Hello all! Just curious what y’alls typical setup is when it comes to running multiple stacks which require the same “support” containers.

What I mean is, say you want to run two services that both require a connection to a database, would you run two separate DB containers, one for each service and have them connected only to their respective DB “stacks”? Or do you prefer to run a single centralized DB server/service and have your self hosted stacks all communicate with their own databases inside the server?

  • @PriorProjectEnglish
    2•1 year ago
    1. 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.
    2. If I do need a proper RDBMS (because the software I’m using doesn’t support sqlite), I’m going to use…
      1. A single Postgres container.
      2. 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.

    • @[email protected]OPEnglish
      2•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!