In 2025, the Percona Operator for MongoDB targeted on the toughest components of working MongoDB in Kubernetes: dependable backups and restores, clearer conduct throughout elections and restores, higher observability at scale, and safer defaults as MongoDB 8.0 grew to become mainstream. The 12 months included actual course corrections, similar to addressing PBM connection leaks and being specific about when to not improve. The result’s an Operator that’s extra clear about its ensures and higher fitted to multi cluster, multi area, and compliance pushed environments.
For a lot of groups, 2025 was not about studying Kubernetes or MongoDB for the primary time. It was about working extra clusters with fewer individuals, assembly stricter safety and compliance expectations, and anticipating routine operations to remain routine.
Group conversations mirrored that shift. Questions had been much less about “how do I deploy” and extra about:
- “How do restores behave underneath stress?”
- “What occurs throughout elections when nodes are drained?”
- “How do I see what the operator is definitely doing throughout many clusters?”
So let’s see how Percona addressed these and plenty of different requests to ship greatest on a market open supply kubernetes operator for MongoDB 😉
Backups and restores grew to become extra versatile and fewer nerve-racking
Early within the 12 months, with model 1.19.0 launched in January, the Operator expanded its storage flexibility in two necessary methods. Along with including filesystem based mostly backups over NFS as a tech preview, it additionally launched extensibility for PVC resizing to work with exterior autoscalers. Collectively, these modifications addressed frequent realities in restricted or extremely regulated environments the place S3 suitable object storage is probably not out there and the place storage development must be dealt with dynamically with out handbook intervention.
That very same launch additionally eliminated a long-standing limitation by permitting backups in unmanaged duplicate clusters, which simplified catastrophe restoration designs that depend on secondary or distant clusters.
In Might, model 1.20.0 targeted closely on backup workflows. Level-in-time restoration was improved so restores may very well be carried out from any configured storage with out ready for cluster reconfiguration. This lowered friction in environments that rotate or separate storage by function.
Incremental bodily backups had been additionally launched round this time as a tech preview. The motivation was easy: smaller backups, quicker completion, and higher restoration time aims for bigger datasets. The boundaries had been saved specific, together with the requirement for a base backup and a single storage location for the backup chain.
Throughout the 12 months, restore conduct was refined based mostly on real-world utilization, particularly round balancer dealing with and PBM integration. These modifications made restores extra predictable, even when they weren’t at all times seen as “new options.”
MongoDB 8.0 grew to become simpler to undertake with confidence
Help for Percona Server for MongoDB 8.0 arrived in the beginning of the 12 months and matured steadily over subsequent releases. By October, MongoDB 8.0 grew to become the default model for brand spanking new clusters, reflecting rising confidence in its stability and readiness.
Alongside the way in which, the Operator tailored monitoring roles, backup logic, and restore conduct to match MongoDB 8.x expectations. One notable addition was persistent cluster stage MongoDB logging by means of the logcollector configuration. This made debugging and day two operations considerably simpler by guaranteeing logs survive pod restarts and are accessible on the cluster stage relatively than being tied to particular person containers.
The online outcome was not simply “help for a brand new model,” however a clearer path to adopting it with out rewriting operational playbooks.
Multi-cluster and multi-region operations felt extra intentional
As extra groups ran MongoDB clusters throughout namespaces, areas, and even a number of Kubernetes clusters, operational readability grew to become extra necessary than uncooked performance.
Mid-year enhancements made it simpler to provide clusters significant names in monitoring, so PMM dashboards stayed readable even in complicated environments. This small change lowered confusion throughout incidents, the place figuring out the precise cluster shortly issues.
Later within the 12 months, concurrent reconciliation was launched so a single Operator occasion might handle a number of clusters extra effectively. As a substitute of updates queueing behind each other, reconciliation may very well be tuned to match the size of the atmosphere.
CRDs additionally gained clearer model labeling, making it simpler to confirm {that a} given CRD definition is according to the Operator model working within the cluster. This helped groups keep away from delicate mismatches when newer Operator variations launched up to date or expanded CRD schemas, significantly throughout upgrades and audits.
Reproduction set conduct received calmer and extra predictable
A number of enhancements all year long targeted on lowering surprises round elections and topology.
Early on, the Operator added help for manually adjusting duplicate set member precedence, giving groups extra management throughout upkeep or deliberate failovers.
Later within the 12 months, hidden nodes grew to become out there. These nodes maintain full copies of information with out serving consumer site visitors, making them helpful for backups or reporting workloads.
Collectively, these modifications helped align the Operator extra carefully with how MongoDB is definitely operated in manufacturing environments.
Safety and entry administration grew to become less complicated
Safety-related enhancements in 2025 targeted on lowering handbook work relatively than including complexity.
Computerized password technology for customized MongoDB customers allowed groups to declare customers immediately within the Customized Useful resource and let the Operator deal with secret creation safely.
Help for IAM roles for service accounts lowered the necessity to handle long-lived credentials for cloud storage entry, aligning higher with fashionable cloud safety practices.
These modifications quietly eliminated a variety of customized scripting across the Operator.
What we discovered as a group
Just a few themes got here up time and again, and many of the work in 2025 adopted immediately from these classes.
- Restore correctness issues greater than restore velocity
- Clear boundaries are higher than hidden automation
- Observability must scale with the variety of clusters, not simply the dimensions of 1
- Making tradeoffs specific builds extra belief than pretending they don’t exist
What’s subsequent
2025 was about making the Percona Operator for MongoDB really feel much less shocking and extra reliable. Trying forward, the priorities stay intentionally sensible and targeted on manufacturing realities.
Backup and restore workflows will proceed to be hardened, together with help for backups utilizing PVC snapshots. This opens the door to quicker and extra storage native restoration paths, particularly in environments the place snapshot based mostly workflows are already normal.
Storage automation will advance additional with automated PVC resizing, lowering handbook intervention as datasets develop and making it simpler to pair the Operator with exterior autoscalers.
Credential administration is one other space of lively funding. Integrating Vault for system consumer credential administration will assist groups standardize secrets and techniques dealing with and align MongoDB operations with broader safety and compliance practices.
Restore workflows may even change into extra versatile with deliberate help for duplicate set remapping throughout restores. This may make it simpler to recuperate into totally different topologies, areas, or cluster layouts with out requiring put up restore reconfiguration.
Throughout all of this, the guiding aim stays the identical. Make MongoDB on Kubernetes simpler to function at scale, simpler to recuperate underneath stress, and simpler to belief when issues go unsuitable.
