| ▲ | solid_fuel 2 days ago | |||||||||||||
I would rather keep things on postgres but everything wanting its own postgres container is really annoying. Postgres already has support for multiple databases, users, and access controls. I would personally prefer to just set up one postgres instance with proper backups and have everything run against that, unfortunately some self-hosting projects have fairly poor support for that. | ||||||||||||||
| ▲ | doubled112 2 days ago | parent | next [-] | |||||||||||||
I prefer a separate DB instance for each app. Each app is on a separate ZFS filesystem so I can snapshot/backup the app data and DB together as one. A possible restore only affects that app. Plus I can guarantee the files and DB were snapshotted at the same moment this way. It may just be a way for me to avoid managing the DB. | ||||||||||||||
| ||||||||||||||
| ▲ | eddythompson80 2 days ago | parent | prev | next [-] | |||||||||||||
You could sometimes get there. The problem is in an effort to simplify the getting-started with postgres (or other databases) most projects assume they would also automate the management of that postgres instance. The getting started would be a lot different if it first instructed you to install postgres, run a script or create a database and users and configure access controls. Also certain things become easier if you assume you can also manage the postgres instance, like on an upgrade, maybe you just create a completely new database and drop the old one, or isolate tenants within one application into different databases, etc. In general, I agree with OP that sqlite is all you need for selfhosted applications (most of the time at least) | ||||||||||||||
| ▲ | steezeburger a day ago | parent | prev [-] | |||||||||||||
That sounds like a mess. What do you do when the open source projects you're running need different versions of postgres? | ||||||||||||||
| ||||||||||||||