Postgres on Kubernetes usually works well enough — until the operator itself becomes part of the incident. The harder problems tend to show up in two areas that operator documentation rarely covers: troubleshooting incidents that cross multiple systems, and sizing the operator pod and its reconciliation behaviour.
This session draws on real cases from working on the Percona Operator for PostgreSQL. The specific incidents are tied to design choices we made and bugs we shipped; different operators will hit different problems. What generalises is the shape of the problem.
Key discussion areas:
Why debugging operator-managed Postgres often means debugging three systems at once: Kubernetes, the operator, and Postgres
Correlating operator logs, Postgres logs, controller state, and Kubernetes events into a single debugging workflow
Sizing the operator pod: CPU, memory, and how much work it is allowed to reconcile in parallel
Attendees will leave with practical knowledge for debugging operator-managed Postgres, a starting point for sizing operator, and a set of questions to ask before trusting any Postgres operator in production.
This session is intended for SREs, DBAs, and platform engineers running or evaluating Postgres on Kubernetes.
Event
Speaker card
