Well if you run a tiny single-threaded app then SQLite is a nice simplification over spinning up a separate machine for Postgres.

▲

eterm 5 hours ago | parent | next [-]

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.

▲

s_ting765 4 hours ago | parent | next [-]

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"?

	▲	eterm 2 hours ago \| parent [-]
		Because you don't add a network layer by running a database locally.

▲

eddd-ddde 4 hours ago | parent | prev | next [-]

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.

	▲	teaearlgraycold 2 hours ago \| parent [-]
		Yes, postgres should support a superset of SQLite functionality.

▲

wat10000 3 hours ago | parent | prev [-]

Now you've added a substantial dependency, and annoying setup requirements. Good luck doing this for a native app on mobile or desktop.

	▲	eterm 2 hours ago \| parent [-]
		Obviously SQLite is the best choice for a mobile or desktop app, that's not what's being discussed here.

▲

ai_fry_ur_brain 6 hours ago | parent | prev [-]

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.

▲

turtlebits 3 hours ago | parent | next [-]

Its 2x the infra. You have to manage an additional process, auth, backups, logging, etc.

▲

tasuki 4 hours ago | parent | prev [-]

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.

▲

not_kurt_godel an hour ago | parent | next [-]

> 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?

	▲	ai_fry_ur_brain 39 minutes ago \| parent \| next [-]
		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.
	▲	bdangubic 28 minutes ago \| parent \| prev [-]
		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.

▲

ai_fry_ur_brain 4 hours ago | parent | prev [-]

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.