In our current VUCA(P) world, digital sovereignty is no longer a theoretical debate; it has become a survival requirement. This environment is defined by Volatility, Uncertainty, Complexity, Ambiguity, and Paradox, where the only constant is adapting to change.
As data becomes the primary fuel for the AI revolution, an organisation’s ability to control its data is directly tied to its ability to own its AI future. For organisations looking to navigate these global uncertainties, the journey begins by reclaiming control over the most critical layer of the stack: the database.
Obviously, I will be talking about PostgreSQL, the database that we at EDB have helped build and evolve for more than 20 years.
Navigating the paradox of sovereignty
The “paradox” in VUCA(P) is a critical driver for modern technical strategy. It represents the constant tension between seemingly opposing forces, such as the need for rapid, high-speed innovation and the requirement for absolute data control. Historically, organisations felt forced to choose one over the other. Choosing innovation often meant embracing proprietary DBaaS solutions that offered velocity but sacrificed sovereignty, while choosing control often meant staying on-premise with manual, legacy processes.
However, by acknowledging these opposing forces, you can find a balance that ensures your final outcome maintains its direction. Today, true sovereignty is the ability to resolve this paradox. It allows you to leverage the automation and scale of the cloud while maintaining the operational independence required for compliance and long-term resilience.
The Day 2 operational wall
The last 30 years of PostgreSQL have seen incredible evolution, moving from Day 1 operations involving installation on bare metal to the rise of DBaaS approximately 15 years ago. These managed services were revolutionary because they automated Day 2 operations, including high availability (HA), disaster recovery (DR), and self-healing.
In a VUCA(P) context, this convenience came with a hidden risk: operational lock-in.
The intelligence required to run these mission-critical databases was trapped behind proprietary cloud APIs. This created a "data gravity" that made it nearly impossible to move workloads to sovereign infrastructure without a high-risk re-architecture and significant operational disruption.
Reclaiming control: The cloud neutral stack
To meet modern requirements, such as the EU Data Act, we must move toward a cloud neutral architecture. This is exactly what the combination of Kubernetes, PostgreSQL, and CloudNativePG provides
Kubernetes provides a portable, distributed operating system that runs identically on-premise and across every public cloud. CloudNativePG then serves as the "missing link" by codifying a database administrator's expertise directly into the Kubernetes control plane. It transforms the human knowledge of Day 2 operations into declarative, infrastructure-neutral code.
This allows organisations to build a "Sovereign DBaaS" that offers automation comparable to hyperscalers while maintaining deployment freedom.
However, true portability requires a more generic approach to operations. To avoid new forms of lock-in, organisations must move beyond provider-specific services—not just for the database, but holistically. If your metrics, logs, and traces are trapped in a cloud that is not under your control, your sovereignty is incomplete. Reaching true independence means integrating with standard, platform-agnostic interfaces to ensure that your entire operational stack remains as portable as the code it serves.
Entering the winning zone
To break the cycle of lock-in, organisations must adopt the winning zone methodology, as defined by Kim and Spears. This approach reframes migration from a high-risk "danger zone" into a safety zone where teams can prepare, practice, and de-risk the process.
By using a blue/green migration strategy powered by native logical replication, you can move from a proprietary service to CloudNativePG with minimal downtime and total confidence in your business continuity. This move is a one-time investment in freedom.
Once you are within the CloudNativePG ecosystem, you achieve permanent portability. You can use native physical streaming replication to synchronise or move your databases in real time across any infrastructure, ensuring that your HA and DR requirements are met identically, whether you are on bare metal or in a public cloud.
A growing ecosystem for the future
The journey toward a cloud neutral PostgreSQL experience is not yet complete. This is a rapidly growing ecosystem, and CloudNativePG is currently in the CNCF Sandbox, aiming to become a CNCF Incubating project (the second stage in the maturity model).
At EDB, we are committed to continuing our support for this project and improving the overall PostgreSQL experience in Kubernetes. Our goal is to further integrate with other CNCF projects that cover strategic areas of IT operations, ensuring that your data layer remains as modern and agile as your applications.
Conclusion: the foundation of Sovereign AI
Sovereignty over the data layer is the mandatory first step for operational independence and Sovereign AI.
Even for organisations that are comfortable running in the public cloud, there is a clear path to greater control. If you already run applications in a Kubernetes-managed service provided by a hyperscaler (e.g. EKS) but rely on their proprietary DBaaS for your Postgres database (e.g. RDS), you can reclaim sovereignty by moving the database into that same Kubernetes cluster with CloudNativePG and PostgreSQL. This transition allows you to benefit from increased control and immediate portability while still leveraging your cloud provider of choice.
Moreover, by following the OpenSSF's trajectory toward safer software supply chains, the CloudNativePG project facilitates compliance with the EU Cyber Resilience Act (CRA) through the use of signed images and SBOMs.
Floor Drees and I will cover these topics in detail during our upcoming session at Open Sovereign Cloud Day at KubeCon Amsterdam 2026 on Monday, March 23. Join us to explore how to achieve true operational independence: “Beyond the DBaaS trap: achieving data sovereignty with Kubernetes and CloudNativePG”.
EDB is the proud creator and primary contributor to CloudNativePG. We provide enterprise-grade support and certified images for the open source stack. For organisations requiring advanced capabilities, we also offer proprietary solutions based on CloudNativePG, including EDB Postgres AI’s Enterprise Postgres with Transparent Data Encryption (TDE), Oracle Compatibility, and much more. Our commitment includes Long Term Support (LTS) and OpenShift certification, allowing you to own your digital destiny in an increasingly VUCA(P) world.
To learn more about EDB and CloudNativePG, visit us at EDB Postgres AI for CloudNativePG - Enterprise-Grade Database Solution.