Comment by teaearlgraycold
1 day ago
Well if you run a tiny single-threaded app then SQLite is a nice simplification over spinning up a separate machine for Postgres.
1 day ago
Well if you run a tiny single-threaded app then SQLite is a nice simplification over spinning up a separate machine for Postgres.
I use postgres for very simple apps. I have a Dockerfile I use in my boilerplate repo. It takes a single make cmd for me to build, start and run migrations. Its as simple as using sqlite.
But now you have another process to babysit. How do you keep it healthy? And you have to ensure the client-server communication won't break.
For me the main benefit of sqlite is that it's a library rather than an app.
> But now you have another process to babysit. How do you keep it healthy?
I've been assured by many HN users that running apps/sites on a single VPS requires near-zero maintenance or monitoring to achieve acceptable uptime 24/7/365 for years on end, sooooo...just pretend it will never fail like your main server process?
4 replies →
I have boilerplate for client-server communication that makes it pretty trivial to build on top of.
Im not saying that sqlite isn't useful, im mostly saying that using postgres doesnt have to be complicated.
Its 2x the infra. You have to manage an additional process, auth, backups, logging, etc.
Or you can run postgres on the same machine as the application, which lets you much more easily migrate if the time comes when you need to scale to multiple application servers.
There's a world between "local file" and "network DB server", running a DB server locally has lots of benefits from being able to easily query from outside if needed to forcing you to consider concurrency without the latency overhead of a network hop.
This decision tree doesn't make much sense to me. Why you someone forego performance today in favor of adding a completely unnecessary network layer to every DB query in order to "satisfy" future imaginary "scaling concerns"?
Because you don't add a network layer by running a database locally.
That's still orders of magnitude more complexity for no real benefit. A migration from sqlite to postgres, if really required, is not that hard.
Yes, postgres should support a superset of SQLite functionality.
Now you've added a substantial dependency, and annoying setup requirements. Good luck doing this for a native app on mobile or desktop.
If someone is talking about "spinning up a separate machine" for Postgres, they're not talking about a desktop or mobile app...
Obviously SQLite is the best choice for a mobile or desktop app, that's not what's being discussed here.