MulticloudDB SDK: Cross-cloud portability in the coding agent era

Building cross-cloud solutions with best-of-breed cloud-native databases means learning multiple SDKs, translating queries, handling different errors, and testing across providers. The Multicloud DB SDK for Java lets you share that work across Azure Cosmos DB, Amazon DynamoDB, and Google Cloud Spanner. You (or your coding agent) write CRUD and query logic against one Java API, with provider selection and connection settings in configuration.

We demonstrated one application running unchanged across two providers at Azure Cosmos DB Conf 2026 on April 28, 2026, in MultiCloudDB: Write Once. Run Anywhere.. The SDK is in public preview, with a roadmap for general availability. You’ll find the current details in the repository, documentation, and samples.

Why make every application solve the same portability problems? Each team has to work out how queries, failures, and supported operations differ between databases, then keep that knowledge up to date as providers change. A shared SDK gives teams somewhere to reuse those decisions and tests.

Each provider adds query translation, error handling, tests, and ongoing maintenance.

But if a coding agent can draft a new implementation and its tests in minutes, how much of this work do we still need to share? There are two questions worth separating.

You can. The work is checking that the rewritten application still behaves as expected. Does it handle missing values the same way? Does pagination skip or repeat results? What happens when a write is throttled or only part of an operation succeeds? The answers depend on the databases involved, and the tests need to catch those differences. The SDK puts that work into shared adapters and conformance tests, so each application doesn’t have to start again.

The fact that code generation is cheap actually makes a shared, tested abstraction more valuable, not less. As coding agents make implementation faster, the bottleneck shifts from writing code to validating that it behaves correctly. The MulticloudDB SDK gives you a head start on that validation: its shared contract and provider implementations have already been tested together for supported operations. Why make every application repeat that work when developers and coding agents can build on the same tested SDK?

A coding agent can build a common interface and the adapters behind it. Establishing that they behave correctly takes much longer and requires detailed knowledge of each database. Someone has to define what the shared API promises, check that each provider can meet those promises, and test query translation, pagination, error handling, and failure scenarios. Coding agents can help with all of this, but generated code and tests can share the same mistaken assumptions. Passing those tests isn’t enough to establish that the contract is right or that every adapter implements it correctly.

That validation takes time and expertise, even when coding agents do much of the coding. The MulticloudDB SDK brings a tested implementation and cross-provider conformance tests that applications can reuse, with Microsoft support planned for general availability. Today it remains a public preview with limited support. Building your own abstraction means your team takes on that validation, ongoing maintenance, and support responsibility.

Research on coding agents helps explain why interface design matters here. SWE-agent studied how interfaces for editing code and running tests affect coding agent performance. Anthropic’s guidance on simple, composable patterns and tool design also emphasizes clear operations, useful errors, and evaluation. Neither evaluates this SDK, but both inform the approach: give coding agents documented operations and feedback they can use to check their work.

A fix in a shared adapter can help every application that uses it.

• Portable CRUD and query. One Java API for create, read, update, and delete, plus a query DSL translated into each native query language.
• Provider switching by configuration. Select the provider and supply its connection settings without rewriting supported CRUD and query operations.
• Capability introspection. Check what a provider supports before choosing a code path.
• Normalized errors and diagnostics. Common failure categories and diagnostic fields, with provider details retained.
• Native access. nativeExpression() and nativeClient() let you use provider-specific features. Those calls need their own provider-specific tests.
• Cross-provider conformance tests. Conformance suites run the same operations against each provider emulator to check shared behavior.

The shared API sits above provider adapters, with capability checks and access to native features.

MulticloudDbClientConfig config = MulticloudDbClientConfig.builder()
        .provider(ProviderId.fromId(props.getProperty("multiclouddb.provider")))
        .connection("endpoint", props.getProperty("multiclouddb.connection.endpoint"))
        .connection("key", props.getProperty("multiclouddb.connection.key"))
        .build();

MulticloudDbClient client = MulticloudDbClientFactory.create(config);
ResourceAddress products = new ResourceAddress("appdb", "products");
Key key = Key.of("books", "product-42");

client.upsert(products, key, productDocument);
DocumentResult loaded = client.read(products, key);

Provider selection stays outside the code:

multiclouddb.provider=cosmos
multiclouddb.connection.endpoint=${DATABASE_ENDPOINT}
multiclouddb.connection.key=${DATABASE_KEY}

For DynamoDB or Spanner, use dynamo or spanner with the appropriate provider module and connection settings. Data modeling and supported capabilities still differ. Check the documentation and README for current dependencies and setup instructions.

Try a few CRUD and query operations from an application you work on against each provider emulator. We’d like to hear what works, what’s missing, and where you still need provider-specific code.

We plan to expand support when the SDK reaches general availability. Your feedback will help us prioritize that work. Open an issue or feature request to suggest an operation or database, report unexpected behavior, or discuss your requirements with the team.

• MulticloudDB SDK for Java on GitHub
• MulticloudDB SDK documentation
• MulticloudDB SDK sample applications
• Azure Cosmos DB Conf 2026 and the conference announcement
• SWE-agent: Agent-computer interfaces enable automated software engineering
• Building effective agents and Writing tools for agents