You've decided the database is going to the cloud, and you've picked a migration method. Now comes the question that determines everything downstream — networking, contracts, operations, and what your 3am looks like: where does the database actually live? For most Oracle estates in 2026 that's a choice between OCI native and Oracle Database@Azure — and a third option people keep forgetting, the OCI–Azure Interconnect.
The wrong way to decide is by database features, because that's the trick of it: the database is the same in all three. Same Exadata, same 19c/26ai, same Data Guard, same RMAN. What changes is everything around the database — and that's where the decision really lives.
The short version. Database@Azure puts Oracle-operated Exadata hardware physically inside Azure datacenters: you provision from the Azure portal, latency to your Azure apps is same-building, and the spend burns down your Azure commitment (MACC). OCI native gives you the full Oracle cloud — every service, typically the lowest total cost — and is the obvious home when your apps aren't married to Azure. The Interconnect is the middle path: database in OCI, apps in Azure, under 2ms between them with no egress charges over the link. Decide by three things: where your apps run, who holds your commercial commitments, and how much latency the app-to-database path can afford. And the same template now works for AWS and Google Cloud — Database@AWS and Database@Google Cloud are the identical play on different hosts.
Three options, not two
1. OCI native. The database runs in Oracle's cloud — Exadata Database Service, Autonomous Database, Base Database, or plain compute — alongside the rest of OCI's catalog. One console, one bill, Oracle's infrastructure pricing.
2. Oracle Database@Azure. Oracle ships Exadata racks into Microsoft's datacenters and operates them there. You buy it in the Azure Marketplace, provision it from the Azure portal, and your apps in the same Azure region talk to it at in-datacenter latency. It is genuinely OCI — a slice of Oracle's cloud embedded in Azure — operated by Oracle's own OCI team, with support handled jointly by Oracle and Microsoft.
3. The OCI–Azure Interconnect. The database stays in OCI; your Azure workloads reach it over a private, pre-built link between paired OCI and Azure regions — a dozen region pairs, sub-2ms round-trip, and no ingress/egress charges over the link. (You may also find references to Oracle Database Service for Azure (ODSA), the 2022 portal-sync service built on this link — for new projects it's been superseded in practice by Database@Azure.)
Choosing where an Oracle database lives. Follow app gravity first, then latency, then commercials — the database itself is the same everywhere.
What Database@Azure actually is
The name undersells it. This isn't a connector or a managed VM — it's OCI hardware in Azure buildings:
- The services: Exadata Database Service on Dedicated Infrastructure and on Exascale Infrastructure, Autonomous Database (Serverless and Dedicated), Base Database Service, plus GoldenGate and the Zero Data Loss Autonomous Recovery Service. Oracle Database 19c and the current 26ai are supported — 26ai being 23ai renamed (a single Release Update makes the jump, no upgrade or recertification), which is also why you'll increasingly see the branding Oracle AI Database@Azure.
- The footprint: available in 33 Azure regions and climbing — it more than doubled in the last year.
- The commercial model: purchased through the Azure Marketplace; consumption counts 1:1 toward your Microsoft Azure Consumption Commitment (MACC). Your existing Oracle licenses apply — BYOL or license-included, same as OCI.
- The operating model: Oracle's OCI operations team runs the hardware, patching, and infrastructure; Microsoft runs the datacenter; you get Azure-portal provisioning with Entra ID identity and Azure-native monitoring hooks, while database internals still surface through an OCI console linked to your Azure tenancy.
That last point is the honest fine print: day-2 operations span two control planes. Provisioning, networking, and billing feel like Azure; the deep database machinery is still OCI underneath. Teams that expect a purely Azure experience find the seam; teams that know OCI find it familiar.
The decision factors
| Factor | OCI native | Database@Azure | Interconnect (DB in OCI) |
|---|---|---|---|
| App-to-DB latency | in-OCI | same datacenter | < 2ms between paired regions |
| Buys down Azure MACC | No | Yes — 1:1 | No (OCI spend) |
| Oracle license BYOL | Yes | Yes | Yes |
| Service breadth | Full OCI catalog | Core DB services + GoldenGate + ZRCV | Full OCI catalog |
| Regions | OCI's global footprint | 33 Azure regions | 12 paired regions |
| Consoles | OCI only | Azure portal + OCI (split) | Azure + OCI (two estates) |
| Typical total cost | Lowest | Parity on DB, Azure prices around it | Low DB cost + free link egress |
App gravity beats everything. If the applications, integration layer, identity, and the team's tooling live in Azure — and the CIO's strategy says they stay there — the database follows the apps. Fighting app gravity with a cheaper database quote is how you end up owning a latency problem.
Commercials decide more of this than architects like to admit. A large enterprise with a MACC to burn and an Azure-first mandate has an easy business case for Database@Azure: the same Oracle spend now counts against the Microsoft commitment. Conversely, if you're not carrying Azure commitments, OCI native is usually the cheaper estate — Oracle's compute, storage, and egress pricing undercut the equivalent hyperscaler line items, and that's before you price the second cloud's networking.
Latency is the tiebreaker, not the headline. Sub-2ms over the Interconnect is fine for most applications — batch, reporting, services with sane call patterns. Where it isn't fine is chatty OLTP: an app that makes hundreds of sequential database round-trips per user action multiplies every one of those milliseconds. Measure your app's round-trip count before you let anyone tell you 2ms is nothing — wait events don't lie, and SQL*Net message from client on the database side of a chatty app is exactly where this shows up. (You can measure this multiplication yourself — see the lab below.)
When each one wins
OCI native wins when you're not anchored to Azure: greenfield builds, estates consolidating on Oracle's stack, Exadata Cloud@Customer hybrids, cost-driven migrations, and anywhere you want the whole OCI catalog next to the database. It's also the simplest operationally — one console, one support path, no seam.
Database@Azure wins when the application estate is committed to Azure and the app-to-database path matters: same-datacenter latency, MACC burn-down, Azure-portal provisioning, Entra ID, and Exadata/Autonomous without leaving the building. It's the answer that lets an Azure-first enterprise run real Oracle — not a compromise port — and every migration method works against it, because it's Exadata under the hood.
The Interconnect wins when you want OCI's pricing and catalog and Azure apps, and the app can tolerate single-digit milliseconds. Database in OCI, apps in Azure, private link, no egress fees over it. This is also the natural DR pattern: primary in one cloud, Data Guard standby across the link in the other — a cross-cloud failover story that doesn't require moving the estate.
And if your apps live on AWS or Google Cloud: the identical decision now exists there. Database@AWS and Database@Google Cloud are both generally available — Oracle-operated Exadata inside the other hyperscalers' datacenters — and AWS's own AWS Interconnect added OCI connectivity in preview in 2026. Swap the vendor names and this whole article still applies.
What teams get wrong
- Deciding on database features. The database is identical in all three options. The decision is about apps, contracts, latency, and operations — never about the engine.
- Ignoring the split control plane. Database@Azure provisioning is Azure; deep database operations are OCI. Budget for your team learning both, or the first incident will do the teaching.
- Treating 2ms as free. For chatty OLTP, interconnect latency compounds per round-trip. Profile the app's call pattern first; move the database into the same building only if the numbers say so.
- Leaving MACC on the table. If the company has an Azure commitment, Database@Azure spend counts toward it 1:1 — finance may like the "more expensive" option better than your spreadsheet does.
- Forgetting the Interconnect exists. Not every Azure app needs the database in Azure. The middle path keeps OCI economics with Azure proximity — and nobody promotes it, because neither vendor's sales team owns it.
- Assuming Azure ends the DR conversation. Wherever the database lands, it still needs a protection architecture — Data Guard across regions (or clouds), backups, and a tested restore.
The one-paragraph version
Follow the apps. If they're committed to Azure and the app-to-database path is chatty, put the database in the same building — Database@Azure, which is real Oracle-operated Exadata inside Azure, bought through the Marketplace and burning down your MACC. If they're committed to Azure but the path tolerates a few milliseconds, consider the Interconnect — database in OCI at OCI prices, sub-2ms away, no egress over the link. If the apps aren't anchored to Azure, OCI native is the default: full catalog, one console, lowest total cost. The engine is identical everywhere — so decide on app gravity, commercial commitments, and latency, in that order. The same template now answers the AWS and Google Cloud versions of this question, too.
Measure it before you decide it. The
latency/lab runs this post's chatty-vs-batched experiment on your own machine: Oracle Database Free in Docker, withtc neteminjecting the 0ms / 2ms / 10ms of the three homes above. Same database, same rows — the chatty workload went from 0.7s to 3.6s to 11.8s as the latency rose, while the batched one barely moved (0.1s → 0.3s). The round-trip counts come fromv$mystat, and the run fails unless the elapsed times actually match the injected delay — so it only passes if the math is real. Chatty apps don't have a cloud problem; they have a round-trip problem that latency exposes.Want to try the OCI side for free? Oracle Autonomous Database on OCI Always Free gives you a real, fully managed 26ai database — no license, no server, no cost — and it's the same Autonomous service that runs inside Database@Azure. Standing one up is the fastest way to feel how the OCI half of this decision operates before you commit an estate to it.
Frequently asked questions
What is Oracle Database@Azure?
Oracle Database@Azure is Oracle-operated database infrastructure — Exadata Database Service (Dedicated and Exascale), Autonomous Database (Serverless and Dedicated), Base Database Service, GoldenGate, and the Zero Data Loss Autonomous Recovery Service — running on Oracle hardware physically located inside Microsoft Azure datacenters. You purchase it through the Azure Marketplace, provision it from the Azure portal, and your Azure applications reach it at in-datacenter latency. It is available in 33 Azure regions.
Who operates Database@Azure — Microsoft or Oracle?
Oracle. The hardware is owned, patched, and operated by Oracle Cloud Infrastructure personnel; Microsoft provides the datacenter, the Azure-side networking, and the portal integration. Support is handled jointly, so you can raise issues through either vendor. Day to day you provision from the Azure portal, while deeper database operations surface through an OCI console linked to your Azure tenancy.
Does Database@Azure spend count toward my Azure commitment (MACC)?
Yes. Oracle Database@Azure is purchased through the Azure Marketplace and consumption counts 1:1 toward a Microsoft Azure Consumption Commitment. For organizations carrying a large MACC, that often makes the business case by itself — the Oracle database spend reduces the Microsoft commitment.
Can I bring my own Oracle licenses to Database@Azure or OCI?
Yes, both. Database@Azure and OCI database services support bring-your-own-license (BYOL) as well as license-included pricing, so existing Oracle Database licenses and support agreements carry over to either destination.
What is the difference between Database@Azure and the OCI–Azure Interconnect?
Database@Azure puts the database physically inside the Azure datacenter — same-building latency, Azure Marketplace billing, MACC burn-down. The Interconnect keeps the database in OCI and links it privately to a paired Azure region at under 2 milliseconds round-trip with no ingress/egress charges over the link. The Interconnect preserves OCI pricing and the full OCI catalog; Database@Azure wins when the app-to-database path is latency-critical or the commercials favor Azure. The older Oracle Database Service for Azure (ODSA) portal service has been superseded in practice by Database@Azure for new projects.
Is Database@Azure more expensive than running in OCI?
The database services are priced comparably, but the estate around them usually is not: OCI compute, storage, and egress typically cost less than the Azure equivalents, so OCI native tends to have the lowest total cost. Database@Azure changes the calculation when a MACC is in play, because the spend burns down an existing Microsoft commitment — the accounting can favor it even when the sticker price does not.
How do I migrate an existing Oracle database into Database@Azure?
The same way you would migrate to Exadata in OCI — because it is Exadata. All the standard methods apply: Data Pump for simple moves with an outage, Data Guard for near-zero-downtime same-endian migrations with easy rollback, transportable tablespaces with RMAN CONVERT for very large or cross-endian moves, GoldenGate when you are crossing versions or need a fallback, and ZDM to automate whichever fits. Autonomous targets accept logical methods only.
Do Database@AWS and Database@Google Cloud work the same way?
Yes — both are generally available and follow the same model: Oracle-operated Exadata and Autonomous services physically inside AWS and Google Cloud datacenters, purchased through the respective marketplaces and counting toward those clouds' commitments. AWS's own AWS Interconnect service added OCI connectivity in preview in 2026. The decision framework — app gravity, commercial commitments, then latency — is identical; only the vendor names change.
Wherever the database lands, the architecture questions that follow are the same ones this blog keeps coming back to: which migration method gets you there with the downtime you can afford, which protection architecture keeps it alive once it's there, and whether you can prove a restore on the worst day. The cloud changes the building; it doesn't change the job.
Originally published at uptimearchitect.com. I write here in a personal capacity — questions or feedback are welcome via the contact page.
Top comments (0)