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?

Ive been assured by many HN users that you must have 24/7/365 uptime for everything in case one of your 10 bi-monthly users decides to log on.

Call me old-fashioned and quaint, but I don't like to build software that doesn't work all the time if I can help it, whether it's for 10 users or 10 million.

24/7/365 is needed (or achieved) just about never. our big tech is proving 90% will soon be utopia as well. being down has always been fine for 99.999975% of all projects on the planet.

Ok, now tell me the stat by percentage of overall market revenue rather than project count

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.