I work per stack. Each stack can have multiple services/containers. So one db per stack. I usually work with the compose file provided by the app I want to run and they usually provide their database container in those. My persistent data for a stack is in a single folder for every services. For backup, I only have to backup the compose and environment files and also the persistent folder and that’s it. Every stack is independent from each other so it’s easier to move them from a server to another if I want to use more than one server.

I used to use only one db container for all db. It worked well, until I had a data corruption issue. I had to rollback from a backup for all services that used this db. Then I moved to 1 db per stack and it happened again, but this time, only that stack was impacted, so no big deal. Just did a rollback and everything was fine.

CloudNative PG is so far my favorite. I also prefer a PG per App.

I just let each docker stack get its own.
Often different services need different versions or update between versions at different cadences, so I don’t want to deal managing all that.

One database service but separate databases running inside of the service. Each database has 3 accounts: table_owner (no remote access), proc_owner (only table specific permissions and the owner of all stored procedures; no remote access) and application_account (no table access and only execute permissions on the proc_owner’s stored procedures).

Which means that even if the application is compromised, it can not compromise the database. It can only use approved stored procedures that check their inputs and abort on the smallest deviation from expected inputs.

I just run whatever db is required in the docker compose stack. I’ve thought about running separate db like mongo, mysql, sqlite and having them as central db services for the containers. I don’t see a downside to doing that. It just seems to me that it’s easier just to run what is required by the compose stack itself. For what I’m doing, they don’t seem to eat up much resources.

Am having problem getting MariaDB to work with NextCloud. Any help would be appreciated.

I use a single centralized database running directly on the host (postgres) and make it accessible to the docker clusters.

Pros: It’s all in one place to backup all important data for every service, I find this a much easier and more reliable way to backup all services, and I’m confident if you tried it you would too. The application data becomes a first-class citizen instead of hiding inside some nameless docker volume. Significantly less database overhead. Consistent database version and tools.

Cons: Lots. You need to manage and backup the database. You need to manage the database users and passwords too. Making the DB accessible to the docker clusters is nontrivial and can be fragile. You can no longer use the default “official” docker compose files, since they will almost never support an actual database service without several modifications, they’re always built for spinning up their own docker container database. So you’re going to be doing a bunch of work setting up users and passwords and performing extensive surgery on the docker-compose before you even start up the application, which adds a lot of friction, with lots of opportunity for error. All things considered, it’s actually quite painful. Technically if one application abuses your database hard enough and exhausts its memory to crash it or something it would affect other applications too, but that’s true of any services running on shared hardware abusing anything on that hardware, so it’s not a realistically concerning con.

I consider it worthwhile, but I might be wrong. Also I hate docker in general. I understand why people use it. It’s the same reason I use it. But I still hate it. I think system installations are so much easier to manage in the long run, but initially more work, and you need to invest that work at a time when you’re not even sure if you really want to run this application or if it’s going to be compatible with the rest of your environment. So docker is the easy solution. But then you’re basically trapped in dockerland. It’s not that bad, I just hate it in principle. I wish there were a better way.

Not a database admin nor expert nor experienced. I also don’t want to experience dependency hell.
Each service get’s what it requests in the readme/docker compose template.

One per service. Not just because it’s easy, but because it allows you to minimise blast radius. If you’re running one DB per container and one container gets compromised, only that one DB is compromised. With one centralised DB for all containers, a breach of one container means access to the data of all containers that use this database without the need for any lateral movement.

I too spin up a new DB for every service that needs one. It makes maintenance less intrusive since I only have to shut down one service at a time to update or do a full file backup and I can safely tweak the DB config to best suit the service without worrying about negatively impacting other services on the same DB. I also like the flexibility to choose the best DB for the service, e.g. I use Postgres for a lot of the services I develop but they do also support MySQL/MariaDB, but I have other services that are more tested on MariaDB.

I’d imagine having one database for everything could eventually cause performance problems across all services if the database gets too big or clunky or queries get too complex, even if just one service is causing the problem.

I also run a lot of physical servers (I have about 10 low power computers I use as servers right now) so having a dedicated DB per service allows me to get better performance since the DB can be on the same machine as the service. Not that they need high performance, but it also helps with the efficiency.

Bare metal database VM running mariadb, postgres and valkey. Haven’t had any issues with needing multiple versions. Simpler to manage imaging the VM and data backups from a central place. Plus, I need a general database anyways for development work, sanitized production clones, etc. No sense in having 50 database servers running when I can have 3

I typically have one DB service per app service (not just ler cluster, unless multiple services need the same db).

Advantages:

• Simple backup/data organization, each service is self-contained
• True isolation: Unless you manually create DB accounts for each service, likely all your services have access to all data, and even with accounts there are data leaks and exploits

Disadvantages:

• You have more services running than strictly needed, but this is a minuscule impact on performance (the overhead of the DB service is typically not noticable)

I’ve had a really hard time figuring out how to get cloud native pg working 'cause I couldn’t get longhorn working for disk space.

So instead I went with a separate Raspberry Pi that isn’t part of the cluster to host a single Postgres instance.

It’s inelegant, but has worked for years. Still, I’d rather host a separate pg instance for each project… I just have to figure the above out first.

Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:

5 acronyms in this thread; the most compressed thread commented on today has 7 acronyms.

[Thread #13 for this comm, first seen 15th Jun 2026, 07:30] [FAQ] [Full list] [Contact] [Source code]

Individually. If the app requires a DB, I put it in the compose file. This simplifies both backups and migrations. My tooling for backups has a pre and post script I can customize on a per app basis so I just have the pre do whatever *dump for that DB and the post clean it up (backup takes a tar of the folder).