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.

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.

I prefer one database server instance hosting different databases, for each client service one.