Should we centralize databases or have a database with each application? My company develops different web applications for different clients.
For each new client (or important project), we use a new server with a new MySQL database.

This way, an application can access its database only and the database is directly linked with the project (as it is in the same server so basically in the same directories). Until now it has not shown any particular problem.

As we are changing our methods, my colleagues wonder if we could use instead only one database with all projects in it and use some master/slave replication. 

Our different databases have some tables in common, but with different data as they belong to their respective apps.



I did some research on the subject :
I find mostly posts that recommend using a database for each application for these reasons :  


Distinct log files and backups for each project
Better scalability as we can inspect the needs for each database
Simple to use from application without having to change data or create views, etc.


Most of what I read about this is between 5 and 10 years old so I'm not sure if the disadvantages of the other solution are still relevant.  

I struggle to find precise information and advantages about the unique-database solution and the use of Master/Slave replication for this kind of cases.  

I'm new to this idea : I understand the concept of master/slave here but I don't have technical knowledge about it.  



(Could using a unique database be beneficial ?)  

Should we have :


The database of an app on the same server than the app,   
A single server for all databases, and keep the apps in other hosts ?  


Note that we are using MySQL but PostgreSQL is a possible option if we chose to use a single database with different schemas for each app.
What you have read (even though it's oldish) is still very relevant!

Your problem is called multi-tenancy - to do it or not - the consensus appears to be "not", but there is a wide divergence of views on this issue - you can "partially multi-tenant" - i.e. keep virtually unchanging reference tables in common for example - however the same issues as outlined below apply to "partial" multi-tenancy.

My advice - use separate databases if at all possible! 


If one app goes down, at least the others will still work, with a central database, if one app brings the server down, you're bunched (nothing will work). 
Also, for migrations, if you need to, say, migrate one of your apps (size/speed/whatever problems - or you wish to dip your toe into the cloud testing with one app), then you will have difficulty separating out your apps, whereas if you use separate systems, you won't have any difficulties on that score!


If you'd care to explore this in more detail, I have answered questions on this issue before - check them out (1, 2 and 3 and links therein). Obviously cost and the nature of the expertise readily available to you is an issue so it's worth checking out your options before coming to a decision - you 

Sometimes the wise heads are indeed on old shoulders! :-)

Another recommendation - use PostgreSQL if at all possible! It is vastly superior to MySQL in a myriad of ways - SQL compliance, JSON, Geospatial, CHECK constraints, SET operators ... long list... you won't regret it!