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!

  • Smk@lemmy.ca
    1·
    1 year ago

    1 db per stack. Not worth your time to secure, configure and debug one big db.

  • palitu@lemmy.perthchat.org
    1·
    1 year ago

    I agree with the posts above. Db per stack/service.

    They are cheap, disposable, ring fenced from causing issues with other dB’s, exact version that has been tested on.

    The list is endless. We’ll, I’m at my end.

    Oo. Typically compose has everything you need prewritten including the db.

  • anteaters@feddit.deEnglish
    1·
    1 year ago

    I wondered about that myself these days and decided to give each stack its own db. Makes it easier to throw a stack into the bin without having to manually prune the associated databases. I might end up running a database container anyways for tests and side projects and things like that but service stacks get their own db of their choice.