LiteFS Recommendation #779
Replies: 2 comments 2 replies
-
I don't have time to answer properly right now but I have considered this and I do have an answer. Before I give it, can you tell me what you're building that requires more than 100 writes per second? |
Beta Was this translation helpful? Give feedback.
-
Sure! Well, we've got 70+ technicians in the fields who will be pinging their location in a background, and we'll have an API writing that to the database. Then we also have ETL's syncing the database with external services. On top of that, we've got all the regular database writes as well as logs of who has written what, around 30 in-office people in addition to the technicians. We are working on the CRM right now, but will also have an ERP, dispatch board, inventory, customer signatures, approvals, phone call meta data, CSR statuses, customer intake information, and all kinds of stuff like that. This is just for our first customer too, hopefully we will be growing rapidly, which will make these numbers compound. Maybe my use case is odd though in having that much data. |
Beta Was this translation helpful? Give feedback.
-
I'm wondering why LiteFS would be recommended. It doesn't really seem to have a use case to me.
It maxes out at 100 transactions per second. If you have a large application, you are going to need more throughput than that. If you have a smaller application, you don't need replication anyway, and you can get away with volume snapshots or Litestream.
If you're trying to make your application scalable, Postgres seems like a more prudent option to me (although, I'm personally just using a SQLite server, as I only have one node atm). If you're just trying to get as much mileage as possible out of a single node application, it seems like Litestream would be a better solution.
Am I missing something?
Beta Was this translation helpful? Give feedback.
All reactions