A certificate was about to expire, and nobody knew.
The connection would have gone dark within hours. In a Postgres deployment running at scale, that’s how fast trust can vanish. Certificate rotation in Postgres is not just a box to check—it is a precision task that keeps your binary protocol connections alive, secure, and uninterrupted. When a certificate expires without a fresh one in place, every client using TLS is locked out. Queries fail. Transactions hang. And the clock keeps ticking.
Postgres binary protocol proxying adds another layer. A proxy that speaks the binary wire protocol gives you flexibility—routing, load balancing, traffic shaping—but it also becomes part of the trust chain. Every certificate in that chain must be rotated with zero downtime. That means both server and client certificates. It means synchronizing changes across proxies, replicas, and any connection poolers. It means no hand-edited config files in the middle of a failing connection storm.
A sound rotation strategy begins with automation. Your proxy should reload new certificates without stopping. Postgres itself can swap certificates, but most deployments hide Postgres behind a proxy. That proxy must support hot reloading and smooth failover during rotation. If not, your “secure connection” becomes a point of failure. The binary protocol is unforgiving—if the encrypted handshake fails, there is no fallback.