What Is a Database Connection Limit and Why Does It Matter

A database connection limit is the maximum number of simultaneous client connections a database server will accept from your application, and hosting providers impose it to protect shared resources. When you exceed that limit, the database rejects new connections with an error like Too many connections, and your site starts failing intermittently or completely. Understanding this limit matters because it is often the first thing you hit when your application grows, and the fix is rarely "buy more RAM."

How the protocol enforces the limit

Every time your application talks to a database, it opens a new TCP connection, sends a handshake, and then executes queries. The database server tracks each open connection as a lightweight process or thread. For MySQL and MariaDB, the relevant server variable is max_connections. For PostgreSQL, it is max_connections in postgresql.conf. The server checks this counter at the moment a new client attempts to connect, and if the count is already at the ceiling, it sends an error packet and closes the socket.

You can see the current limit and the number of active connections directly from the command line. On MySQL or MariaDB, run:

mysql -u root -p -e "SHOW VARIABLES LIKE 'max_connections'; SHOW STATUS LIKE 'Threads_connected';"

The output will look something like this:

+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| max_connections | 150   |
+-----------------+-------+
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| Threads_connected | 12   |
+-----------------+-------+

On PostgreSQL, you can query the same information with psql:

psql -U postgres -c "SHOW max_connections;" -c "SELECT count(*) FROM pg_stat_activity;"

If the second number gets close to the first, you are about to fail new connections.

Why hosts set the limit low on shared plans

On shared hosting, dozens or hundreds of websites run on one physical server, and each database connection consumes memory, file descriptors, and CPU time for the handshake and authentication. If one site opens 500 connections, it can exhaust the server's process table and starve every other site on the box. So the host sets a conservative limit, often between 20 and 50 for shared accounts, and makes it a hard boundary. You cannot raise it yourself because the host controls the global configuration file. On a VPS, you own the configuration, so the limit is typically higher, but it is still finite and tied to your allocated memory. Each MySQL connection can use several megabytes of RAM, so a VPS with 2 GB of memory might cap connections at 100 to avoid swapping.

The limit is not a penalty. It is a safety valve. If your application tries to open one connection per user request and you get a burst of traffic, you will hit the ceiling long before your CPU or disk becomes the bottleneck. The error message is often vague, so you might see a PHP warning like PDOException: SQLSTATE[HY000] [1040] Too many connections or a generic white page. The first step is always to check the server status as shown above, not to contact support and demand a higher limit.

Common causes and how to fix them

The most common cause is connection leakage. Your code opens a connection, runs a query, but never closes it. In languages with garbage collection, the connection stays open until the interpreter decides to clean up, which can be seconds or minutes later. In PHP, if you use the old mysql_connect() or a persistent connection like mysqli_pconnect(), the connection survives the request and is reused, but if you open a new one on every request without reusing the pool, the count climbs. The fix is to use a connection pool or a singleton pattern. For example, in PHP with PDO, you can store the connection in a static variable so it is created once per process:

function get_db() {
    static $pdo = null;
    if ($pdo === null) {
        $pdo = new PDO('mysql:host=localhost;dbname=mydb', 'user', 'pass');
    }
    return $pdo;
}

Another common cause is using a connection per request in a long-running worker, such as a cron script or a queue consumer. If that script loops 1000 times and opens a new connection each iteration without closing it, you will exhaust the limit quickly. Add $pdo = null; at the end of each iteration, or better, reuse the same connection for the whole loop.

On the server side, you can also reduce the pressure by tuning wait_timeout and interactive_timeout so idle connections are closed faster. The default is often 8 hours, which is absurd for a web application. Set it to 60 seconds or 120 seconds. On MySQL, you can do this without restarting:

SET GLOBAL wait_timeout = 60;
SET GLOBAL interactive_timeout = 60;

That change is temporary and resets on restart, so you should also add it to your configuration file, usually my.cnf under the [mysqld] section. On PostgreSQL, you would edit postgresql.conf and set idle_in_transaction_session_timeout to a few seconds.

What to do when you hit the limit

If you are on shared hosting and you keep hitting the limit even after fixing your code, you have three options. First, look at your query patterns. Are you running long queries that hold connections open? Use SHOW PROCESSLIST; to see what is actually connected. If you see many connections in Sleep state, that is a leak. If you see many in Query state, you have a slow query problem. Second, consider moving the database to a separate service, such as a managed database instance, which gives you a dedicated connection limit that is not shared with other tenants. Third, if your application genuinely needs hundreds of concurrent connections, you should move to a VPS or a dedicated server where you control max_connections and can raise it, but only after you have verified your memory can handle it.

For VPS users, raising the limit is trivial but dangerous. Edit your configuration, set max_connections to a higher value, restart the database, and watch memory usage. A safer approach is to use a connection pooler like pgbouncer for PostgreSQL or ProxySQL for MySQL. These tools sit between your application and the database, multiplexing many client connections onto a small number of real database connections. You can then keep the database limit low and let the pooler handle the burst. That is the architecture used by most production systems, and it is the right answer for any application that expects traffic spikes.

Your next step is to run the diagnostic commands from this article on your current server and write down the numbers. Check max_connections, Threads_connected, and the number of sleeping connections. Then look at your application code for any place where you create a connection inside a loop or a function that is called frequently. Fix those two things before you ask your host for a higher limit. If you still fail, search for connection pooler documentation for your database and consider moving to a VPS where you own the tuning knobs.