this post was submitted on 30 Nov 2023
1 points (100.0% liked)
Homelab
371 readers
9 users here now
Rules
- Be Civil.
- Post about your homelab, discussion of your homelab, questions you may have, or general discussion about transition your skill from the homelab to the workplace.
- No memes or potato images.
- We love detailed homelab builds, especially network diagrams!
- Report any posts that you feel should be brought to our attention.
- Please no shitposting or blogspam.
- No Referral Linking.
- Keep piracy discussion off of this community
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I think it only make sense if you have resource constraints. Consolidation databases would free up some RAM and CPU cycles.
From perspective of maintenance and security it’s a nightmare. Depending how many services you have and what’s their migrations strategy most setups require full admin to DB some will try to create DB. You would have to tweak db scripts for those deployments. Performance wise it would put load on single DB process so you would have to inspect queries to figure out what is causing performance issues if you have any.
Database upgrades would be impacting all services. If one of them uses deprecated functions or another one is requiring to upgrade to use new release you would be in trouble.
You need to have separate users and permissions. Create databases outside of normal deployment scripts.
Generally separation of databases gives a lot of flexibility for releases, isolated database activities for performance and administrative tasks, streamlines new release upgrades.