Comment on "Support" containers - centralized or separate per service?
PriorProject@lemmy.world 1 year ago
- If a service supports sqlite, I often will use that option. It provides everything a self-hoster needs from a DB with basically no operational overhead.
- If I do need a proper RDBMS (because the software I’m using doesn’t support sqlite), I’m going to use…
- A single Postgres container.
- Configured with multiple logical “databases” (the container for schemas and tables), one DB for each app connecting.
I do this because I’m always memory constrained and the rdbms is generally the most memory-hungry part of any software stack. By sharing one db-process across all the apps that need it I get the most out of my db cache memory, etc. And by using multiple logical db’s, I get good separation between my apps, and they’re straightforward to migrate to a truly isolated physical DB if needed… but that’s never been needed.
AnAnxiousCorgi@lemmy.reddeth.com 1 year ago
That makes a lot of sense and where I’m leaning towards as well
While my homeserver still has plenty of resources to spare, I see a lot of them going towards multiple DB containers. It’s nice for “segregating” the containers, but backups are also a pain, gotta plan backups/restores for multiple DBs
Same story with an s3 (well, minio) instance running. Seems like it would make more sense to centralize DB and file operations and having different services talk to them. Then if I ever needed to move them into separate servers, it wouldn’t be as big a move.
Thanks!