Hacker News new | ask | show | jobs
by Kuyawa 11 days ago
No intention to antagonize but... why not postgre? Even my side projects run on postgresql with no overhead at all
3 comments

It's also explained in the post shared:

---

I've heard "why not PostgreSQL?" a few times this week. It was even our original plan in #539! Well, it was a pragmatic choice in two different ways:

The person who volunteered to do the work used SQLite.

I don't want to use solutions that are bigger and more complex than our likely needs. Postgresql is my default for projects, but it does have the added complexity of being a separate service to run, tune, and maintain.

The person who volunteered to do the work used SQLite.

That is a totally valid reason.

Though if you can run it from SQLite there is not much tuning on Postgres that would be needed. I would expect migration to Postgres from MariaDB would be easier.

> run on postgresql with no overhead at all

Citation needed. I love postgres as much as the next person, but it does have more overhead than Sqlite which is in an in-process db linked through compiled C code, it doesn't run as a separate server. Very significant difference that when you use Sqlite db, there is typically no db process other than your application logic, unless you implement the server yourself. If you don't want your application to have multiple processes (say, as a toy example) then it totally makes sense to prefer Sqlite just for this reason. Sqlite and postgres are different tools, they serve different purposes.

If you run it on your one app server, it’s not much more work than SQLite. SQLite requires some special care when you’re dealing with multiple processes, and backups are about the same amount of effort.
Where are you hosting postgres
On the same machine where they are currently storing the sqlite file maybe? It's not that hard to run. A sqlite backup cron is also not that much more work than a pg_dump cron.
if they have only one server, then on that server. If they have a load-balanced front end and central database, then on the database.