So I’m in the process of (re-) setting up my homelab and unsure about how to handle databases. Many images require a database, which the docker-compose usually provides inside the stack.
Now my question, shall I have 1 database container which is accessed by all containers? Or shall I have a separate container for each service?
For critical services, which shall have as few dependencies as possible I’m already using sqlite or a similar solution.
Also on a sidenote: I have two docker hosts, can I let the containers of 1 hypervisors use the same internal docker network?
TIA!
1 db per stack. Not worth your time to secure, configure and debug one big db.
One database for many different services could pose a security risk, though it should be extremely low if each service can access only its own database. However, it’d be harder to distribute services across different hosts if you ever decided to do that. Also, different services could require or work better with different database types. I prefer to use separate database containers.
Unless you are very constrained on resources, using a database per application is much easier.
Not only do I prefer separate db for each stack, ideally the db and app are in the same container. Fewer containers to manage and makes the app nice and self-contained.
Backup / restore gets complicated if you have multiple apps in 1 dB
No one said a single DB. You can have multiple DBs in a single container, and then use something like databacker/mysql-backup container which solves the complexity of multiple db backups for mariaDB and MySQL
Yes, terminology… I mean single instance. And although you can create pg_dumps of separate databases, a true (online) backup of separate databases is difficult. Tools like pgbackrest or barman don’t support it. (I mainly focus on Postgres)
