1
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 30 Nov 2023
1 points (100.0% liked)
Homelab
371 readers
2 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
It's really hard to tell, and the devil is in the details.
On bare metal, a single server containing both the front-end application and the DB may be faster (no networking overhead), but only to a point. As load increases, a split system (front-end on one machine, DB on another, or even on a cluster) becomes more attractive.
When everything is virtualized and machines talk to each other over virtual interfaces, I would think a single database server usable by multiple front-end applications would be a good idea. This way, you have only one DB server overhead. Also, maintenance is more straightforward; you look after a single database server, even though it contains multiple databases.
It's probably a good idea to pair each application with a dedicated database (within the same database server) and assign each application a unique user name with rights only for that database.