Stateful Workloads on Kubernetes in 2026: CloudNativePG, KubeBlocks, and the Operator Generation

“Do not run stateful workloads on Kubernetes” was sound advice in 2019. By 2026 it is wrong for most workloads. Operator quality, CSI driver maturity, and the operational learnings that crystallized across the CloudNativePG, KubeBlocks, StackGres, and Strimzi projects have made Kubernetes a genuine production home for Postgres, MySQL, MongoDB, Redis, Kafka, ClickHouse, and Pinot. The teams running these patterns in production — Tembo, Crunchy, EDB, Aiven, Confluent, StreamNative, Percona and their customers — have eliminated most of the early failure modes.

This is the senior-engineer view of what actually works for stateful Kubernetes in 2026.

Why the picture changed#

Four things matured in parallel between 2022 and 2025:

• Operators got real. CloudNativePG, KubeBlocks, StackGres, Strimzi, Apache Pinot’s operator, the MongoDB Community and Enterprise operators, the Redis Operator family — these are now genuinely production-grade. They handle backup, restore, point-in-time recovery, failover, version upgrade, scale-out, scale-in, and observability with discipline that ad-hoc StatefulSet scripts cannot match.
• CSI matured. EBS CSI, GCE PD CSI, Azure Disk CSI, Longhorn, OpenEBS, Rook-Ceph, and Portworx have all stabilized. VolumeSnapshots, ResizeVolume, and topology-aware provisioning are routine. The early “volume gets stuck on a dead node” failures have been mostly engineered out.
• Network and DNS got predictable. CoreDNS tuning, NodeLocal DNSCache, Cilium kube-proxy replacement, and the broader CNI ecosystem produced stable low-latency networking for stateful workloads that historically lost to chattiness.
• Talos and immutable nodes arrived. Talos OS (Sidero Labs) replaced the “general-purpose Linux node” model with a minimal immutable Kubernetes-purpose OS. For stateful workloads where node-level reliability matters, this is a real upgrade.

Postgres on Kubernetes: CloudNativePG, StackGres, KubeBlocks#

Postgres is the workload most often asked about. The honest 2026 answer is “yes, with the right operator.” The three serious choices:

CloudNativePG (CNPG) is the EDB-sponsored CNCF Sandbox project (graduated to Incubation in 2025) and is the most widely deployed Postgres operator on Kubernetes today. Strong primary-replica setup, streaming replication, point-in-time recovery via Barman, pgBouncer integration, declarative upgrades. We deploy CNPG by default on greenfield Kubernetes Postgres projects.

StackGres by OnGres is a more comprehensive Postgres-on-K8s distribution with a deeper feature surface (Patroni-based HA, integrated Envoy proxy, Citus extension support, built-in monitoring). Heavier to operate but more featureful. Right pick for teams that want a more managed-database feel.

KubeBlocks by ApeCloud is a multi-engine operator (Postgres, MySQL, Redis, MongoDB, Kafka, ClickHouse) with a unified operational model. Strong fit for platform teams that want one operator family across multiple data engines. We use KubeBlocks at clients who want platform consolidation across many engines.

The production-readiness signals: CNPG runs the production Postgres for the Italian government’s healthcare data infrastructure, multiple European banks, and a number of major SaaS vendors. The “Postgres on K8s does not work” objection in 2026 is roughly five years stale.

Strimzi for Kafka#

Kafka on Kubernetes has been credible since 2020 via Strimzi (the CNCF project, originally Red Hat-sponsored). By 2026 it is the default for new Kafka deployments at any organization already running Kubernetes. Confluent’s Kafka operator and StreamNative’s Pulsar operator are the commercial alternatives.

What works: KRaft mode (no Zookeeper) has been the default since Strimzi 0.40 and is mature; the Topic Operator and User Operator handle declarative topic and ACL management cleanly; the Connect Operator manages Kafka Connect deployments; MirrorMaker 2 handles cross-cluster replication. Strimzi’s broker rolling upgrades are clean.

What still requires care: disk performance is the dominant variable. Kafka brokers on a local SSD or a high-IOPS network disk (gp3 with provisioned IOPS, GCP pd-ssd, Azure Premium SSD v2) perform well. Kafka brokers on default network-attached storage do not. Sizing is the engineering work.

Apache Pinot and the analytics operator wave#

Pinot’s operator landed for real-time analytics on Kubernetes. ClickHouse Operator (Altinity), Druid Operator, and Trino Operator handle the other major analytics engines. The pattern: the operator handles cluster lifecycle, scaling, and rolling upgrades; the data lives on object store (S3, GCS) or fast local disk depending on the engine; the team writes queries.

