💻Postgres Connection Pooling Can't Fix Network Physics
Why your Postgres connections are bottlenecked
TL;DR
Postgres connection pooling can't solve network latency issues. Each query ties up a socket, limiting throughput to 333 queries/s. QUIC offers a potential fix with 0-RTT session resumption.
Postgres connection pooling doesn't fix network physics. Each query ties up a socket until the server responds, limiting throughput to 333 queries per second. This bottleneck affects any app connecting to Postgres over a WAN. QUIC, however, offers a potential fix with 0-RTT session resumption, reducing handshake penalties to near-zero.
Key Points
Postgres synchronous protocol ties up a socket per query until server responds, limiting throughput to 333 queries/s.
Opening 1,000 TCP sockets isn't viable due to file descriptor and buffer allocation overhead.
QUIC runs on UDP, providing natively multiplexed, independent bidirectional streams over a single connection.
QUIC streams don't create Linux kernel sockets or allocate file descriptors, reducing overhead.
QUIC supports 0-RTT session resumption via TLS 1.3 session tickets, reducing handshake penalties to near-zero.
Why It Matters
If you're running Postgres over a WAN, connection pooling won't fix the bottleneck. Each query ties up a socket, limiting throughput to 333 queries/s. However, QUIC offers a potential fix with 0-RTT session resumption, reducing handshake penalties to near-zero. This could be a game-changer for apps with high-latency Postgres connections.
Comments
Be the first to comment
Enjoyed this article?
Get it daily. 7am. Free. Reads in 5 minutes.
Join 3,549 builders reading daily.