From VMs to Kubernetes: A DBA's Journey in a Large Global Bank

How one of the world's largest financial institutions rethought database operations by bringing PostgreSQL natively into Kubernetes—and what every enterprise DBA can learn from it.

Running a database at global-bank scale means operating under some of the strictest uptime, compliance, and security requirements on the planet.

So when a team at a major financial institution decided to abandon traditional VM-based PostgreSQL deployments in favor of Kubernetes, the technical and cultural challenges were anything but trivial. Still, the promise of a better, more stable, scalable, and secure environment overcame any reservations.

The lessons learned are invaluable for any enterprise considering the same shift.

The talk that brought the room to its feet

Presented at Data on Kubernetes Day (the co-located event just ahead of KubeCon + CloudNativeCon EU 2026 in Amsterdam) was a candid, practitioner-level account of migrating mission-critical databases in a heavily regulated environment.

Gabriele Bartolini, VP and Chief Architect of Kubernetes at EDB and co-founder of the CloudNativePG operator, was joined by Laurent Parodi, a veteran DBA inside one of the world's largest global banks, who told the story from both sides: the open-source toolmaker and the enterprise operator who bet his production workloads on it.

You can watch the full talk here:

Why are VMs being left behind?

For most of its history, enterprise PostgreSQL lived where all enterprise databases lived: on virtual machines. The VM model was comfortable, familiar, and auditable. DBAs understood it. Procurement understood it. Compliance teams understood it. But the cracks began to show as organizations scaled.

Provisioning a new database cluster could take days or weeks. Configuration drift between environments was problematic. Disaster recovery was elaborate and manual. And the increasing pressure to ship software faster—at cloud speed—meant the old operating model was becoming a drag on the entire engineering organization.

Some of the core VM problems causing this drag are:

• Slow provisioning cycles out of step with application deployment velocity
• Configuration drift between dev, staging, and production environments
• Manual, error-prone failover and disaster recovery procedures
• Difficulty integrating databases into modern GitOps and CI/CD pipelines
• Operational silos between DBA, infrastructure, and development teams

With the limitations above, it’s not surprising that organizations are looking for a better path forward. Hence, the reason why Kubernetes is becoming so popular with the DBA community and the growth of the CloudNativePG operator.

CloudNativePG: the better path forward

The CloudNativePG operator was purpose-built to eliminate database drag. Unlike operators that bolt Kubernetes onto an existing VM-era architecture, CloudNativePG was designed from the ground up to treat the Kubernetes controller as the authoritative operational brain for PostgreSQL. It handles primary election, synchronous and asynchronous replication, automated failover, switchover, and configuration management—natively and declaratively, without external dependencies such as Patroni or repmgr.

By embedding the intelligence of a DBA as an operational brain within Kubernetes, you remove the Operational Wall of the hyperscalers, creating a DBaaS that is automated enough for developers but sovereign enough for the enterprise."

— Gabriele Bartolini, VP & Chief Architect of Kubernetes, EDB

The key insight is that Kubernetes is not just a deployment platform — it is a reconciliation loop. Once you define your desired state, the platform continuously works to achieve and maintain it. For databases, this means self-healing clusters, automated backup scheduling, and point-in-time recovery become the norm, not the exception, with human oversight as needed to ensure control and compliance requirements.

The DBA's journey: from Skeptic to Advocate

Laurent Parodi's account from inside a large global bank added the grounding that purely theoretical talks often lack. DBAs—understandably—approached Kubernetes with skepticism. Their expertise had been built over years around a very different operational model. Learning Kubernetes concepts, YAML manifests, and the declarative philosophy felt, at first, like abandoning hard-won mastery in favor of an uncertain new world.

Bartolini has written extensively about this dynamic, describing a "paradoxical" phase in the industry: a growing number of teams successfully run Postgres in Kubernetes, while many others resist the shift.  Reverting to familiar proof methods will reduce tension and demonstrate the validity and reliability of the new approach.

