First, ask for yourself a questions: In multi-user environment, how exactly would you manage concurrent users? Will they take turns? Will they use terminal to log in?
One client could potentially bring down the entire system. Instead of competing for CPU/RAM/Disk on the same machine, now they have their own. If database server goes down, a properly designed client could cache data, with the condition that application support properly design client, and then sync to the database server once it comes back online.
Let's see, you have these components of a typical n tier architecture:
- Web server/s (presentation)
- App server/s (application)
- Database server/s (data)
They all have very different infrastructure, environment, security and management/support requirements.
Consider a high performance enterprise scale environment. You may be running an Oracle DB on a physical dedicated Unix server. All resources like memory, disk and IO controllers are dedicated to optimal performance of read, write or both. If the data is business critical you may also have a fail over, backup & recovery and disaster recovery strategy that takes this into account.
Now consider app servers that may be quite lightweight in comparison. You may choose to utilize virtual servers on Linux or Windows for budget reasons or due to the skill set of the development team. If performance issues arise scaling out the application layer can be a fairly trivial task. You also have the ability to balance load across multiple app servers.
It's similar for web servers. Also consider security implications. With multiple tiers you have greater control over what you can firewall. You may only want app connections landing on the DB server. If the app/web server are publicly accessible you don't want the sessions landing on the DB server.
In terms of latency between app and DB servers there are many things you can do to minimize this. Point to the DB host using IP not host name, utilize GB connectivity between the two, look at using and maintaining a per-created pool of connections.
This is an interesting question and I could waffle on for hours, hopefully this gives you an insight.
Other arguments:
There are many advantages of separating application server with database server. I will cover as many advantages as I can. So, let's get started with the first and most important advantage.
- Better Monitoring: Yes, when you separate your database server with your application server, you get to know whether your need to optimize your server or you need to optimize your application. It's because one server will be running application and you will get information about resources usage just for your application code and on the other side, you will get information just about your database. Let's say you have one 16GB server with application as well as database and the load on your server is higher than it can handle. What you can do? separate your servers and check whether your application requires more resources or your database requires more resources.
- Scalability: You can upgrade/downgrade servers according to their resource consumption. Let's say you have one 16GB server and you have 70% CPU usage. Separate application server with database server 8GB each and check whether your application requires your more resources or your database. If your database requires less resources, You can downgrade it to save money ;) . Also, you can upgrade based on the resource usage. If your Database server requires more resources then you can upgrade your database server and keep same application server.
- Better performance: In a single server, Apache/Nginx/IIS, MariaDB/MySQL/PostgreSQL/MongoDB, PHP/Python/Perl has to share single CPU but when they get their own resources, you will see improvement in overall performance of your application.
So, these are the benefits you get when you have different machines to manage your different types of tasks. I recommend you to separate Database server with Application server once you reach the Limit of 32GB RAM or 8 cores. Let me know if you have any more queries in the comment section. - If someone breaks the box that houses your application server, they are not guaranteed access to the same server that houses the database. Also, by separating this functionality you make it easier on the IT (software devs, admins, etc) to minimize code change impact / policy updates on different aspects of the environment. This does not in any way fix poor coding or weak security (SQL injection, default username/passwords). but it does facilitate a better security posture overall.
Summarize:
Keep the database server separate from the web server. When installing most web software, the database is created for you. To make things easy, this database is created on the same server where the application itself is being installed, the web server. Unfortunately, this makes access to the data all too easy for an attacker to access. If they are able to crack the administrator account for the web server, the data is readily available to them.
Instead, a database should reside on a separate database server located behind a firewall, not in the DMZ with the web server. While this makes for a more complicated setup, the security benefits are well worth the effort.
Other arguments are scalability, better performance, better monitoring.
Choose right solution to design your environment infrastructure.