[throwawaaarrgh]

Like everything in life, "it depends."

If what you need can suffice with SQLite, then Postgres will work too.

If you're running an app on a VM, running Postgres on it too is easy and isn't "big". It's easy to install and set up, and you're set up for all the features you may want later. Plus you avoid having to refactor for a different database later on.

If you're running your app in a serverless context, or on a PaaS/SaaS, etc, then SQLite might be easier. But maybe you want horizontal scalability with a shared dataset and then you're back at Postgres.

Just picking one thing "because everybody does" or "because it's lightweight" or "it works in most cases" etc aren't good reasons to pick technology. Look at your actual application, make a list of pros and cons, and choose based on your situation, not the cargo cult answer from the HN hive mind.

[stavros]

Except I have to install Postgres and create a user for it, which I don't have to do with SQLite.

[throwawaaarrgh]

Yes, I mentioned that. It takes about 15 minutes and you do it once.

[stavros]

Yes, that's 15 minutes that could have been saved.

[lxgr]

A project using Postgres vs. SQLite can make the difference between being able to run a single Docker container or having to use Docker Compose.

Nothing big, but I do appreciate being able to trial a tool or service on a test machine with a simple `docker run`.