Intermittent Doctrine DBAL Connection Pool Exhaustion in Shopware 6

Addressing Connection Pool Exhaustion

In Shopware 6, Doctrine DBAL does not maintain a global application-level connection pool. Instead, each PHP-FPM worker process establishes its own connection to the database. Exhaustion occurs when the total number of concurrent PHP-FPM workers exceeds the database server's max_connections limit, leading to 502/503 errors.

Analysis of Connection Behavior

To answer your specific technical constraints:

• Concurrent Process Support: Because there is no shared pool across workers, a "5-connection pool" (if configured via a specific driver) typically applies only to the internal state of a single process. In a standard Shopware setup, 1 PHP-FPM worker = 1 database connection. Therefore, the maximum number of concurrent processes is limited by your database server's max_connections setting, not a Doctrine config value.
• Persistent Connections: Enabling PDO::ATTR_PERSISTENT in doctrine.yaml can reduce the overhead of the TCP handshake. However, in shared hosting or high-traffic environments, this often accelerates exhaustion. Persistent connections are not closed when the request ends; they stay open for the worker. If you have 50 workers, you will have 50 permanent connections regardless of actual traffic. This does not typically cause stale data, but it can lead to "Too many connections" errors more quickly.
• Scaling in Docker/FPM: Each PHP-FPM worker and each Docker container maintains its own independent connection. There is no global pool shared across containers. If you scale to 3 containers with 20 workers each, your database must support at least 60 concurrent connections.

Recommended Resolution Steps

1. Align FPM and DB Limits: Ensure your database max_connections is higher than the sum of all pm.max_children across all PHP-FPM pools and containers.
2. Audit Long-Running Processes: Check Shopware message queue consumers. If consumers are not restarted periodically, they may hold idle connections. Use the --memory-limit or --time-limit flags on the messenger:consume command.
3. Optimize Transaction Scope: Ensure no external API calls are made inside a Doctrine transaction, as this holds the connection open while the process waits for a network response.
4. Monitor Active State: Run the following command during a load spike to identify "Sleep" connections:

   SHOW PROCESSLIST;

Required Diagnostic Detail

To refine this recommendation: What is the current max_connections value on your database server and the total pm.max_children across all PHP-FPM nodes? If the FPM limit is higher than the DB limit, the issue is a configuration mismatch rather than a Doctrine pool leak.