Postgres with QUIC

Postgres’ frontend/backend protocol is synchronous per TCP connection - one active in-flight query ties up a socket - so client-side TCP pools become a hard bottleneck in distributed deployments where clients sit tens of milliseconds from the database. Traditional poolers protect the database from having thousands of backend processes, but they do not change the client-to-pooler hop: opening many TCP sockets exhausts file descriptors, kernel buffers, and client memory, producing huge request backlogs under surge. To break that wall, the Postgres protocol was run over QUIC: PgCat was modified to accept QUIC associations and multiplex hundreds of lightweight bidirectional streams so thousands of logical database queries share a small number of UDP connections (test used 50 QUIC connections × 40 streams = 2,000 streams vs. 500 TCP connections).

Under a controlled ramp from 100 to 5,000 QPS using very short (~0.5ms) queries, QUIC sustained 9,718 QPS at ~246ms avg latency while TCP collapsed into a backlog of ~40,000 queries with ~7,088ms latency; client memory with QUIC was ~91MB vs ~474MB for TCP. QUIC used more CPU due to user-space crypto but processed more than twice the throughput before queuing. The approach is recommended for edge-to-central DB traffic, large microservice fleets, and lossy WANs; it adds little value for co-located low-latency setups, very long-running analytical queries, or workloads dominated by multi-statement transactions.