Chapter 4:

Interrogating Kubernetes solutions

Kubernetes provides the platform for modernizing the data layer, but the operator you choose matters as much as the database itself. A basic operator might automate installation but leave your team managing backups, failovers, and upgrades manually. An enterprise-grade operator automates the full database lifecycle. The difference determines whether Kubernetes eliminates operational friction or simply relocates it.

A value proposition framework for enterprise-ready operators

Evaluating operators requires looking beyond feature lists to the business value they deliver. An enterprise-ready operator creates value across three strategic pillars:

Operational efficiency at scale: An operator's primary value is its ability to automate the complex and recurring Day 1 and Day 2 operations that consume the majority of an operations team's time. This includes automated high-availability clustering, seamless scaling, coordinated rolling upgrades, and, most critically, fully automated backup, restore, and disaster recovery procedures. This automation reduces headcount costs, eliminates human error, and allows a smaller platform team to manage a much larger and more complex data estate.
Risk mitigation and architectural freedom: A best-in-class operator must be portable, functioning on any CNCF-certified Kubernetes distribution, from public cloud services (EKS, GKE, AKS) to on-premises platforms (OpenShift, Rancher). This portability is a powerful risk mitigation tool. It allows the organization to execute a multi-cloud strategy, avoid vendor lock-in, and protect itself from a single provider's price increases or roadmap changes.
Accelerated innovation: The operator should be the foundation for a true internal database-as-a-service platform. By exposing a simple, declarative API, it allows developers to provision, configure, and manage databases independently using the same GitOps workflows they already use for applications. This replaces the slow, ticket-based process with true self-service, directly enabling the developer velocity goals discussed in previous chapters.

The Kubernetes operator market

The Kubernetes ecosystem offers three distinct types of operators, each with a clear set of trade-offs:

Proprietary, vendor-specific operators: These operators, often from the commercial entities behind a database (e.g., MongoDB Enterprise Operator, Crunchy Data's Postgres Operator, Oracle Kubernetes Operator, or DataStax Kubernetes Operator for Cassandra), typically offer comprehensive automation. However, they are almost always tied to paid, enterprise-licensed versions of the database. This approach swaps one form of lock-in (DBaaS) for another at the Kubernetes layer, limiting architectural choice and tying your strategy to a single vendor's roadmap and pricing model.

The "Build-Your-Own-Platform" (Community-driven open source operators): This approach offers maximum flexibility and freedom from commercial licensing. However, community operators vary widely in quality and maturity, especially for complex Day 2 automation. This path requires significant, and often underestimated, internal engineering investment to vet, deploy, harden, maintain, and support the tooling at an enterprise level. The TCO, in terms of specialized headcount, can be very high.

The "Strategic Synthesis" (Enterprise-grade open source operators): This approach combines the architectural freedom of open source with the reliability and comprehensive feature set of a commercial product. Crucially, they are designed to deliver the robust, out-of-the-box Day 2 automation and certified portability that enterprises demand. This synthesis provides a path to a standardized, multi-database platform without sacrificing control or building the entire stack from scratch. The trade-off is one of accountability: the organization must take on the responsibility of operating the service, either by maintaining a skilled internal platform team or by relying on a trusted enterprise support partner to manage production workloads.

Operator category	Day 1 & 2 automation	Portability/lock-in risk	Developer self-service	Strategic implication
Proprietary, vendor-specific	Often comprehensive, but tied to paid enterprise features.	High Risk. Locks the organization into a specific database version and commercial license.	Good, but within a closed, proprietary ecosystem.	Swaps one form of lock-in (DBaaS) for another at the Kubernetes layer. Limits architectural choice.
Community-driven open source	Varies. Can be excellent for core tasks but may lack advanced Day 2 features.	Excellent. No commercial lock-in.	Strong, but relies on internal platform teams to build a polished experience.	Offers maximum flexibility but requires significant internal expertise to vet, maintain, and support.
Enterprise-grade open source	Comprehensive. Designed for robust Day 2 automation (HA, backups, scaling) out of the box.	Excellent. No commercial lock-in and certified across major Kubernetes platforms.	Excellent. Provides the foundation for a true, multi-database self-service platform.	Combines open source freedom with enterprise reliability, but shifts service accountability to the internal team, requiring platform skills or a commercial support plan.

This table provides a general overview of common operator categories and their trade-offs. For a detailed, side-by-side comparison of Percona’s enterprise-grade open source Operators against closed-source or community options, view our Operator Feature Comparison. This interactive chart is sortable by technology, including PostgreSQL, MySQL, and MongoDB.

Ultimately, the goal is to create a database platform that is as agile, portable, and transparent as Kubernetes itself. An enterprise-grade, open source operator is the most effective approach, delivering comprehensive automation without vendor lock-in, production reliability without sacrificing control, and the flexibility to run anywhere Kubernetes runs.