PGDay UK2026

CloudNativePG has made running PostgreSQL on Kubernetes reliable and production-ready. It provides high availability, streaming replication, and automated failover. This however, adds a lot of moving pieces, which makes performance tuning an even larger challenge. Most PostgreSQL tuning advice assumes a static server: a fixed amount of RAM, predictable CPU access, direct edits to postgresql.conf, and a primary that never moves. None of those assumptions hold in a CloudNativePG cluster, where PostgreSQL runs inside Pods with strict resource limits, configuration is declarative, and the primary can change at any moment. What exactly do you need to be aware of when tuning in this dynamic environment? What are the new risks—and the automated possibilities? In this talk, I share a case study on tuning a highly available CNPG cluster without guesswork or downtime. We will move beyond "safe" defaults to address the specific technical kinks of the CNPG stack: The Container Illusion: How Cgroup limits change the fundamental math for memory and parallelism. Operator-Led Optimization: Applying configuration safely via the CNPG operator without restarts or configuration drift across replicas. HA-Aware Tuning: Handling primary failovers mid-session without corrupting measurement results or losing cluster stability. Dynamic Planning: Why statistics and planner behavior matter more in shifting, containerized environments. Using a 3-instance cluster and a realistic stress workload, we validated this methodology with automation (eliminating human error and accelerating iteration). The result: 4.5× improvement with zero downtime. Whether you apply this manually or with tooling, the principles remain the same.

Attendees will leave with a repeatable, data-driven blueprint for tuning PostgreSQL responsibly on Kubernetes.