Local SQLite vs Remote MongoDB

Question

I am developing a new web project and, having studied some options aimed at scalability, I came up with two database solutions:

• Local SQLite files carefully designed for the scalable method (one new database file for each user X, because the records will depend on the contents of the user, regardless of different users);
• Remote MongoDB server (e.g. Mongolab ) since my host server does not serve MongoDB.

I do not trust the MySQL server on the current shared host, since it is very rarely referenced (and I had problems with MySQL on another host). For the same reason, I am not going to use postgres.

SQLite Pros:

• It is local, so it should be faster (I will take care of using the index and transactions properly);
• I don't need to worry about how tcp sniffing since the Mongo protocol protocol is not encrypted ;
• I do not need to worry about shutting down the server since SQLite is serverless.

Pros of MongoDB:

• It scales more easily;
• I do not need to worry about database partitioning because scalability seems natural;
• I don’t have to worry about schema changes, since Mongo is schematic and SQLite does not fully support the alter table (especially considering changing many production files, etc.)

I want to help make a decision (and maybe consider a third option). Which one is better when write and read operations are growing?

I am going to use Ruby.

Answer 1

One of the main risks of the SQLite approach is that as you scale up, you won’t be able to (easily) deploy to multiple application servers. You can divide your users into separate servers, but if this server was to go down, you will have several subsets of users who cannot access their data.

Using MongoDB (or any other centralized service) alleviates this problem since your web servers are stateless - they can be added or removed at any time to host the web download without having to worry about what data lives there.