Posted on July 15, 2026 by Oliver Wolf, anynines

CNCF projects highlighted in this post

Kubernetes logo

For application teams, databases should feel like a solved problem. A team needs PostgreSQL, MariaDB, Redis, or another data service, submits a request, receives credentials, and starts building.

In practice, the experience is rarely that simple.

In 2026, many organizations have made significant progress in platform engineering and Kubernetes adoption, but database provisioning remains fragmented. Teams that want a cloud-native developer experience often face an uncomfortable tradeoff: operational responsibility versus platform dependence.

On one side, developers can operate databases themselves using Kubernetes operators. On the other side, platform teams can provide a managed experience through internal platforms and provisioning systems, frequently relying on cloud-managed services. Both approaches work, but both have limitations.

The result is that organizations repeatedly reinvent solutions to what has become a very common platform problem: providing Database-as-a-Service (DBaaS) capabilities that work consistently across environments.

The current state of database provisioning

If a development team needs a database today, the process typically follows one of two patterns.

The first pattern gives teams direct operational ownership. A development team deploys and manages database operators inside their Kubernetes environment. For PostgreSQL, this could involve projects such as Patroni-based solutions or other Kubernetes-native operators. Similar patterns exist for MariaDB, key-value stores, and many other database technologies.

The second pattern centralizes responsibility within a platform team. Using tools such as Crossplane compositions, platform teams create abstractions that allow developers to request services while provisioning cloud resources underneath, often through services such as managed relational databases.

The second approach improves the developer experience considerably. Developers receive self-service provisioning while operational tasks remain centralized. In many cases, platform teams use tools such as Crossplane to provide a self-service interface while provisioning cloud-managed resources underneath, for example, AWS RDS databases. Developers get a simple and consistent experience, while the operational burden shifts away from individual teams and toward centralized platform automation. While it is relatively clear how tools such as Crossplane can be used within the same cluster where application workloads run, using them as a centralized platform layer across multiple environments remains an open question. Many platform teams are currently exploring different approaches, often independently and without much coordination across the broader ecosystem.

An image of the developer team operated databases versus hyperscaler operator databases

However, relying on cloud-managed services as the underlying implementation often comes with an important compromise: cloud dependence.

For organizations with requirements around data sovereignty, regulatory compliance, or multi-cloud portability, relying heavily on cloud-specific managed offerings can become problematic. If cloud independence is a requirement, the fallback often becomes self-managed databases within Kubernetes clusters.

That solution works—but it shifts operational responsibility back toward engineering teams.

Operators reduce complexity, but not operational responsibility

Kubernetes operators have substantially improved database automation.

Instead of writing custom scripts and operational workflows, teams can adopt mature open source projects that automate common tasks such as failover, scaling, and replication.

For PostgreSQL, operators based on Patroni and similar projects reduce the implementation effort. Organizations no longer need to build database lifecycle management from scratch.

But operators do not eliminate operational responsibility.

Someone still needs to answer important questions:

In many organizations, every team answers these questions independently.

Even when platform teams define a “golden path,” operational responsibilities remain distributed. Instead of centralizing ownership, organizations often end up multiplying it.

The missing layer: A common platform standard

The underlying challenge extends beyond database automation itself. Kubernetes operators have significantly improved many aspects of database lifecycle management, but organizations still need consistent ways to expose and manage these capabilities across teams and environments.

The missing piece is standardization.

There is still no broadly adopted framework that separates what developers request from how platform teams implement it.

Historically, the Open Service Broker API (OSBAPI) attempted to solve exactly this challenge.

Cloud Foundry successfully used the service broker model to provide self-service access to infrastructure resources. Developers requested services through a standard interface, while platform operators remained free to implement provisioning using any backend system.

The model worked well.

However, adoption beyond Cloud Foundry remained limited.

Attempts to integrate service broker concepts into Kubernetes ecosystems ultimately struggled to gain traction. One lesson from these efforts became increasingly clear: Kubernetes users generally expect a Kubernetes-native workflow.

For many engineering teams, the desired user experience is straightforward:

kubectl apply -f postgres.yaml

Anything requiring a fundamentally different interaction model often creates friction.

What would a Kubernetes-native service broker look like?

This raises an interesting question for the cloud-native ecosystem:

What would a modern service broker standard look like if designed specifically for Kubernetes?

Such a system would likely preserve many of the ideas that made OSBAPI valuable:

But it would also embrace Kubernetes-native principles:

In that model, a control plane enables central governance while still allowing local self-service. That combination creates a foundation for capabilities such as billing, audit and monitoring, quota allocation, and other policy-driven controls that platform teams need in larger organizations.

One possible direction is Klutch.io, an open source project exploring this approach.

Klutch translates service broker concepts into Kubernetes-native resources. These resources are created within local clusters and replicated into a centralized control-plane cluster where automation systems can process them.

In practice, engineering teams interact with familiar Kubernetes resources:

kind: PostgresService

kind: ServiceBinding

kind: Backup

kind: Restore

kind: BackupSchedule

Platform teams then decide how these resources should be fulfilled.

A PostgresService could be implemented through:

The consumer experience remains unchanged.

The implementation remains flexible.

Toward a shared DBaaS Foundation

The cloud native ecosystem already has many excellent building blocks.

Kubernetes operators automate database lifecycle management. Platform engineering practices improve developer experiences. Tools such as Crossplane provide abstraction layers across infrastructure.

What remains missing is a widely adopted standard that connects these pieces together.

Without such a standard, organizations continue building similar solutions repeatedly—each with its own APIs, workflows, and operational assumptions.

Database provisioning is unlikely to become simpler on its own. As organizations continue adopting hybrid, on-prem, and multi-cloud architectures, the need for consistent self-service patterns will only increase.

The question may no longer be whether Database-as-a-Service belongs inside Kubernetes ecosystems.

The more interesting question is whether the cloud-native community can converge on a common model for delivering it.

Discover more about klutch.io at https://anynines.com/products/hub/.