PATTERN Cited by 1 source

Connection pooler as separate deployment

Statement

Run the connection pooler as its own Kubernetes Deployment, fronted by a dedicated Service, spread across availability zones for availability — rather than colocating it with the database or embedding it in the application.

This is the default shape Zalando's Postgres Operator chose for PgBouncer in release 1.5: "Postgres Operator creates a single connection pooler deployment and exposes it via new service."

When to use it

• Standard cloud-native Postgres deployments where the pooler is one more autonomous workload managed by an operator.
• Stateless-pooler workloads — PgBouncer processes are cheap to replace, kill, restart. Horizontal scaling is the primary knob.
• Mixed AZ environments where the pooler must stay available if one AZ fails.

Why it works

• Independent scaling: pooler replicas scale on their own schedule, driven by CPU pressure or connection demand, not tied to Postgres lifecycle.
• Independent lifecycle: rolling pooler upgrades don't touch the database; rolling database upgrades leave the pooler's connections in place.
• Stateless + lightweight: pooler pods have no persistent state; restart is cheap (<100 MB memory, transaction-state- ephemeral).
• Fits Kubernetes primitives cleanly: Deployment + Service is the idiomatic shape.

Trade-off: latency variability

The deployment-spread model introduces latency variability from three sources:

1. AZ-spread adds inter-AZ network latency — a pooler pod in AZ-a talking to a Postgres primary in AZ-b pays the cross-AZ RTT on every query.
2. iptables kube-proxy distributes non-uniformly — some pods get more load and slow under pressure.
3. Kubernetes scheduler may land pods on shared hyperthreads, triggering softirq contention.

For workloads that can't tolerate this variability, the patterns/big-pooler-affinity-plus-small-pooler-ha pattern is the operator-documented escape hatch.

Instances

• systems/zalando-postgres-operator (release 1.5, 2020) — first pattern instantiation on this wiki.

Seen in

• sources/2020-06-23-zalando-pgbouncer-on-kubernetes-minimal-latency — canonical walk of the pattern plus its latency trade-offs, with the paired escape hatch pattern for edge cases.

Related

• systems/zalando-postgres-operator · systems/pgbouncer · systems/kubernetes · systems/postgresql
• patterns/big-pooler-affinity-plus-small-pooler-ha — the escape hatch when latency variability is unacceptable.
• patterns/two-tier-connection-pooling — stacks on top of this pattern when pool depth exceeds a single pooler layer.