I’m designing a new web project and, after studying some options aiming scalability, I came up with two database solutions:
- Local SQLite files carefully designed for a scalable fashion (one new database file for each X users, as writes will depend on user content, with no cross-user data dependence);
- Remote MongoDB server (like Mongolab), as my host server doesn’t serve MongoDB.
I don’t trust MySQL server at current shared host, as it cames down very frequently (and I had problems with MySQL on another host, too). For the same reason I’m not goint to use postgres.
Pros of SQLite:
- It’s local, so it must be faster (I’ll take care of using index and transactions properly);
- I don’t need to worry about tcp sniffing, as Mongo wire protocol is not crypted;
- I don’t need to worry about server outage, as SQLite is serverless.
Pros of MongoDB:
- It’s more easily scalable;
- I don’t need to worry on splitting databases, as scalability seems natural;
- I don’t need to worry about schema changes, as Mongo is schemaless and SQLite doesn’t fully support alter table (specially considering changing many production files, etc.).
I want help to make a decision (and maybe consider a third option). Which one is better when write and read operations is growing?
I’m going to use Ruby.
One major risk of the SQLite approach is that as your requirements to scale increase, you will not be able to (easily) deploy on multiple application servers. You may be able to partition your users into separate servers, but if that server were to go down, you would have some subset of users who could not access their data.
Using MongoDB (or any other centralized service) alleviates this problem, as your web servers are stateless — they can be added or removed at any time to accommodate web load without having to worry about what data lives where.