4 ms·
Proper concurrency, and the ability to scale out your applications across multiple servers / nodes. I’ve never worked on any application that had only a single
by christophilus 2y ago
Proper concurrency, and the ability to scale out your applications across multiple servers / nodes. I’ve never worked on any application that had only a single web server, and yes, most of my applications have had to scale out a few times under load— even the smaller ones. Doing this with Postgres is trivial. Doing this with SQLite requires engineering. I’m not scared of engineering. I just don’t think it’s warranted when you have such an obvious, tried and true off the shelf database like Postgres available to you.
- deleted 2y ago[deleted]
- vidarh 2y agoScaling with SQLite and a datastore-per-user model is trivial. If you build your app as if it's using Postgres when you're using SQLite, then, yes, you'll suffer. If you pick SQLite, you should pick it because you will actually build your application in the way that makes most sense with SQLite. Datastore-per-user makes sharding/scaling trivial, and tends to drive an architecture that is easier to reason about. You're never going to e.g. accidentally leak data between users because of a broken query, for example.