On-prem DBaaS in 2026: Platforms, standards, and gaps

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.... 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

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.... 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. 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: Are backups running consistently? Can backups actually be restored? How are upgrades handled? Who responds when availability issues occur? How are operational policies enforced across teams? 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

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.... 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. 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: Are backups running consistently? Can backups actually be restored? How are upgrades handled? Who responds when availability issues occur? How are operational policies enforced across teams? 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