Chapter 5:
Design decisions that shape sovereignty
Architectural choices determine whether a database platform can withstand regulatory shifts, provider outages, or jurisdictional constraints. Many organizations unintentionally reduce sovereignty through design choices that create hidden dependencies. Others adopt patterns that strengthen independence and create verifiable control points.
Design patterns that undermine sovereignty
Provider-owned backup and snapshot formats
When backups are created, stored, or restored through provider-specific mechanisms, organizations lose the ability to independently validate continuity. In many DBaaS platforms, snapshots exist only inside the provider’s storage ecosystem. They cannot be exported without transformation, and the restore process requires calling provider APIs. This introduces both operational dependency and jurisdictional uncertainty, as backup storage may cross borders without the customer's control. Guidance from the European Central Bank (ECB) on cloud outsourcing explicitly identifies this 'lack of substitutability' as a critical risk. Regulators now expect 'functional equivalence' in exit strategies, meaning backups must be usable on alternative infrastructure without significant re-engineering.
Mandatory cross-region or cross-border operational flows
Some managed database platforms automatically shift control plane operations across regions. For example, monitoring, failover initiation, or replication management may occur from infrastructure located outside the region where data is stored. Analysts have cited this as a source of compliance and sovereignty risk, particularly for public sector and financial institutions in Europe.
When operational logic is executed in another jurisdiction, organizations lose the ability to guarantee that access pathways comply with applicable data protection or localization laws.
Vendor-mediated failover and maintenance
Many platforms rely on automatic failover mechanisms orchestrated by proprietary services. While convenient, these mechanisms cannot be audited in detail. Organizations are unable to validate the behaviors under region failure, control plane disruption, or jurisdictional constraints. This presents a compliance issue in regulated sectors that must demonstrate the ability to maintain continuity independently of the provider’s internal systems.
Provider-controlled encryption domains
If encryption keys are created, stored, or rotated through provider systems, organizations lose control over the cryptographic boundary. Customer-managed keys mitigate this risk, provided that key creation, storage, and rotation occur within systems fully controlled by the customer or a compliant external key management solution.
As highlighted in the 2024 Thales Data Threat Report, organizations now identify 'mandatory external key management' as the leading technical control for achieving sovereignty. Post-Schrems II legal analyses further confirm that standard 'Bring Your Own Key' (BYOK) models are often insufficient if the provider retains access to the key memory. True sovereignty requires 'Hold Your Own Key' (HYOK) architectures where the identity provider and key store remain completely external to the database vendor.
Logging that remains inside the provider infrastructure
If administrative, operational, or security logs remain solely in provider-managed logging systems, organizations cannot independently validate access or privilege paths. Regulators are increasingly expecting logs to be exported to customer-controlled SIEMs or data retention platforms for audit purposes.
Design patterns that strengthen sovereignty
Portable backups under customer control
Backups that can be restored in any compliant environment provide the foundation for continuity, migration, and exit strategies. Organizations strengthen sovereignty when they:
- Use open, portable backup formats
- Store backup copies in customer-governed S3-compatible object storage
- Test backup restoration in alternate environments
- Maintain version-aligned restore procedures
These practices demonstrate operational independence.
Customer-managed encryption keys
Organizations strengthen control when they create, store, and rotate encryption keys within systems governed by internal policy. Customer-managed keys reduce risk and allow organizations to demonstrate compliance with jurisdictional and regulatory requirements.
Independent observability
Security teams increasingly require that logs for access, operations, and configuration changes be routed into systems under customer control. This enables the creation of evidence, advanced analysis, and retention that is aligned with regulatory requirements. It also ensures that auditability is independent of provider systems.
Declarative automation outside the provider’s control plane
Automation frameworks such as Kubernetes Operators provide a portable and open method for provisioning, scaling, and maintaining databases. When these systems run outside provider control planes, organizations maintain operational authority and can validate behavior in controlled scenarios.
Open, portable database distributions
Databases that can run on-premises, across clouds, or in sovereign environments allow organizations to maintain continuity even if provider services become unavailable or change their terms. Portability is a key factor in long-term resilience strategies, and this strategic priority is corroborated by the 2024 Gartner Magic Quadrant for Cloud Database Management Systems, which identifies 'multicloud' and 'intercloud' capabilities as critical differentiators for market leaders. Gartner analysts note that organizations are increasingly prioritizing platforms that decouple data from specific cloud providers to mitigate the risks of concentration and vendor lock-in.
Architecture determines resilience
Many organizations assume resilience comes from provider scale. In practice, resilience comes from the ability to operate independently when provider systems are constrained or unavailable.
