StatefulSets in Production — PostgreSQL and Elasticsearch on Kubernetes

In 2017, we started with StatefulSets in beta. Today we run PostgreSQL clusters and Elasticsearch on Kubernetes in production. Two years of experience in one article.

PostgreSQL on Kubernetes¶

We use the Patroni operator for PostgreSQL HA. Three-node cluster: primary + 2 replicas. Automatic failover, streaming replication, point-in-time recovery from WAL archives in S3.

What works: automatic failover, backup scheduling, resource isolation. What’s challenging: storage performance tuning, major version upgrades (still a manual process), connection pooling (PgBouncer as a sidecar).

Elasticsearch on Kubernetes¶

Elastic Cloud on Kubernetes (ECK) operator. 3 master nodes, 3 data nodes, 2 coordinating nodes. Automatic scaling, rolling upgrades, snapshot backups.

The ECK operator is excellent — you define the desired state, the operator takes care of the rest. Upgrading Elasticsearch from 6.x to 7.x was done via rolling update with no downtime.

Lessons Learned¶

• Storage class matters: SSD (gp2/gp3) for databases, always
• Anti-affinity: replicas on different nodes/AZs
• Resource requests = limits for guaranteed QoS
• Test backups regularly — restore drill every month
• Monitoring: databases need specific metrics (replication lag, connections, locks)

When NOT on Kubernetes¶

Extremely performance-sensitive workloads (bare metal latency is still lower). Huge databases (TB+) with complex sharding. Legacy databases without a Kubernetes operator.

Stateful Workloads on Kubernetes Are Production-Ready¶

With a good operator, proper storage, and disciplined operations, it works. But respect the limits — not every database belongs in Kubernetes.