Connection pooling

Opening a database connection is expensive and each one uses server memory. A pool such as PgBouncer shares a few connections among many application threads, so adding app servers does not exhaust the database.

Where it shows up in real systems

  • Relational database

    The primary handles every write; read replicas add read capacity but lag slightly behind, so a user may not see their own write. A Multi-AZ standby takes over in about a minute if the primary fails. Sharding multiplies write capacity, but a bad shard key creates a hot shard. Without connection pooling, many app instances exhaust the connection limit.

    In production: PostgreSQL (Amazon RDS, Aurora), MySQL, Azure SQL Database, Cloud SQL, Citus, Vitess

  • Database connection proxy

    Place it between your services and a relational database. Serverless functions and large fleets open far more connections than a database can hold; the proxy multiplexes them and also shortens failovers by holding connections while the standby takes over.

    In production: PgBouncer, Amazon RDS Proxy, ProxySQL, Odyssey, Supavisor

See it break, then fix it

Build an architecture, send it a day of traffic and outages, and learn why it holds or fails. Free to start.

Open the learning path Open the sandbox