Microsoft released an open-source tool that lets enterprise applications switch between cloud databases without rewriting code. The business case is real. The current state has gaps CIOs need to understand before this shows up in a resilience plan.

By Shashi Bellamkonda · May 4, 2026

Picture building a house, then discovering the foundation only works on one specific plot of land. That is the situation most enterprises face with high-performance cloud databases today. The databases that power global-scale applications, Azure Cosmos DB, Amazon DynamoDB, and Google Cloud Spanner, are each proprietary to their cloud. Choosing one means writing application code specifically for it. Moving to another cloud later means rewriting that code. That is a project measured in months and carried out under pressure, usually during a migration or a regulatory audit, not in ideal conditions.

Microsoft released an open-source project called MulticloudDB that attempts to change that. Write your application's database logic once, then point it at whichever cloud database your situation requires — a customer contract, a regulatory obligation, a disaster recovery scenario — without touching the underlying code. The project carries an MIT license, meaning no vendor fees and no proprietary strings.

Three business pressures made this inevitable

B2B software vendors are increasingly required to deploy in the cloud their enterprise customers already use. A financial services firm running on Google Cloud does not want its software vendor's application data sitting in Azure. Serving that customer without cloud-portable data infrastructure means building and maintaining separate codebases for each cloud, or turning away the deal.

Enterprises operating across multiple clouds for cost or capability reasons face the same constraint from the other direction. Critical applications need to work across all their clouds without separate engineering teams maintaining separate versions.

The sharpest pressure is regulatory. The Digital Operational Resilience Act, or DORA, which took effect January 17, 2025, requires European financial institutions to demonstrate they are not dangerously dependent on a single cloud provider. A bank that runs both production systems and disaster recovery on the same cloud has a concentration risk problem under DORA, regardless of how many data centers that cloud uses. Cross-cloud resilience is now a compliance requirement, not an architecture preference. And cross-cloud resilience requires a data layer that can actually move.

What MulticloudDB actually delivers

The core value is straightforward. Instead of building separate database integrations for each cloud, an engineering team builds one. MulticloudDB translates that single integration into the language each cloud database speaks. Switching from Cosmos DB to DynamoDB to Spanner requires changing a configuration setting, not rewriting application code.

The Azure Cosmos DB team noted that many of their own enterprise customers were already building this kind of translation layer themselves, each organization independently solving the same problem and then maintaining the result indefinitely. MulticloudDB makes that a shared, tested, maintained project. It ships with over 281 tests that run against all three cloud databases to verify portable behavior. The value is not just portability. It is confidence that portability actually holds before you need it during an incident.

For B2B vendors, the business case is direct: stop maintaining separate database codebases per cloud and reduce the engineering cost of winning customers in any cloud environment. For enterprises under DORA, the case is also direct: cross-cloud disaster recovery requires an application stack that can actually run on a different cloud, and the database layer is usually the hardest part to move.

The neutrality question has a straight answer

The project was built by the Azure Cosmos DB team and announced at Azure Cosmos DB Conf 2026. The announcement states it will maintain no affinity to any cloud. Both facts are relevant and neither cancels the other.

The MIT license is a meaningful structural protection. Any organization can inspect the code, contribute to it, or fork it if the project drifts. Open-source governance is the mechanism by which neutrality gets enforced over time. The current provider parity is where to look for early signals. Azure Cosmos DB and DynamoDB are fully supported and available through standard software distribution. Google Cloud Spanner support exists in the codebase but is not yet available through Maven Central, the standard channel Java development teams use to install software dependencies. Teams that need Spanner today must build from source manually.

That gap is not a disqualifier. It is a timing fact. A tool that claims three-cloud portability but currently delivers two clouds through standard channels is a two-cloud tool with a roadmap. That distinction matters before this appears in a DORA compliance document or an architecture review.

Microsoft has stated MulticloudDB will carry production support when it reaches general availability. The project is currently in public preview, which the documentation explicitly notes means it is not yet ready for production deployments.

The direction is right. The production commitment is still ahead.

About Shashi Bellamkonda

Loading bio…

LinkedIn Profile

Get new posts by email:

Subscribe

Powered by