The bank's journey from VM-based PostgreSQL deployments to a Kubernetes-native model didn't happen overnight. At the global bank, the journey unfolded in four deliberate phases:

1. Assessment & Proof-of-Concept

Before committing to a full migration, the team identified workloads that were strong candidates for Kubernetes, established performance benchmarks, and stress-tested CloudNativePG against the bank's stringent security and compliance requirements. This phase was about building confidence, not just in the technology, but in the team's ability to operate it effectively.

2. Team Upskilling & Cultural Shift

The biggest challenge in any platform migration is rarely technical; it's human. DBAs needed to become fluent in Kubernetes primitives: pods, operators, custom resources, and GitOps workflows. The goal wasn't to turn DBAs into platform engineers, but to expand their existing expertise.

3. Migration Tooling & Zero-Downtime Import 

With confidence established and skills sharpened, the team began moving live workloads. CloudNativePG's import capabilities enabled migration from both VM-based deployments and managed cloud services into Kubernetes. This was achieved without taking applications offline, a non-negotiable requirement in a 24/7 financial services environment. 

4. Production Rollout & Operational Stabilization

The final phase was about making Kubernetes-native PostgreSQL the new normal. Coverage expanded incrementally, CI/CD and GitOps pipelines were integrated, and on-call runbooks were rewritten to reflect the new operational model, ensuring the team could respond to incidents with the same confidence they had in the old world.

Data sovereignty: the hidden advantage

One theme that surfaced repeatedly—and resonates especially in the financial services sector—is sovereignty. When a hyperscaler's proprietary DBaaS offering manages your database, you have surrendered control over the operational model, the upgrade cadence, and ultimately the data itself. Running PostgreSQL in Kubernetes with an open-source operator on infrastructure, you reclaim control and restore data sovereignty.

This matters enormously in contexts where regulators require demonstrated control over where data lives and how it is accessed. It also matters competitively because organizations that depend entirely on a single cloud provider's managed database service are exposed to pricing changes, feature deprecations, and lock-in that can have material consequences years down the line.

The new generation of enterprise data protection

At the same event, EDB previewed its next-generation Kubernetes-native data protection solution built on CloudNativePG. Moving decisively beyond legacy backup tools designed for the pre-container era, the solution delivers near-zero data loss via native WAL streaming, managed through a single centralized interface, and end-to-end encryption that meets FIPS 140-3 security standards. For a global bank weighing its options, this is critical because it provides enterprise-grade protection on an open, portable infrastructure, rather than locking it into a proprietary, closed-end hyperscaler cloud.

Some of the key takeaways that DBA’s can act on now, for working with Kubernetes are:

• DBAs do not need to reinvent themselves. They can extend their skills to Kubernetes without abandoning their database expertise.
• Start with lower-criticality workloads for proof-of-concept. Build confidence before migrating tier-one systems.
• CloudNativePG's declarative model makes configuration drift structurally impossible. This is a major win for compliance teams.
• Near-zero-downtime migration paths exist for moving from both VM-hosted and cloud-managed PostgreSQL into Kubernetes.
• Sovereignty and auditability are major advantages of Kubernetes, along with the freedom of the open-source operator model, which is designed to meet regulatory requirements.

The road ahead

The trajectory is no longer speculative. Kubernetes has become the default platform for application workloads, and databases are following suit, with growing conviction among the people who operate them at the highest stakes.

Laurent Parodi's journey, from skeptic to advocate inside one of the world's most demanding regulated environments, is the most credible proof point CloudNativePG has yet had. If the operational model holds at a global-bank scale, under those compliance and security constraints, the question of whether Kubernetes is ready for mission-critical PostgreSQL has been answered. What remains is execution.

The path Laurent walked (assess, upskill, migrate, stabilize) is repeatable. The tooling exists, the patterns are documented, and the operator is production-hardened. The hardest part, as it usually is, was the first step. This talk is a good place to start. To learn more about this story, watch the video or visit us at EDB Postgres® AI for CloudNativePG™: Empowering Kubernetes | EnterpriseDB.