Postgres with QUIC
4 hours ago
- - TCP connection pooling to Postgres is bottlenecked by client-side network latency: with a 10-connection client pool over a 30ms WAN, only ~333 QPS can be dispatched, regardless of database speed.
- - The PostgreSQL wire protocol is synchronous per connection: one connection supports only one in-flight query or transaction, preventing concurrency on a single TCP socket.
- - Opening thousands of raw TCP sockets to solve the problem causes file descriptor exhaustion (EMFILE), high kernel memory usage, slow connection setup (TCP+TLS handshakes), and TCP head-of-line blocking.
- - QUIC (over UDP) provides lightweight, multiplexed bidirectional streams that don't consume kernel sockets or file descriptors, enabling thousands of concurrent queries across just a handful of physical connections.
- - Benchmark results: under identical heavy load, QUIC sustained 9,718 QPS at ~246ms average latency, while TCP collapsed with 40,000+ backlogged queries and latency spiraling to over 7,000ms.
- - QUIC does not fix multi-statement transactions: open transactions still pin a physical Postgres backend connection, so transport multiplexing only helps single-statement or auto-commit workloads.
- - QUIC is most valuable for edge-to-centralized database traffic, microservice fleets, and unreliable WAN links; it's less relevant for co-located monoliths, heavy analytical queries, or chatty multi-statement transactions.
- - The implementation required no PostgreSQL wire protocol changes: tokio-postgres can run over an s2n-quic bidirectional stream, and the modified PgCat pooler maps incoming QUIC streams into its transaction pooling state machine.