4 ms·
> The idea that SQLite shouldn't be use for web applications is about a decade out-of-date at this point I think it's still very relevant. I mean you have serv
by Thaxll 4y ago
> The idea that SQLite shouldn't be use for web applications is about a decade out-of-date at this point
I think it's still very relevant. I mean you have service XYZ replicated two times behind a load balancer, how do you use SQLite out of the box? You can't, you have to use one of those service that will proxy / queue queries, so then why even trying to use SQLite.
The fact that it's just a file on disk make it a bad solution for a lot of simple use cases.
- ok_dad 4y agoYou could partition your data to 2 parts, and direct your users to whichever service serves their partition of that data. Every database turns out to be just a set of files on disk, but for using SQLite you have to think differently than most databases due to the extreme locality of the data.
- emadda 4y agoYou only need a pool of servers behind a load balancer for extreme reliability or for scaling out. Most small to medium web applications can handle: - Only being reliable for 99.99% of the time (using a single cloud VM where the cloud provides the hardware level failover). - Scaling up instead of out (adding CPU, RAM and faster disk).
- ketralnis 4y agoSure, if that's a requirement then it's not a great fit. But it might not be a requirement.
- simonw 4y agoIf you're worried about high availability should your instance fail (which is something that's worth worrying about, though many smaller web apps will likely work perfectly fine on a single instance with good scheduled backups) you should absolutely investigate https://litestream.io https://litestream.io - it's the missing piece of the SQLite-for-web-apps story.