In 2025, the Percona Operator for PostgreSQL put most of its energy into the things that matter when PostgreSQL is running inside real Kubernetes clusters: predictable upgrades, safer backup and restore, clearer observability, and fewer surprises from image and HA version drift.
Backups and restores got more resilient and more controllable
In March, Operator 2.6.0 concentrated heavily on backup and restore behavior, an area where many production issues tend to surface.
Retry logic was added so transient network issues or short timeouts would not immediately cause backup jobs to fail and restart from scratch. Restore behavior became more configurable, allowing teams to fine-tune how WAL files are handled during recovery without modifying backup repositories directly.
An experimental cleanup finalizer was also introduced for teams that want automatic backup removal when clusters are deleted, while keeping it optional and clearly scoped.
These changes are not flashy, but they target the failure modes that show up in incident reviews: backups that silently stop, restores that stall, and workflows that only work when everything is perfect.
Observability moved closer to “works across real org shapes”
Operator 2.7.0 on July 18, 2025, added native PMM 3 support while keeping PMM 2 compatibility. It also added ways to name clusters in monitoring, so that multi-region, multi-namespace, and multi-tenant setups remain understandable in dashboards.
The same release leaned into practical operator controls: deeper Patroni configuration override options for troubleshooting, and improvements around user schema behavior and optional public schema access for non-superusers, which reduces friction when applications assume “default PostgreSQL” behavior.
Alongside these improvements, the team spent time validating pg_tde as a custom extension in real operator-managed environments and published guidance on how to use it safely. Those experiments were an important learning phase. They highlighted both what works and where operational complexity creeps in. Based on that experience, it is now clear that encryption at rest needs to move beyond custom wiring and toward more cloud native, operator-driven integration.
Fewer moving parts in the foundations
By late in the year, with Operator 2.8.0, several foundational choices were tightened.
The Operator standardized on Patroni 4 for high availability, reducing legacy complexity and ambiguity. PostgreSQL images transitioned to official Percona builds with explicit version support, improving predictability during patching and automation.
Support for huge pages made it easier to run memory-intensive workloads efficiently, while expanded S3 compatibility for custom extensions helped teams in nonstandard or restricted storage environments.
Status reporting also improved with the addition of observedGeneration, making it clearer when configuration changes had actually been applied.
More milestones: PostgreSQL 18 support and built-in pgvector
Operator 2.6.0 introduced built-in pgvector in the PostgreSQL images used by the Operator. This removed the need for custom extension installation steps and made it significantly easier for teams to enable vector search capabilities in a predictable, operator-managed way.
PostgreSQL 18 support arrived later, starting with Operator 2.8.1. With that release, teams could begin testing and adopting PostgreSQL 18 using the Operator, with packaging and defaults aligned to newer upstream expectations and without requiring changes to existing deployment workflows.
What is next
Looking ahead to Q1 2026, the focus shifts from individual features to deeper, opinionated integration that reflects how production teams actually run PostgreSQL on Kubernetes. One concrete example is making pg_tde a first-class citizen in the operator experience. It should not be something users have to wire in as a custom extension, but instead a built-in capability that aligns with expectations already set by other databases. PostgreSQL may not have native TDE today, but Percona does not approach this problem in isolation. Drawing on years of experience with MySQL and MongoDB, we understand how infrastructure teams expect encryption, key management, and Kubernetes workflows to behave, and we are well-positioned to apply those lessons to PostgreSQL.
Beyond TDE, more is to come. Reducing major version upgrade downtime with a clear path toward near-zero downtime upgrades is an active area of work. We are also investing in OIDC based authentication, faster availability of minor releases shortly after upstream, and smoother operational workflows overall. Another important goal is to lower friction for users coming from other ecosystems, including making it easier for teams currently using Crunchy Data to migrate to Percona, if and when they choose to.
If you take one thing away from this wrap up, let it be this. The operator is increasingly shaped around production behavior, not just feature checklists. That direction is deliberate. It only works because users surface real world sharp edges, and contributors turn that feedback into code, documentation, and disciplined releases. What’s next is less about adding one more feature and more about making PostgreSQL on Kubernetes predictable, secure, and boring in the best possible way.
