Back to roadmap
Module 6 · Relational Data at ScaleDay 05620 min

Connection Pooling

Connections are expensive — share them.

← PreviousNext →
Day 056

Connection Pooling

App
service
Pool
edge
pgBouncer
edge
Postgres
datastore
Signal path
App pool + edge pooler
App
service
flow
Pool
edge
Pool
edge
flow
pgBouncer
edge
pgBouncer
edge
flow
Postgres
datastore
Memory hook

Connection Pooling: connections are expensive

Mental model

shape data so reads and writes stay honest

Design lens

Transaction-mode pooler doesn't support session features (prepared statements, ad...

Recall anchors
App poolEdge poolerTuning

Why it matters

Each DB connection costs memory and a backend process; thousands of connections kill Postgres. Pool at the app and/or with a dedicated pooler so the DB sees a small, steady connection count.

Deep dive

Postgres backend ≈ 5–10 MB; 10k connections = 50–100 GB.

App pool size ≈ N_app × pool_per_instance, plus headroom.

Transaction-mode poolers (pgBouncer) multiplex many app connections onto few DB ones.

Demo / scenario

Lambda fleet exhausting Postgres connections.

  1. 1000 concurrent lambdas → 1000 DB connections.
  2. Add RDS Proxy.
  3. DB sees 100 connections, multiplexed.
  4. p99 stable; no more 'too many connections' errors.

Tradeoffs

  • Transaction-mode pooler doesn't support session features (prepared statements, advisory locks).
  • Bigger pool → contention, OOM.
  • Smaller pool → starvation under spikes.

Diagram

App
Pool
pgBouncer
Postgres
App pool + edge pooler.

Mind map

Check yourself

Loading quiz…

Sources & further reading

← PreviousNext →