Your Platform Cannot Follow Your Data. That Is a Strategic Risk You Have Already Accepted.

When we started building BDB twelve years ago, we made a decision that most platform vendors never make: we would build for every deployment reality, not just the convenient one. Not because we predicted every regulation that would follow. But because we had seen enough of the world to know that enterprise data does not live in one place — and a platform that cannot follow it is a platform with a ceiling.

That decision cost us more than we anticipated. Building for on-premises, cloud, hybrid, and modular deployment simultaneously means maintaining a unified codebase across radically different infrastructure environments. It means testing on bare-metal servers, on Kubernetes clusters, on private clouds, on AWS and Azure and GCP. It means your engineers need to understand all of it.

We built it anyway. And in 2026, the world has caught up with that decision.

---

The data sovereignty moment has arrived

Something significant happened in 2025 that received less attention than it deserved in the enterprise technology press.

The General Manager of Microsoft France, testifying under oath before the French Senate, stated that he could not guarantee that the data of French customers would be protected from access by US federal authorities — even when stored in Microsoft's European data centres.

This is not a Microsoft-specific failure. It is a structural consequence of building cloud platforms under US corporate jurisdiction, subject to the CLOUD Act — which grants US authorities the right to compel data disclosure by American companies regardless of where that data is physically stored.

The implications for enterprises in banking, healthcare, government, and defence are not theoretical. They are operational. And they are driving one of the fastest-growing market shifts in enterprise infrastructure: the sovereign cloud market, valued at $129 billion in 2025, is projected to reach $572 billion by 2032 — a 24% annual growth rate driven almost entirely by regulatory pressure.

The question for any CDO or CTO evaluating a data platform today is not 'do we need deployment flexibility?' The question is 'what happens when our regulator tells us we needed it six months ago?'

---

What BDB actually supports — and why it took 12 years to build right

BDB supports six distinct deployment configurations from a single unified codebase. Not six different products. Not a 'sovereign edition' that costs three times more and ships six months later. The same platform, the same architecture, the same Kinetic Semantic Layer and Ontology — deployed wherever your data needs to live.

The modular deployment options deserve special attention because they address a problem that most platform vendors ignore: not every enterprise needs the full stack on day one, and not every enterprise wants to replace everything at once.

• An enterprise with a strong existing data warehouse but poor BI governance can deploy BDB's Visualisation module on top of what they have.
• An enterprise with excellent dashboards but fragmented pipelines can deploy the Data Pipeline and Science module.
• An enterprise building a data mesh can deploy the Data Management module — Catalog, Semantic Layer, Data Quality — as the governance backbone, with other tools consuming it through open APIs.

This is what 'meeting the customer where they are' actually looks like in practice. Not a forced rip-and-replace. A modular path to a complete, governed, AI-ready platform — on the customer's timeline.

---

The regulated verticals — and what each actually requires

Deployment flexibility is not a generic capability. Different industries have different regulatory imperatives, and the consequences of getting it wrong range from regulatory fines to contract termination to, in some cases, criminal liability for data officers. Here is what the four key regulated verticals actually need in 2025:

The common thread across all four verticals is that cloud-native-only platforms — regardless of their technical sophistication — cannot serve these requirements without significant architectural compromise. Microsoft's sovereign cloud offering, as noted above, cannot even guarantee sovereignty under oath. Databricks and Snowflake have no on-premises deployment path at all.

BDB is the only end-to-end Data and AI platform in this comparison that can serve all four verticals with a deployment model that satisfies their specific regulatory requirements — from full air-gapped on-premises to cloud to hybrid — without a separate product or a separate price list.

---

The platform comparison — deployment capabilities side by side

---

The migration flexibility argument

There is one deployment scenario that deserves its own discussion: the ability to migrate between cloud providers within two to four weeks at production scale. In past we have done it for a large enterprise as they got decent credits from other cloud vendor.

This is not a selling point that appears in most platform comparisons because most platforms cannot do it. When you are locked into Azure because your semantic model lives in DAX, or locked into AWS because your Glue pipelines are bespoke, or locked into Databricks because your Delta Lake architecture is built on proprietary formats — migrating is a multi-year project, not a three-week one.

BDB's architecture is built on open standards throughout: Postgres, Mongo, Kafka, Kubernetes, Hudi, Iceberg, open metadata formats. There is no proprietary lock-in at any layer. A BDB deployment on AWS can be moved to Azure in three to four weeks because the platform does not depend on any hyperscaler's native services. It uses them as infrastructure, not as architecture.

In a geopolitical environment where cloud provider relationships between governments and enterprises are shifting — and where the cost of being locked into the wrong provider is measured in regulatory exposure, not just migration cost — this is not a minor advantage.

I know this from experience. We lost a major European contract not to a technology failure but to a geopolitical event — a war — and a subsequent management change at the client. The lesson I took from that was not about contracts. It was about architecture: your platform should be able to follow you wherever the business goes next. Ours can.

---

What to verify before your next platform renewal

If you are in an active platform evaluation or approaching renewal, here are four questions that will reveal your current exposure:

BDB was built to answer all four of these questions with confidence. Not because we were clever enough to predict the regulatory future — but because we were disciplined enough to build for it, even when nobody was asking for it yet.

Twelve years of building this platform without institutional support taught me one thing above all else: the constraints that seem like disadvantages in the short term often become the deepest moats in the long term. We could not afford to be cloud-only. So we built for everything. Now the world is catching up.

---

  Your Platform Cannot Follow Your Data