This is the workload class where Kubernetes-native operators arguably outperform managed services for self-aware platform teams. ClickHouse Cloud and Aiven for Pinot are excellent managed offerings; for teams with existing K8s platforms and a real ops capacity, the operator-on-K8s pattern matches the managed service feature-for-feature at meaningfully lower cost.

VolumeSnapshots and the CSI ecosystem#

VolumeSnapshots and VolumeSnapshotContents (the CSI snapshot CRDs) are now production-ready across all major CSI drivers. The pattern that works:

• Schedule snapshots via Velero, Kasten K10, or the cloud-native snapshot scheduler (AWS Data Lifecycle Manager, GCP Snapshot Schedules).
• Use VolumeSnapshotClass to control snapshot retention and storage class.
• For cross-region or cross-account DR, replicate snapshots via cloud-native replication or Velero.
• For point-in-time recovery on databases, the snapshot is the floor; the database operator’s PITR via WAL archiving is the ceiling.

Combined with the database operator’s backup story, the modern Kubernetes data-platform recovery posture is genuinely competitive with managed services.

Talos and Sidero#

Talos OS replaced the “general-purpose Linux node” with a minimal Kubernetes-only immutable OS. No SSH; configuration via API; the node is essentially a Kubernetes appliance.

For stateful workloads, this matters because node-level reliability is the dominant failure mode. A Talos node does not drift from configuration; it does not accumulate cruft; it does not get patched by a misbehaving CM tool. Sidero Omni (the management plane) handles fleet operations cleanly.

We deploy Talos at clients who want a serious production posture without paying for a managed Kubernetes service that abstracts away the node entirely. It is also a strong fit for on-prem and edge deployments.

The honest tradeoffs#

Where Kubernetes-stateful is the right call:

• Existing strong Kubernetes platform with platform-engineering capacity.
• Need multi-cloud or hybrid portability.
• Cost-sensitive at meaningful scale (managed-service margins add up).
• Want unified operational model across data engines.

Where managed services are still the right call:

• Small team without K8s platform expertise.
• Workload-specific managed features that matter (Aurora’s serverless v2, Spanner’s global consistency, BigQuery’s pricing model).
• Compliance posture where the managed service’s audit certifications shortcut the review.
• Low-volume workloads where the managed-service unit cost is amortized.

We routinely deploy both shapes for the same client based on workload.

The Postgres-on-Kubernetes failure modes we still see#

Even with mature operators, teams find new ways to mis-deploy:

• Wrong storage class. Postgres on gp2 instead of gp3 with provisioned IOPS; or on hyperdisk-balanced instead of pd-ssd. The performance gap is meaningful.
• No backup verification. Backups are configured; nobody verifies restores quarterly. The first time the team finds out the backup is broken is during an incident.
• Single AZ deployment “to save cross-AZ cost.” First AZ outage takes the database with it. The cross-AZ replication cost is a fraction of the cost of an unplanned downtime.
• Forgetting connection pooling. PgBouncer or pgpool is required at any nontrivial connection count. Application teams hammer the database with raw connections, run out of slots, and blame the platform.

Modern operators catch most of this if you configure them correctly. They cannot rescue you from skipping the configuration.

How we deploy stateful workloads in 2026#

For client engagements, the typical shape:

• Postgres: CloudNativePG on K8s for new deployments. RDS or Aurora for legacy workloads where the migration cost is not justified.
• Kafka: Strimzi by default on K8s. MSK or Confluent Cloud where the team does not have ops capacity.
• Analytics engines: ClickHouse Operator or Pinot Operator on K8s for self-managed; ClickHouse Cloud or Aiven where the managed unit economics make sense.
• Redis: Redis Operator family on K8s for cache layers; ElastiCache or Memorystore for simpler use cases.
• MongoDB: Community or Enterprise Operator on K8s; Atlas where it fits.
• Nodes: Talos OS where the team is committed to immutable-node discipline; otherwise a hardened modern Linux base (Bottlerocket, Flatcar) on managed K8s.

For the broader Kubernetes shape, see our Kubernetes production patterns piece, the GPU scheduling on Kubernetes take, and the related Helm vs Kustomize piece.

Where pdpspectra fits#

Our DevOps and CI/CD and cloud infrastructure practices design and operate stateful Kubernetes platforms across the major data engines. We have shipped Postgres-on-K8s for healthcare and banking clients where data residency and platform consolidation justified the operator path.

Related reading: Kubernetes production patterns, GPU scheduling on Kubernetes, and Helm vs Kustomize.

---

Stateful on Kubernetes works in 2026 — with the right operator and the right discipline. Talk to our team about your data platform.