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.
this post was submitted on 20 Jul 2023
25 points (96.3% liked)
Selfhosted
40437 readers
623 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:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 2 years ago
MODERATORS
The cost of running a db container for each stack is negligible compared to the comfort of not having to clean up your main database container after you just tried some random container. Then you also have different requirements by different containers, each asking for a specific database for whatever reason and lastly you have another level of seperation between your services
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.
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.
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)
view more: next ›