For years, the debate around digital sovereignty focused on infrastructure. Now the spotlight is shifting to a far more valuable enterprise layer: the database. Geopolitical pressure, especially in Europe, is pushing hyperscalers like Amazon and Microsoft to invest heavily to meet new policies and regulations as data governance forces organizations to re-evaluate reliance on managed cloud services. Instead of accepting lock-in, a growing number of enterprises are treating assets like PostgreSQL as a portable, cloud-neutral foundation that behaves identically across on-premises, private, and public cloud environments. The shift is fueling interest in what some engineers call Sovereign DBaaS: database platforms that deliver cloud-level automation without surrendering control to hyperscalers.

At the center of the change is Gabriele Bartolini, VP and Chief Architect of Kubernetes at EDB. A prominent figure in the open source PostgreSQL community, Bartolini brings deep credibility to the discussion. He co-founded 2ndQuadrant, founded both the Italian PostgreSQL Users Group (ITPUG) and PostgreSQL Europe, and is a co-founder and active maintainer of the CloudNativePG operator. Bartolini is also the creator of Barman, one of the most important disaster recovery tools in the Postgres ecosystem. His work over the years has played a significant role in establishing PostgreSQL as a first-class citizen in cloud-native environments, including leading the initiative that made EDB the first Kubernetes Certified Service Provider for PostgreSQL.

According to Bartolini, this isn’t about compromise. It’s about reframing the problem to get the best of both worlds: convenience and control. “True sovereignty starts with the database. If your PostgreSQL isn’t portable across environments, you don’t really control your stack,” he says. Ensuring consistency across environments allows enterprises to standardize deployments, enforce policies, and manage complex, resource-intensive workloads with confidence. Bartolini emphasizes that this architectural choice also directly strengthens negotiating leverage, regulatory compliance, and long-term strategic flexibility.

• A tempting shortcut: While managed cloud services promise speed and simplicity, Bartolini warns that convenience often comes at the cost of control. “Convenience is the cloud’s biggest shortcut, but convenience isn’t sovereignty. Real control means you can move your database anywhere and it behaves the same.” Bartolini’s warning is particularly relevant for organizations that depend on consistent behavior across hybrid environments, where a misstep can cascade into operational or compliance risks.
  
• The leverage play: For many leaders, the move away from managed services centers on long-term leverage. Bartolini frames the upfront investment as a strategic trade that secures future freedom and negotiating power, noting that the approach is gaining enough traction for hyperscalers to begin acknowledging it. He points to a recent Microsoft video encouraging customers to run self-managed PostgreSQL with CloudNativePG on their Azure Kubernetes Service as a sign that portability is entering the mainstream. “As an organization, you gain significant leverage with the hyperscaler because they know you can leave easily,” Bartolini explains. “That portability forces them to provide better offerings and better deals to keep your business.”

A key enabler for this portability is the Operator Pattern, an architecture that elevates database management beyond simple containerization by extending Kubernetes itself. It works by encoding domain-specific expertise into software, essentially teaching Kubernetes how to manage the entire lifecycle of a stateful application like PostgreSQL. The approach is evident in CloudNativePG, which supports modern microservice database architectures and provides declarative APIs for high availability, backup, and self-healing, using native PostgreSQL streaming replication rather than proprietary cloud tools.

• The operational brain: Bartolini asserts that, while Kubernetes provides portability, simply containerizing a database isn’t enough. The database itself must encode operational intelligence and effectively manage its lifecycle alongside the cluster. “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.”

But does all this control come at the expense of performance? Bartolini says the opposite is true—and he has the numbers to prove it. He points to recent benchmarks that will be published soon, which showcase CloudNativePG on bare metal, achieving 30,000 TPS with synchronous replication*, while small cloud deployments might yield only 1,500 TPS. That level of performance becomes particularly valuable when considering the demands of sovereign AI.

• The AI cost equation: “The move to bare metal marks a return to a CAPEX model. With AI, you need predictable costs. The unpredictability of cloud spend was already a problem, and with AI, things can get out of control very easily. Fixed costs are essential,” he notes. By owning the hardware, organizations can better forecast expenses for resource-intensive AI workloads, avoiding the hidden variability of cloud billing and giving teams more control over both performance and budgets.
  
• Bare metal performance: Beyond just a technical choice, moving away from virtual machines and cloud abstractions has the potential to be a performance multiplier. “If you move to on-premises and you can run Kubernetes directly on bare metal, the database can go as fast as a traditional bare-metal deployment. Many people assume you need VMs, but deploying on bare metal with local storage gives you massive throughput, and you avoid inefficiencies like replicating blocks multiple times.” For enterprises building resource-intensive AI workloads, this approach ensures both speed and operational predictability, complementing the CAPEX-driven cost model that makes AI projects financially manageable.

Of course, technology is only half the battle. Making this model work requires a cultural change. Bartolini recalls how his own team of DBAs initially thought Kubernetes might not mature into what it is today. In his view, the solution is to cultivate a “T-shaped profile” in which DBAs supplement their deep expertise with a horizontal understanding of Kubernetes, noting that this mirrors the historical adoption of PostgreSQL by innovators like Instagram, Spotify, and even Skype in the early 2000s. The operator’s Custom Resource Definition (CRD) can act as a key enabler, serving as a transparent contract between platform engineers and database experts.

• The evolving DBA: “DBAs have two options: stay in the comfort zone and pretend Kubernetes doesn’t exist, or start learning.” The choice reflects a broader shift in enterprise IT, where infrastructure and development teams increasingly expect database experts to be conversant in cloud-native environments rather than operating in isolation.
  
• Facing the challenge: He is optimistic about how quickly DBAs can adapt, sharing that at EDB, “We’ve proven that with about a month of study, a DBA can earn their CKA certification and build that T-shaped profile, enabling smart conversations with both developers and the infrastructure team.” This approach not only strengthens collaboration across teams but also positions DBAs as active architects of both application and infrastructure workflows, rather than passive stewards of data.

“The database team cannot drive this change alone, otherwise it’s a ‘Transformation with a capital T’ that fails.” Building what he calls a “sovereign bubble” often involves unplugging other key layers from provider-specific services, addressing everything from compliance to disaster recovery. Bartolini identifies observability as the biggest gap impacting enterprise teams, warning, “If your logs and metrics are trapped in a provider’s proprietary tool, you are not independent. The change needs to flow where the entire infrastructure is already going.” From his perspective, teams should focus on standard formats and technologies as a first principle, rather than relying on a CNCF-native observability stack, to avoid being locked into proprietary tools that limit transparency, hinder collaboration, and constrain the organization’s ability to scale and innovate independently.

*Throughput measured using pgbench TPC-B-like simulations on unoptimized, out-of-the-box CloudNativePG installations; real-world performance may vary depending on schema, workload patterns, replication setup, and hardware configuration.

Get your free copy of the O’Reilly book: Building a Data and AI Platform with PostgreSQL

Group Created with Sketch.