Chapter 1:

Databases: The bottleneck to cloud-native success

The core promises of the cloud-native model, including unprecedented agility, scalability, and developer velocity, were quickly realized for application deployment. Microservices, containers, and infrastructure-as-code delivered speed and scalability that legacy systems couldn't match. Applications modernized. Databases didn't. That gap is now the primary constraint on cloud-native velocity and a key driver of cloud cost overruns.

The impact is measurable. Application teams provision new services in minutes, while database requests take days or weeks. Containers scale automatically, while database capacity planning remains a quarterly exercise. Applications run anywhere, while databases lock you into specific clouds. This provisioning disparity translates directly to developer idle time, delayed feature launches, and competitive ground surrendered.

Why the lag happened

The primary reason for the lag in database modernization is validated by data: The 2024 Data on Kubernetes Report finds that 35% of organizations cite technical complexity as a significant barrier to adoption.

This complexity manifests as a skills gap, as running stateful, mission-critical workloads on Kubernetes requires specialized expertise that most teams lack. This challenge was compounded by immature tooling for persistent workloads and the high perceived risk of migrating data. For many, their databases also worked fine on-premises and didn't need hyperscale.

For years, this calculation made sense, as the migration risk simply outweighed the benefit. That calculation has changed as the tooling got better.

Mapping the journey: A database modernization maturity model

Modernizing the data layer is a strategic evolution through distinct stages of maturity. This progression allows a CIO to benchmark their organization's current state, understand the associated risks, and see the path forward.

  • Level 1: Legacy ad-hoc. Operations are manual and ticket-based. Provisioning is slow, and DBAs are siloed by technology. This model has high operational overhead and cannot keep pace with modern application development.

  • Level 2: Lift-and-shift / Basic DBaaS. Databases have been moved to the cloud, but are still managed as monolithic instances. Agility remains low, costs are opaque, and the organization is now exposed to significant vendor lock-in.

  • Level 3: Fragmented cloud-native. The enterprise has begun running some stateful workloads on Kubernetes, typically using a mix of community-led operators or vendor-specific solutions for different databases. While automation is present, it is inconsistent across the data estate. Each database type requires a different set of tools and skills, creating new operational silos and preventing the realization of a truly unified platform.

  • Level 4: Unified data platform. The target state. The organization operates a standardized, multi-database platform on Kubernetes. An enterprise-grade, open source operator framework provides consistent automation. Developers have self-service, governance is centralized, and full TCO control is achieved.

The vast majority of enterprises today are in Level 2 or Level 3. The sheer scale of the Level 2 cohort aligns with Gartner’s forecast that the PaaS market (which includes DBaaS) will grow 21.6% in 2025, reflecting the continued expansion of this model across organizations. This growth indicates that many organizations continue to be deeply invested in managed database services as their primary operating model.

As this paper argues, many in this group are now grappling with the painful consequences of this strategy: vendor lock-in and opaque, escalating costs. In response, an advanced group (Level 3) has begun migrating to Kubernetes, only to find themselves stalled by a new set of challenges: fragmentation, complexity, and inconsistent automation.

The compounding costs of stagnation in levels 1 & 2

Organizations that remain in the first two stages of maturity accumulate four distinct and compounding types of strategic debt:

  1. Provisioning delays that compound across every sprint. The gap is particularly acute in microservices architectures, where each service potentially needs its own data store. What should be self-service becomes a ticket, a queue, and a deployment issue that delays launches and hands an advantage to faster-moving competitors.
  2. Rising costs and vendor lock-in. Proprietary DBaaS platforms look simple until you scale, add regions, or try to leave. Pricing models penalize growth. Multi-region replication costs more than the database itself. Data transfer fees compound with every query. What started as convenience becomes a tax on every transaction.
  3. Security and compliance fragmentation. Every additional database platform is another security perimeter to monitor, another compliance framework to audit, another data residency rule to enforce. When applications run on Kubernetes but databases don't, you can't apply consistent policies across your stack.
  4. Operational complexity that scales poorly. Traditional database operations require specialized teams for each technology. Managing provisioning, backups, upgrades, and monitoring through different tools and processes fragments operational efficiency and creates knowledge silos that limit organizational agility.
Previous page
Next page