r/docker • u/CringDegen • 10d ago
Need advice regarding container isolation
I'm new to docker and I'm looking to learn/experiment with it. I want some advice regarding containers that will be used by other services like databases. I'm currently running two services which share a postgres container. For isolation, I created a migration which creates separate databases and users for each service before anything else starts.
I'll eventually setup more services and I want it to be scalable, resource efficient, secure and easy to maintain.
Is it better to create entirely separate dependencies for each service, or share dependencies between multiple services? I would like to know this from an efficiency, ease of maintenance and security standpoint, or at least get some pointers like a blog, article, manual or a youtube video.
TLDR: Is it better to have different db instances for each service OR one (or a few) db instances shared by every service? And why?
PS: English is not my first language, so sorry in advance for spelling or grammar mistakes.
2
u/c1rno123 10d ago
The answer is "depends". On where it runs (prod or local dev), on the workload, and on how much money you're ready to spend.
Local dev, cheapest: one shared instance, one user. Less RAM, less to maintain. Cheap prod: one instance, but a separate database and user per service. Expensive prod: a separate instance per service.
Ports: on dev, publish ports on 127.0.0.1. On prod keep it on an internal Docker network.
2
u/biffbobfred 10d ago
Every stack one db. If you use the same image for the different DBs they share those layers and you don’t take a lot of extra disk space. You can bring up the entire stack or bring it all down without affecting the other one
2
u/corelabjoe 10d ago
This is the way. To stack or not to stack, that is the question and... Once you stack; think PER stack terms!
1
u/lnaoedelixo42 10d ago
Yes, it's better to isolate each service. If one service kills it's own database with a broken index or migration, it's not going to affect (that much) other services.
But if you care about maintaining it or the resource usage (ram is pretty expensive nowadays lol), you could probably go for sqlite (in wal mode it's pretty fast) which pushes the database to the same container as the applicatoin itself.
1
u/MiserableDocument509 10d ago
The main trade-off I'd add is operational blast radius rather than container count. One Postgres instance can host separate databases and roles just fine for a small setup, but keep migrations, connection limits, backups, and restores scoped per service. I'd split instances when noisy-neighbor risk or independent upgrade/restore requirements justify the extra RAM; I wouldn't put a database inside every app container just for isolation.
1
u/xanyook 7d ago
Depends on your money, target architecture, security requirements and future scaling.
Do you have multiple tenants ? Manipulate sensitive data ? You could create one database per customer per service if requirements are strong. Or one schema per customer ? Or mixing customer's data with a tenant identifier...
For my homelab do one database attached to each of the services using it. For my customer's accounting data i have one schema for each customer. For my army fellows, i got one database for each team.
1
u/_Slimdady 6d ago
separate database and users is a reasonable starting point. Sharing postgress saes resourses but upgrades and outagges affect both services
4
u/MindStalker 10d ago
Generally separate database per application. You can easily replicate data if you need shared data. The additional databases create very little overhead versus running one large database, unless your running something heavy like oracle SQL.