Authored by Matt Johnson, Principal Technologist at MongoDB

Tech sovereignty has moved fast up the corporate agenda. Where data lives, who owns the software stack, which jurisdiction’s laws govern the infrastructure – these are now boardroom conversations, not compliance footnotes. Geopolitical friction has accelerated this shift, and the urgency is understandable. But urgency without precision or careful consideration can create more harm than good, and right now, too many organisations are letting anxiety about sovereignty crowd out far more tangible operational risks facing them.

Are businesses pushing sovereignty for the wrong reasons?

Organisations, particularly those in regulated industries like finance and healthcare, have always needed to think carefully about data residency and the various legal frameworks they work within. In most cases, that’s still very much the case. What has changed is the nature of the conversation driving sovereignty decisions. Today’s push is less about regulatory obligation and more about geopolitical uncertainty. One example being perceived by some is deteriorating transatlantic relations, and subsequent fears that hyperscalers may share data if placed under enough pressure by government administrations.

In turn, this has distorted how many of us see sovereignty. The question of what data requires what kind of control is getting unnecessarily politicised, when in reality, it should remain an operational and architectural decision. Some organisations are even exploring full disengagement from hyperscaler ecosystems. For the vast majority, that’s not a credible option.

The hyperscalers became dominant because they offered capabilities and reliability that were genuinely hard to replicate, and many businesses would likely have struggled to scale without these components, and not because enterprises had no alternative. Additionally, walking away from infrastructure that is likely deeply embedded across the enterprise would require a multi-year transformation with substantial execution risk. This is something that most organisations would likely find difficult to achieve, and it’s uncertain whether most would benefit from doing so.

The real risks are practical, not jurisdictional

This is not to say that it does not matter where organisations store their data – compliance with residency laws is an important mechanism that goes a long way in protecting businesses and their customers alike. The challenge at hand is that sovereignty and data residency are becoming catch-all terms when businesses should really be discussing the much wider topic of operational resilience.

Outside of compliance with key requirements, the incidents that cause genuine organisational damage are mostly practical in nature – such as system failures, slow incident response and the exploitation of security vulnerabilities. These are the risks that take organisations offline, chip away at customer trust, and incur fines from regulatory bodies.

A customer-facing platform that fails during peak demand doesn’t become less damaging because the data was stored in the right jurisdiction. A security breach doesn’t cause less harm because it happened on domestic infrastructure. Uptime, availability, security posture and incident response capability are the risk metrics that determine whether an organisation functions when it matters most. As a result, sovereignty should be treated as another layer within that broader set of concerns — not the frame through which all infrastructure decisions are made. An organisation needs to make sure its infrastructure is resilient foremost – it’s not resilient just because of where data is stored.

Taking control of the data layer

The more productive framing for this conversation is infrastructure control, and that control lives primarily at the data layer. With the rise of AI applications, the database is not just a storage mechanism, but often the only point of deterministic control in the stack. Additionally, it is where governance is enforced in practice. Where data is stored, how it is encrypted, who can access it, how it moves between regions: these can be bolt-on application logic, but in reality, they are data infrastructure questions. And getting the architecture right at this layer is what makes meaningful sovereignty possible.

When an organisation has real control over data governance through its database architecture, the binary choice between a major hyperscaler and a fully domestic alternative starts to dissolve. The question shifts from which providers to pick to whether the infrastructure is flexible enough to enforce the right rules for each workload. That’s a much more useful question, and it leads to better decisions.

In practice, this means building in tiers: cloud-native performance where the business demands it, on-premise, or segmented deployments for regulated workloads, and the ability to move between all of the above as key architectural flexibility.

The goal is not to find the perfect sovereign cloud strategy for today’s regulatory environment. After all, regulations will shift year to year, while geopolitics will continue to evolve. As a result, organisations need infrastructure that lets them meet these changes with the right level of flexibility.

Photo courtesy of MongoDB