this post was submitted on 14 Jun 2026
32 points (100.0% liked)

Selfhosted

60451 readers
799 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

Detailed Rules Post

  1. Be civil.

  2. No spam.

  3. Posts are to be related to self-hosting.

  4. Don't duplicate the full text of your blog or readme if you're providing a link.

  5. Submission headline should match the article title.

  6. No trolling.

  7. Promotion posts require active participation, with an account that is at least 30 days old. F/LOSS without a paywall has exceptions, with requirements. See the rules link for details.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 3 years ago
MODERATORS
 

Hello,

As the title suggests, how do you manage your DBs for docker services.

Do you spin a new DB for every new docker cluster or do you have a centralized DB that is accessible to the docker clusters.

What are the pros and cons of both method?

For the moment, I spin a new DB for every services as I feel it is easier to backup the service in case of a problem.

you are viewing a single comment's thread
view the rest of the comments
[โ€“] irmadlad@lemmy.world 11 points 3 weeks ago (1 children)

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.

[โ€“] Mertn33@lemmy.world 1 points 2 weeks ago

I do the same. If the docker container has problems with db I can just shut it down and fix the db from my desktop then start docker again. That has saved me starting again from scratch several times.