3 ms·
No intention to antagonize but... why not postgre? Even my side projects run on postgresql with no overhead at all
by Kuyawa 3mo ago
No intention to antagonize but... why not postgre? Even my side projects run on postgresql with no overhead at all
- adenta 3mo agoWhere are you hosting postgres
- dewey 3mo agoOn 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.
- inigyou 3mo agoif they have only one server, then on that server. If they have a load-balanced front end and central database, then on the database.
- gnulinux 3mo ago> 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.
- christophilus 3mo agoIf 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.
- dewey 3mo agoIt'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.
- ozim 3mo agoThe 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.