The question of where data lives has become considerably more fraught over the past few years.
A mix of regulatory scrutiny, geopolitical tensions across the Atlantic, and the related unease about the concentration of infrastructure power among the hyperscalers have all combined to push data sovereignty up the executive agenda.
The result? A strategic posture that’s increasingly shaped by political anxiety rather than operational logic.
And while both need to be considered by the boardroom, leaning too much on the former leads to very different decisions.
Principal Technologist, EMEA at MongoDB.
To be clear, there’s no debate that compliance with data residency requirements remains a genuine obligation for organizations in regulated industries, and nobody is suggesting otherwise.
The concern is with what comes next: many organizations are at the "we must manage our data carefully" stage, and are considering a leap to "we should consider exiting hyperscaler infrastructure entirely." While the logic could be understandable, the reality is that full disengagement is neither effective nor necessary for the bulk of organizations.
The hyperscalers earned their position because they offered capabilities that were genuinely difficult to replicate at scale, and the organizations that depend on them most deeply are not in a position to unwind that dependency in any near-term timeframe. A multi-year transformation program with substantial execution risk is rarely the right answer to a political concern that may itself shift within that same period.
Conflating data residency and operational resilience
The focus on sovereignty has meant that ideas about data residency, infrastructure control, and operational resilience are being treated as interchangeable concepts. While connected, these are distinct ideas with distinct impacts on a business’s ability to function effectively and comply with regulation.
Let’s consider the incidents that really bring organizations down, and what makes data recovery harder than it needs to be. It’s system failures, slow incident response, and exploited security vulnerabilities that take customer-facing services offline, erode trust and incur regulatory fines. A platform that fails during peak demand causes the same commercial and reputational damage regardless of where its data is stored.
Similarly, a security breach does not become more or less severe based on whether it occurred on domestic or international infrastructure. The metrics that determine whether an organization functions under pressure are uptime, security posture and the quality of incident response capability. Sovereignty is one input to that picture, not the frame through which the whole picture should be viewed.
Simply put, an organization is not resilient simply because its data sits in the right jurisdiction. Resilience is an architectural and operational property that has to be built deliberately.
Where real control lives
If sovereignty decisions are best understood as one component of broader operational resilience, then the more productive question is where in the stack is control most effectively exercised. The answer, particularly as AI applications proliferate, is primarily at the data layer.
The database has moved beyond its traditional role as a storage mechanism. In modern architectures, it is often the most reliable point of deterministic control in the entire stack: the place where governance is enforced in practice rather than documented in policy.
Data location, encryption, access controls, cross-region movement – all of these are data infrastructure questions at heart. Getting them right is what makes meaningful sovereignty achievable, not as a political statement, but as an operational capability.
So in turn, when an organization has genuine control over governance at the data layer, suddenly the choice between a hyperscaler and a fully domestic alternative becomes less relevant. The question shifts from which provider to use to whether the infrastructure is flexible enough to enforce the appropriate rules for each workload. That reframing tends to produce considerably better outcomes.
In practice, this means building in tiers: cloud-native performance where the business requires speed, scalability and flexibility, on-premise or segmented deployments for regulated workloads, and the architectural flexibility to move between configurations as circumstances change. After all, regulations will continue to evolve.
The geopolitical environment that is currently driving sovereignty conversations will look different in three years. That means infrastructure decisions made under today's conditions need to remain workable under tomorrow's.
Building for change, not for certainty
The practical implication for technology leaders is straightforward: meet your regulatory obligations, exercise genuine control at the data layer, and build the architectural flexibility to adjust as requirements shift.
But after that, it’s important to give equal attention and consideration to the failure modes that are statistically far more likely to cause very tangible and costly problems: outages at peak load, delayed incident responses and vulnerabilities that could be exploited.
At the end of the day, those are far likelier to be discussed in post-mortems – not sovereignty. And while sovereignty deserves its place in the technology strategy conversation, it should sit within a resilience framework, not above it.
We've featured the best cloud databases.
This article was produced as part of TechRadar Pro Perspectives, our channel to feature the best and brightest minds in the technology industry today.
The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/pro/perspectives-how-to-submit