Doctrine DBAL connection reuse limits with PDO persistent connections

Answers to the core questions

1. Does DBAL open the underlying PDO connection lazily on first use and reuse the same instance for the lifetime of the request?
   Yes. A Doctrine DBAL Connection holds a PDO object that is only instantiated when the first query is executed (or when connect() is called explicitly). After that, every call to executeQuery, prepare, or any other method that requires a database connection will use the same PDO instance until the request ends or the connection is closed manually.
2. What documented limits or interactions exist when PDO persistent connections are enabled with PHP‑FPM workers?
   Enabling PDO persistent connections causes PHP to keep the PDO instance alive across requests within the same worker process. Doctrine itself does not control the number of persistent connections; the limits are governed by:
   • pdo_mysql.max_persistent (or the equivalent for the driver) – maximum number of persistent connections per PHP worker.
   • PHP configuration for max_lifetime of a persistent connection.
   • Database server’s max_connections setting – each persistent connection counts as a live DB session even when idle.
   Because PHP‑FPM spawns multiple worker processes, the total number of persistent connections is roughly workers × max_persistent. If this product exceeds the database’s max_connections, new requests will block or fail.
3. How does the absence of an application‑level pool affect connection count behavior under concurrent requests?
   Doctrine does not implement its own connection pool. Each PHP‑FPM worker creates (or reuses) its own PDO instance per request. Therefore, for N concurrent requests handled by M workers, the database may see up to N × M concurrent connections (minus those that are idle or reused). This can quickly exhaust the database’s max_connections if many workers are active or if persistent connections are left open across requests.

Underlying behavior and practical limits

• Lazy opening – No connection is created until a query is executed. This is why you can safely instantiate an EntityManager in code that may never hit the database; the underlying PDO stays closed until needed.
• Connection reuse within a request – The same PDO instance is reused for all subsequent operations. Closing the EntityManager does not close the PDO until the request terminates.
• Persistent connections – When PDO::ATTR_PERSISTENT is set, PHP keeps the socket open across requests. Doctrine merely passes the flag to PDO; it does not track or limit the number of persistent sockets.
• Impact of PHP‑FPM worker count – Each worker can maintain its own pool of persistent connections. With workers = 10 and pdo_mysql.max_persistent = 5, you could have up to 50 persistent connections live at once.
• Database max_connections – This is the hard cap. If the sum of active connections across all workers exceeds this value, new connection attempts will fail with “Too many connections” errors.

Practical verification steps

1. Enable Doctrine’s SQL logger and run a request that performs a query. Verify that the PDO connection is established only at that point.
2. Inspect the database’s process list (SHOW PROCESSLIST on MySQL) after a burst of requests. Count how many distinct connections belong to your application’s user.
3. Run a stress test that spawns many PHP‑FPM workers and issues concurrent requests. Compare the observed connection count to the configured max_connections.
4. Within a single request, create two separate Connection instances and confirm that each opens its own PDO (persistent or not) by checking the process list or using Doctrine’s debug tools.

Key take‑aways

• Doctrine DBAL opens the underlying PDO lazily and reuses it for the request’s lifetime.
• Persistent connections are controlled by PHP/PDO settings, not Doctrine. They can reduce handshake overhead but may accumulate across workers.
• Because Doctrine does not pool connections, concurrent requests handled by different workers can multiply the number of live database sessions, potentially hitting max_connections.
• Avoid opening multiple Connection objects in a single request unless you have a specific need; it will increase the number of active connections.

What we still need to know

To fine‑tune your environment, could you share the current values of pdo_mysql.max_persistent and the database’s max_connections for your deployment?