Choosing a proper database for mobile messenger app
-
I'm wokring on a mobile messenger app using Flutter. I'd write backend code in Node.js. My app will have a list of users and each user can send request to other users to get paired with them. Each user can reject/accept other users' requests. If two users get paired, they can send message to each other or make a voice/video call. All messages transfered between users will be registered on the database for further analysis or detecting any criminal materials or misuses. I'd have about 2000 users, meaning the maximum online users are about 2000 people. The overal nature of the backend model is relational. I need to choose a proper database for this app. My options are MongoDb and Sqlite. Which one is good for this project? Can Sqlite handle this project with that amount of users?
-
I'm wokring on a mobile messenger app using Flutter. I'd write backend code in Node.js. My app will have a list of users and each user can send request to other users to get paired with them. Each user can reject/accept other users' requests. If two users get paired, they can send message to each other or make a voice/video call. All messages transfered between users will be registered on the database for further analysis or detecting any criminal materials or misuses. I'd have about 2000 users, meaning the maximum online users are about 2000 people. The overal nature of the backend model is relational. I need to choose a proper database for this app. My options are MongoDb and Sqlite. Which one is good for this project? Can Sqlite handle this project with that amount of users?
You can size it like the following 2000 users 100 messages a day Total = 200,000 message a day Messages per year = 400 * 200,000 = 80,000,000 Why 400? Because precision is not needed. All of the numbers are just guesses to give a goal. Then further what is the average message size? 100 bytes or 1,000,000. Obviously the second is going to be because they are transferring files and not just messages. So do you keep the files also. One thing I don't see in your post is growth rate. Are you starting with 200 users and only expect them to grow to 2000? Or the market that you are targeting, at best, only has about 2000 users? You also do not document retention rates. How long do you keep the messages? 1 year? 7 years (often sufficient for most legal/business reasons)? 20 years? So what database do you need? Any really. Nothing you posted suggests a need for 'speed'. All you are doing is keeping it for future analysis. You could even just write it to files. You also do not mention personal security. Presumably, excluding the analysis, the messages are not subject to random poking around by operations personnel so how do you secure that?
-
You can size it like the following 2000 users 100 messages a day Total = 200,000 message a day Messages per year = 400 * 200,000 = 80,000,000 Why 400? Because precision is not needed. All of the numbers are just guesses to give a goal. Then further what is the average message size? 100 bytes or 1,000,000. Obviously the second is going to be because they are transferring files and not just messages. So do you keep the files also. One thing I don't see in your post is growth rate. Are you starting with 200 users and only expect them to grow to 2000? Or the market that you are targeting, at best, only has about 2000 users? You also do not document retention rates. How long do you keep the messages? 1 year? 7 years (often sufficient for most legal/business reasons)? 20 years? So what database do you need? Any really. Nothing you posted suggests a need for 'speed'. All you are doing is keeping it for future analysis. You could even just write it to files. You also do not mention personal security. Presumably, excluding the analysis, the messages are not subject to random poking around by operations personnel so how do you secure that?
My main problem is concurrent database read/write capability. I'll delete "seen" messages every month. I think Sqlite is not good for this project. What about SQL Server? Or Mongodb?
-
My main problem is concurrent database read/write capability. I'll delete "seen" messages every month. I think Sqlite is not good for this project. What about SQL Server? Or Mongodb?
They are 2 quite different databases, SQL Server (which will certainly meet you needs) is relational and Mongo DB is a document database, a different beast altogether.MongoDB vs SQL Server: Which is Better? [10 Critical Differences] - Learn | Hevo[^]
Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP
-
I'm wokring on a mobile messenger app using Flutter. I'd write backend code in Node.js. My app will have a list of users and each user can send request to other users to get paired with them. Each user can reject/accept other users' requests. If two users get paired, they can send message to each other or make a voice/video call. All messages transfered between users will be registered on the database for further analysis or detecting any criminal materials or misuses. I'd have about 2000 users, meaning the maximum online users are about 2000 people. The overal nature of the backend model is relational. I need to choose a proper database for this app. My options are MongoDb and Sqlite. Which one is good for this project? Can Sqlite handle this project with that amount of users?
Sqlite is meant as a single-user database. MongoDb is for documents.
Alex Dunlop wrote:
users will be registered on the database for further analysis or detecting any criminal materials or misuses.
The answer is a clear no. You might want to consult a lawyer, not a software-dev.
Bastard Programmer from Hell :suss: "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
-
I'm wokring on a mobile messenger app using Flutter. I'd write backend code in Node.js. My app will have a list of users and each user can send request to other users to get paired with them. Each user can reject/accept other users' requests. If two users get paired, they can send message to each other or make a voice/video call. All messages transfered between users will be registered on the database for further analysis or detecting any criminal materials or misuses. I'd have about 2000 users, meaning the maximum online users are about 2000 people. The overal nature of the backend model is relational. I need to choose a proper database for this app. My options are MongoDb and Sqlite. Which one is good for this project? Can Sqlite handle this project with that amount of users?
-
Assuming the database will be controlled by some hosted system that is only accessed by your backend system, then SQLite would be a resonable choice. See Implementation Limits For SQLite[^] for guidance on sizing.
-
If the SQLite database is accessed only by the backend, could it handle 500 read/write requests which are sent to the beckend at the same time?
-
My main problem is concurrent database read/write capability. I'll delete "seen" messages every month. I think Sqlite is not good for this project. What about SQL Server? Or Mongodb?
Alex Dunlop wrote:
My main problem is concurrent database read/write capability
Nothing in what you posted suggests that is a concern. Each new message is just a new record regardless of how you store it. Even if you allow edits you should handle that as a new message rather than replacing the previous one.
Alex Dunlop wrote:
What about SQL Server? Or Mongodb?
Not a matter of whether those would work but rather if they are overkill. When I looked up the transactions per second speed for Sqlite I did not see anything that concerned me for the sizing I previously posted.
-
Sqlite is meant as a single-user database. MongoDb is for documents.
Alex Dunlop wrote:
users will be registered on the database for further analysis or detecting any criminal materials or misuses.
The answer is a clear no. You might want to consult a lawyer, not a software-dev.
Bastard Programmer from Hell :suss: "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
Eddy Vluggen wrote:
You might want to consult a lawyer, not a software-dev.
At least in the US and presuming a single company then users can have no expectation of privacy for company resources. Notifications to company employees are nothing more than a courtesy. Although perhaps also that they should keep the personal stuff off the company sites.
-
If the SQLite database is accessed only by the backend, could it handle 500 read/write requests which are sent to the beckend at the same time?