Features

The Percona Operator for MongoDB is a Kubernetes-native controller that automatically manages the full lifecycle of Percona Server for MongoDB clusters. The Operator offloads your teams from manual day-to-day database management so you can focus on building applications and running the platform.

Core capabilities

Here is what the Operator brings to your infrastructure:

High availability and failover

MongoDB’s built-in high availability — Replica sets and sharding give you data redundancy and automatic failover at the database layer. A replica set uses elections to promote a new primary when the current one fails, with no manual intervention. With sharding, data is distributed across shards (each shard is a replica set), and mongos routes traffic. Both topologies are designed for availability and scale.

What the Operator adds — The Operator runs these topologies reliably in Kubernetes:

• Pod distribution — Use anti-affinity rules to spread replica set members (and optionally arbiters) across nodes so a single node failure does not take down multiple members.
• Health and rescheduling — If a node or Pod fails, Kubernetes reschedules the workload; the replica set reconnects and continues serving traffic.
• Rolling upgrades — Upgrade the Operator and Percona Server for MongoDB with minimal or no downtime.
• Multi-cluster and multi-region — Use multi-cluster or multi-region deployments (including Multi-cluster Services (MCS) where supported) for disaster recovery, cross-site replication, and migration. You can replicate data across clusters or regions so that if one site fails, another can serve traffic.

Automated backup and restore flows

Protect your data with Percona Backup for MongoDB (PBM), which runs as a sidecar in your database Pods:

• Scheduled backups — Configure scheduled backups with remote storage (S3, GCS, Azure, MinIO, or a file server) and retention policies.
• On-demand backups — Create a backup at any time for critical operations.
• Logical and physical backups — Use logical backups for portability or physical backups (including physical incremental) for faster restore on large datasets.
• PVC snapshots to boost your backup and restore performance.
• Point-in-time recovery — Store oplog and restore to a point in time.
• Restore — Restore on the same cluster or a new cluster; replica set name remapping is supported when needed.

Automated scaling and resource management

Scale your database infrastructure as demand grows:

• Horizontal scaling — Add replica set members or scale shards and mongos when sharding is enabled.
• Vertical scaling — Adjust CPU and memory limits in the PerconaServerMongoDB custom resource.
• Storage expansion — Expand PersistentVolumeClaims for database volumes when your storage class supports it.
• Pod placement — Use affinity and anti-affinity to control which nodes run MongoDB Pods, arbiters, or mongos.

Security and compliance

Keep your data and backups secure with built-in options:

• Transport encryption — Enable TLS for client and server; use cert-manager or custom certificates.
• Data-at-rest encryption — Encrypt MongoDB data on disk.
• Users and roles — Manage application users and system users; optionally use Vault for system user credentials.
• Backup encryption — Encrypt backups in object storage.

Monitoring and observability

Gain visibility into your database and cluster:

• Percona Monitoring and Management (PMM) — Integrate PMM via sidecar for metrics, query analysis, and dashboards.
• Kubernetes monitoring — Monitor the Kubernetes layer alongside the database.
• Logging — Configure persistent logging and log rotation.
• Custom options — Tune MongoDB options and PBM options via the custom resource.
• Sidecars — Add sidecar containers (e.g. custom exporters or tools) to replica set, config server, or mongos Pods.

How the Operator works

The Operator extends Kubernetes with a custom resource that represents your MongoDB cluster’s desired state.

Here is what happens under the hood:

1. You define your cluster in a PerconaServerMongoDB custom resource (replica set or sharded cluster, size, storage, backups, and so on).
2. The Operator watches for changes and reconciles the actual state with your desired state.
3. Kubernetes resources are created and updated automatically: StatefulSets, Services, Secrets, PersistentVolumeClaims, and PBM configuration.
4. The cluster self-heals when Pods or nodes fail: Kubernetes reschedules Pods, and the replica set holds elections to choose a new primary.
5. Updates and scaling happen when you change the custom resource; the Operator applies the changes in a controlled way.

This declarative approach means you describe what you want, and the Operator handles the orchestration so your database cluster matches your specification.

Explore the architecture Compare with other solutions

Next steps

Get up and running in minutes, whether you build and application or need to deploy and operate the database.

Get started

---

Last update: March 23, 2026
Created: March 23, 2026