One separate VM as DB? reddit / selfhosted ---------------------------------------------------------------------- sh4hr4m · 2023-12-18 08:22 Hi everyone, In theory, wouldn't it be better to have a dedicated VM for DB instead of multiple DB containers for each application that needs one? is it even possible? if so, which keywords should i use to search? Best Regards, Shah ---------------------------------------------------------------------- TBT_TBT · 2023-12-18 08:29 I prefer to put a separate DB in each Docker stack (I assume you mean Docker with „DB containers“?). The advantages: - different db versions can be used (and pinned) for different containers - each stack can be updated separately without having to stop the other stacks (no interruption of service for other stacks) - each application is in its own network with no need to open external ports for databases (the db is more secure) - easier movability of an app to another host (just take the docker- compose file and the volumes (including the db volume) and put it somewhere else. No need to export the app db. - base databases really don’t need many resources, so it is not that wasteful to run several engines ---------------------------------------------------------------------- sh4hr4m · 2023-12-18 09:03 thank you sir for your answer. it was everything that I needed to know. 🙏🏼🙏🏼🙏🏼 ---------------------------------------------------------------------- PatochiDesu · 2023-12-18 10:44 usually (big) companys run and maintain dedicated db clusters. i only containerize databases for developent and testing because its easy. productive databases i usually host in dedicated database cluster because they have a different backup process than the common containers. ---------------------------------------------------------------------- sh4hr4m · 2023-12-18 11:07 thank you for your answer 🙏🏼 you're right. I thought my data base stays safe when I'm messing around with my other containers. but i run my self hosted services for 1-2 users normally (over 99% 1 user - just myself 🙈) ---------------------------------------------------------------------- PatochiDesu · 2023-12-18 11:24 it depends on your need. usually people want to revert backups not in bulk but maybe just for like 1 or 2 tables. that is not possible with a containerized approach using a uniform backup/restore process. i personally do not like to have the database engine overhead (os, db software) multiple times. that databases dont use much ressources is only true if they are tiny and dont have many indizes. so when you do a query its mostly consuming disk io. but for the queryed subset of data it still consumes memory that it usually doesnt free anymore on container level but inside the container. usually containers only grow. start a container and look at the memory consumption of it. there are not many that also shrink. ---------------------------------------------------------------------- Docccc · 2023-12-18 11:30 this right here ---------------------------------------------------------------------- KD_done · 2023-12-18 12:09 My approach is different, yet, I can't say that TBT's suggestion is wrong.. not at all. However, I have a single DB server.. and it's ticks all the boxes I needed. I run mysql, postgres, redis and mongodb on it. I have 9 firewall rules to make sure that the 6 vps servers can connect to the box freely.. and only those 6 vps servers get access. If I wanted, I could run multiple version of database-software for X reasons.. I have seldom found a reason to do so, so that would not be a good argument for a use-case for me.. Again, a perfectly valid argument, but I have other needs. One of the vps servers runs cloudbeaver (phpmyadmin, adminer or else anything you prefer) for any type of management, and that (besides an ssh directly) is the only way "in". Secure, as secure as the frontend- apps are. A plus for a centralized option is lower memory footprint on the application servers, and especially with larger databases that makes a huge difference. So, this is a per use-case different, and in my case it is of importance (I more than a few databases that exceed the 4Gb in size.. and I would love to have all that data in RAM, but ... not on the application servers side :)). I would argue that moving an app is as easy for me too. I don't need to adjust the config of the application too, and I only need to move the data, nothing else. But again, it all depends on the applications you are running and how you manage them. Not one is solution is better. Now.. my main selling point on a centralized database solution is backup speed & ease of maintenance with the lowest impact on any and all applications. And, I have one final point I would like to make.. Why not both!?!? Both have their benefits.. neither solution is better/worse than the other. Make the stuff work for you, and what suits you best. I like/love ansible.. but, if that's not for you, and you prefer puppet.. sure.. .. but for the love of god, keep that emacs shit to yourself, it's vim all the way ;) ---------------------------------------------------------------------- vermyx · 2023-12-18 15:02 This isn’t all true. The downside of having one database for your apps is that you have to manage how the apps behaves. People who are using disk snapshots (as an example) have to quiesce the database which is harder when you have multiple apps in one DB or run the risk if an inconsistent backup. There is also the issue that (depending on how active apps are) you can starve an app of database buffers if you have a very active application. This means maintenance and backups are actually more difficult to do because you have much more to consider and troubleshooting performance issues becomes more difficult. ---------------------------------------------------------------------- AnApexBread · 2023-12-18 15:43 You could do either, but general Database management practices are a unique DB per project. There's a lot of reasons for this but the biggest one is compatibility. Lets say you have two applications that both need a mySQL DB. Application 1 get an update and now it needs MySQL v1.2 but Application 2 is only compatible with MySQL v1. If you update MySQL to v1.2 you could break application 2, but if you don't then Application 1 could break. Dedicated DBMS solve that problem. ---------------------------------------------------------------------- TBT_TBT · 2023-12-18 18:38 I think both approaches are perfectly valid. Mine might be more suited for containers, yours for vservers/dedis. ---------------------------------------------------------------------- bufandatl · 2023-12-19 09:41 It all depends on the service you run. Occasional access to the database and maybe just one or two users. I would run them in a container for each service. But if you have big and a lot of transactions give it its own VM then you can scale out easier and maybe even do HA clustering easier.