Oracle Database@Azure vs Native Azure Databases
Oracle Database@Azure vs Native Azure Databases
Article Overview
Every Oracle-to-Azure conversation eventually reaches the same fork: keep the Oracle engine and run it on Oracle Database@Azure, or convert the workload to a native Azure database and never pay an Oracle licence again. Both answers are defensible, and the wrong one is expensive in different ways. This article puts Oracle Database@Azure side by side with Azure SQL Database, Azure SQL Managed Instance, and Azure Database for PostgreSQL flexible server — the four options that actually show up on enterprise shortlists — and compares them on architecture, performance behaviour, licensing economics, scalability ceilings, high availability, and workload fit. It closes with a decision framework, a worked cost-thinking exercise, and the mistakes that most often turn a good platform choice into a bad project.
1.The Fork in the Road
A migration programme starts with an inventory. Somewhere in that spreadsheet is a row for every Oracle database in the estate, and next to each one somebody has to write a target platform. That single column decides how much the programme costs, how long it takes, and how much risk it carries.
The temptation is to answer it ideologically. One camp argues that moving Oracle to Azure while still paying Oracle is a half-migration — that the point of the cloud is to escape proprietary licensing, and anything else is a missed opportunity. The other camp argues that rewriting twenty years of PL/SQL to chase a licence saving is how programmes die, and that the database engine is the least interesting thing to modernise.
Both camps are right about specific workloads and wrong as a general policy. The useful question is not "Oracle or native?" but rather:
For this workload, what does the Oracle engine actually give me that a native Azure database does not — and is that worth the licence, the operating model, and the migration path that comes with it?
Answering that requires knowing what each platform genuinely does, not what its marketing page claims. That is what the rest of this article is for.
📚 Assumed background
This article assumes you know roughly what Oracle Database@Azure is. If not, start with the beginner's guide covering its architecture, delegated subnet model, and deployment tiers — the comparison below builds on those concepts rather than re-explaining them.
2.Meet the Four Contenders
These four cover the overwhelming majority of enterprise database targets on Azure. Each solves a distinctly different problem.
Oracle Database@Azure
Real Oracle Database (19c or 23ai) on Oracle-managed Exadata infrastructure physically located in Azure datacenters. Provisioned through Azure Resource Manager, reached over your own VNet via a delegated subnet, billed on your Azure agreement. Available as Base Database, Exadata Dedicated, Exadata Exascale, and Autonomous AI Database.
Azure SQL Managed Instance
A near-complete SQL Server instance delivered as a managed service. Cross-database queries, SQL Agent, CLR, Service Broker, linked servers, instance-scoped objects. The natural landing zone for a SQL Server estate that cannot be broken into single databases.
Azure SQL Database
Database-scoped PaaS with three service tiers. General Purpose and Business Critical follow the classic coupled compute-and-storage model; Hyperscale separates them, giving fast scaling and very large databases. Built for applications designed around a single database boundary.
Azure Database for PostgreSQL
Managed community PostgreSQL on the flexible server deployment model, with Burstable, General Purpose, and Memory Optimized tiers. No proprietary licence at all — you pay for compute and storage. The default target for greenfield development and for cost-driven conversions away from commercial engines.
💡 What is deliberately not here
Oracle on Azure Virtual Machines, Azure Cosmos DB, Azure Database for MySQL, and third-party engines on AKS all have valid use cases, but they answer different questions. This comparison is about the four platforms an enterprise realistically weighs when deciding where a relational Oracle or SQL Server workload should live.
3.Architecture at a Glance
Almost every practical difference between these platforms — how they scale, how they fail over, how fast a large scan runs — traces back to one architectural decision: where the storage intelligence lives.
3.1 Why the storage tier decides so much
On a conventional database, a query that scans a large table pulls every candidate block across the network into the database server's buffer cache, and the engine discards the rows that do not match. The network and the buffer cache become the constraint long before CPU does.
Exadata's answer is to move the filter to the storage servers. Smart Scan applies predicates and column projection inside the storage tier, so only qualifying rows travel back. Storage indexes let entire storage regions be skipped without reading them. Columnar flash cache keeps hot data in a format suited to analytic access. For a large scan-heavy workload, this can be the difference between minutes and seconds, and it is not something you can replicate by buying a bigger VM.
Hyperscale's answer is different but equally consequential: separate the storage into a fleet of page servers with a dedicated log service, and cache aggressively on the compute node. That does not accelerate scans the way Smart Scan does, but it makes compute scaling, backup, and restore essentially independent of how much data you hold — which is a different and often more valuable property.
SQL Managed Instance and PostgreSQL flexible server both keep the classic model: one engine, storage attached beneath it. Simpler, cheaper, entirely adequate for the majority of workloads, and the source of their scaling ceilings.
4.Performance
⚠️ On benchmarks
Vendor benchmark numbers for these platforms are close to useless for planning. Oracle's licence terms have historically restricted publishing database benchmarks, published TPC results rarely match enterprise workloads, and every vendor tunes the test to its own strengths. Treat the discussion below as a guide to architectural performance characteristics, and settle the actual question with a proof of concept on your own data and your own queries.
4.1 Where each platform is genuinely fast
| Workload shape | Oracle Database@Azure | SQL Managed Instance | Azure SQL Database | PostgreSQL |
|---|---|---|---|---|
| Short OLTP transactions | Excellent. RAC spreads sessions across nodes; flash cache absorbs hot blocks. | Excellent on Business Critical — local SSD, In-Memory OLTP available. | Excellent on Business Critical; very good on Hyperscale with warm cache. | Very good on Memory Optimized with correctly sized IOPS. |
| Large analytic scans | Class-leading. Smart Scan and storage indexes cut the data volume at source. | Adequate. Columnstore indexes help, but all filtering happens on the instance. | Good with columnstore; Hyperscale reads from page servers rather than local disk. | Adequate. Parallel query helps; no storage-side offload exists. |
| Mixed OLTP + reporting on one dataset | Strong — the classic Exadata case, with reporting offloaded to storage rather than fighting OLTP for cache. | Good with a Business Critical read-only replica. | Good with named replicas on Hyperscale. | Fair — read replicas are asynchronous and add lag. |
| Very high write throughput | Strong, with the caveat that RAC write contention on hot blocks needs design attention. | Good; log throughput is the usual ceiling. | Hyperscale's dedicated log service is designed for exactly this. | Good, bounded by disk IOPS and checkpoint tuning. |
| Thousands of concurrent connections | Strong with shared server and connection pooling across RAC nodes. | Good; worker limits scale with vCores. | Good; connection limits scale with tier. | Needs PgBouncer. PostgreSQL uses a process per connection, so raw connection counts hurt. |
4.2 The PostgreSQL connection caveat
This deserves calling out because it surprises teams migrating from Oracle. PostgreSQL forks a backend process per connection, so connection count translates directly into memory pressure. Azure's flexible server publishes a default maximum connection count per tier and vCore configuration, reserves a number of connections (currently 15) for replication and monitoring, and ships PgBouncer as the built-in pooling answer. Microsoft's advice is to put PgBouncer in transaction mode, open with a deliberately small pool — on the order of two to five connections for every vCore — and only widen it after watching what resource consumption actually does.
An Oracle application that opens 2,000 sessions and holds them idle will run acceptably on Exadata and fall over on an unpooled PostgreSQL server. That is an application architecture change, not a tuning knob, and it belongs in the migration estimate.
4.3 The storage-IOPS coupling on PostgreSQL
One more PostgreSQL-specific behaviour worth understanding before you size anything: on flexible server the size of the disk you buy is also the amount of I/O you get, and whichever VM series you picked applies a second ceiling above that. Choosing a small disk for a small dataset can silently cap throughput; choosing a large VM with a small disk wastes the compute. Microsoft's performance guidance walks through configurations where aligning both compute and storage — for example a 32-vCore server paired with a 60,000-IOPS Premium SSD v2 disk — is what actually delivers the throughput, rather than scaling either one alone.
Note also that storage on flexible server scales up only. There is no supported shrink operation; reducing size means dumping and restoring into a new server.
4.4 What "faster" really means in a business case
Teams often frame this as raw speed when the real question is predictability under load. Exadata's appeal to a bank running month-end close is not that a single query is faster in isolation; it is that a heavy reporting run does not evict the OLTP working set from cache and turn a four-hour close into a fourteen-hour one. Hyperscale's appeal is not raw scan speed; it is that a 40 TB database restores in minutes rather than a day, so recovery objectives stop being aspirational.
A practical POC design
Take your ten worst queries by total elapsed time from AWR or Query Store, your peak concurrency profile, and one realistic batch window. Run those — not a synthetic benchmark — on each candidate platform at the size you would actually buy. Two weeks of that produces a better answer than two months of spreadsheet comparison.
5.Licensing and Cost Models
Licensing is where the four platforms diverge most sharply, and where the largest sums of money move. The structures are genuinely different, not just differently priced.
5.1 Oracle Database@Azure
Two consumption models exist. Licence Included bundles Oracle Database Enterprise Edition, advanced options, and management packs into the hourly rate — attractive if you do not already hold entitlements, or if you want options you have never licensed. Bring Your Own Licence (BYOL) applies Oracle licences you already own and in active support, at a materially lower subscription rate.
The billing metric depends on the service. Exadata Database Service uses ECPUs on dedicated X11M environments and on Exascale Infrastructure; earlier Exadata generations bill in OCPUs. For comparison purposes Oracle states that one OCPU equals four ECPUs. On the Exadata service the compute you consume and the rack it runs on are two separate purchases with two separate lines on the bill. Anyone who models the per-ECPU rate alone will under-forecast badly.
Minimums matter for small deployments. Oracle documents a minimum of two OCPUs per node for Exadata Database Service. Autonomous AI Database works differently: a node has to be stood up with at least 10 OCPUs or 40 ECPUs behind it, but you are not charged for that floor. What you actually pay for starts at 1 OCPU, or 2 ECPUs, once a database is running.
⚠️ Do not take BYOL conversion ratios from blog posts
Conversion rates between on-premises Oracle licence metrics and cloud ECPU/OCPU entitlements are published in Oracle's PaaS and IaaS Universal Credits Service Descriptions, and third-party summaries of them frequently disagree with each other. The ratio materially changes your business case, so read the current Service Descriptions document and confirm the number with Oracle in writing before you build a model on it.
Two commercial features are unique to this platform and often decide the outcome. Spend counts toward a Microsoft Azure Consumption Commitment (MACC), so an organisation with a large committed Azure spend can fund Oracle databases from money it has already promised to spend. And customers with on-premises Oracle licences remain eligible for Oracle Support Rewards, reducing support costs elsewhere in the estate.
5.2 Azure SQL Database and SQL Managed Instance
Both are sold on the vCore model, with the SQL Server licence either bundled into the rate or discounted through Azure Hybrid Benefit (AHB) if you hold SQL Server core licences with active Software Assurance or a qualifying subscription.
The AHB conversion rules are worth memorising because they are unusually favourable in one specific case:
| You own | You receive |
|---|---|
| One SQL Server Standard core (with SA) | One vCore in the General Purpose tier |
| One SQL Server Enterprise core (with SA) | One vCore in the Business Critical tier |
| One SQL Server Enterprise core (with SA), highly virtualized workloads | Up to four vCores in General Purpose or Hyperscale — the 1:4 exchange |
You can pool several Standard licences to cover a bigger General Purpose footprint. What you cannot do is pool your way into Business Critical — that tier is gated on Enterprise edition entitlements, and no quantity of Standard licences substitutes. The same core cannot be counted twice: an entitlement covers either the on-premises deployment or the Azure one. During a migration you get a 180-day window where both are tolerated, and then the on-premises use has to stop.
⚠️ The Hyperscale Azure Hybrid Benefit deadline
A December 2023 change closed Azure Hybrid Benefit to newly created Hyperscale databases and to dev/test subscriptions altogether. Single databases created before that change, running provisioned compute, keep the discount only through December 2026 — after that they move onto the simplified Hyperscale rates whether you planned for it or not. If your business case for Hyperscale assumes AHB savings, check the creation date of the database and the calendar — this is one of the most commonly missed cost cliffs in Azure data platform planning.
5.3 Azure Database for PostgreSQL
There is no database licence. You pay for compute (by tier and vCore), provisioned storage, backup beyond the included allowance, and any high-availability replica. That is the entire structure. For a workload that fits comfortably inside PostgreSQL's capabilities, this is usually the cheapest of the four by a wide margin, and the cost model is the easiest to forecast.
The costs that do exist are less visible: extension compatibility work, application changes, connection pooling infrastructure, and the engineering time to replace features that came free in a commercial engine.
5.4 Licensing summary
| Oracle Database@Azure | SQL Managed Instance | Azure SQL Database | PostgreSQL | |
|---|---|---|---|---|
| Licence model | Licence Included or BYOL | Bundled or Azure Hybrid Benefit | Bundled or AHB (Hyperscale restricted) | None — open source |
| Billing metric | ECPU or OCPU, plus infrastructure | vCore + storage | vCore or DTU + storage | vCore + storage |
| Existing licences reusable | Yes, including ULAs | Yes, with Software Assurance | Yes, with restrictions on Hyperscale | Not applicable |
| Counts toward Azure commitment | Yes (MACC) | Yes | Yes | Yes |
| Vendor support relationship | Joint Oracle + Microsoft | Microsoft | Microsoft | Microsoft, community engine |
| Typical relative cost | Highest | Moderate to high | Moderate | Lowest |
6.Scalability and Ceilings
Every platform here scales further than most workloads need. The interesting question is what happens when you hit a ceiling — whether you can grow through it, or whether you have to change platforms.
6.1 Published ceilings
Figures below reflect current Microsoft and Oracle documentation at the time of writing. All of them move, so verify before designing.
| Dimension | Oracle Database@Azure | SQL Managed Instance | Azure SQL Database | PostgreSQL flexible server |
|---|---|---|---|---|
| Max compute | Scales with Exadata infrastructure — add database servers and ECPUs; the practical ceiling is the rack, not the software | Bounded by hardware generation; premium-series and memory-optimized premium-series set the top end | Hyperscale runs from 2 vCores up to 128 on premium-series hardware, or 80 on standard-series, with larger 160 and 192 options still in preview | General Purpose and Memory Optimized reach 96 vCores, and 128 or 192 on v6-series hardware |
| Max storage | Petabyte-class on dedicated Exadata; Exascale draws from an elastic pool | Up to 16 TB on classic General Purpose, 32 TB on next-generation General Purpose; Business Critical bounded by local SSD | Hyperscale starts small and runs to a 128 TB ceiling; the vCore count you pick does not constrain how much data you hold | Up to 32 TiB on Premium SSD in supported regions; Premium SSD v2 extends this where available |
| Memory ceiling | Determined by the Exadata shape and node count | Flattens out on the largest shapes — past roughly 80 vCores on premium-series, and past roughly 64 on the memory-optimized variant, extra cores stop buying extra memory | Roughly 5 GB per vCore provisioned; about 3 GB per vCore on serverless | 4 GiB per vCore on General Purpose; 6.75 to 9.5 GiB per vCore on Memory Optimized |
| Scale-out writes | Yes — Real Application Clusters is genuinely active-active for writes | No — single writer | No — single primary; replicas are read-only | No — single writer; replicas are read-only |
| Scaling disruption | ECPU changes are online; infrastructure changes are not, and generally force replacement | Tier and size changes involve a failover | Hyperscale compute scales in minutes without moving data; serverless scales in under a second | Compute scaling requires a restart; storage grows online but never shrinks |
6.2 The escape hatches
What matters more than the headline number is what you do when you approach it.
- SQL Managed Instance → Hyperscale. When a Managed Instance runs out of storage headroom, Microsoft's own answer is to look at Hyperscale rather than to keep growing MI. That is a real migration, not a slider — you give up instance-scoped features to get the storage ceiling.
- PostgreSQL at the storage cap. Hitting the regional Premium SSD limit means moving to Premium SSD v2 where available, or redeploying. Teams have been caught by a region that simply does not offer the larger disk type.
- Hyperscale beyond 128 TB. Sharding at the application layer, or a different platform entirely.
- Oracle at the rack. Add Exadata infrastructure, or move to Exascale. Growth here is a procurement exercise rather than an architectural one, which is precisely what large estates are paying for.
📊 The scale-out asymmetry
Only Oracle offers active-active write scale-out through Real Application Clusters. The three Azure-native platforms all scale writes vertically and reads horizontally. For most applications that is fine — a single large modern node handles enormous write volumes. But if your architecture genuinely depends on multiple instances writing to one database, RAC is not a feature you can substitute, and that alone can settle the platform decision.
7.High Availability and Disaster Recovery
Availability architecture is where the Oracle premium is easiest to justify — and also where teams most often over-buy.
| Capability | Oracle Database@Azure | SQL Managed Instance | Azure SQL Database | PostgreSQL |
|---|---|---|---|---|
| Local HA | RAC — surviving instances keep serving; no failover of the database itself | Business Critical uses Always On availability groups across replicas | Business Critical replicas; Hyperscale HA secondaries | Zone-redundant or same-zone HA with a standby server |
| Zone redundancy | Infrastructure can be placed across two Azure availability zones | Supported on eligible tiers | Supported on eligible tiers | Zone-redundant HA available in supported regions |
| Cross-region DR | Data Guard and Active Data Guard, with zero-data-loss configurations | Auto-failover groups | Auto-failover groups; geo-replication | Read replicas across regions, promoted manually |
| Readable standby | Yes, with Active Data Guard | Yes, on Business Critical | Yes, named replicas on Hyperscale | Yes, asynchronous read replicas |
| Restore speed for very large data | Fast, and Zero Data Loss Autonomous Recovery Service is available on the platform | Proportional to database size | Backup and restore run off storage snapshots, so a 40 TB database does not take forty times longer than a 1 TB one | Proportional to database size |
| Formal availability framework | Oracle Maximum Availability Architecture, up to platinum tier | Service-level tiers | Service-level tiers | Service-level tiers |
7.1 The distinction that actually matters
Every platform here survives a node failure. The difference is what "survives" means to a connected application.
On RAC, when an instance dies, the other instances are already open on the same database. Sessions on the failed node reconnect to a surviving node, and with Application Continuity configured, in-flight work can be replayed rather than lost. There is no promotion step, because nothing was standing by — it was already serving.
On the Azure-native platforms, a failure triggers a failover: a standby is promoted, and connections are re-established against the new primary. Modern implementations make this fast and largely invisible to well-written applications, but there is a window, and applications that do not implement retry logic will see errors during it.
For most systems, a brief failover window is entirely acceptable and vastly cheaper. For a payments switch or a trading system where a dropped transaction has direct financial consequence, the difference is exactly what you are paying Oracle for.
💡 Before you buy RAC-grade availability
Check whether your application actually implements connection retry and idempotent transactions. Many enterprise applications assume the database never goes away, which means they would fail during a Data Guard switchover too. If the application cannot survive a five-second interruption, fixing the application is often cheaper than buying infrastructure that never interrupts.
8.Enterprise Workload Fit
Abstract comparison only goes so far. Here is how the four platforms map onto the workloads that actually appear in enterprise estates.
8.1 Packaged Oracle applications
Winner: Oracle Database@Azure, without contest. Oracle E-Business Suite, PeopleSoft, JD Edwards EnterpriseOne, Enterprise Performance Management, and Retail applications have published support policies for running on Azure with this service as the database tier. Converting the database under a packaged application is not merely difficult — it usually voids support. This category is not a comparison; it is a single-option decision.
8.2 Packaged SQL Server applications
Winner: SQL Managed Instance. The mirror image of the above. Third-party applications built on SQL Server typically depend on instance-level features — SQL Agent jobs, cross-database queries, linked servers, CLR assemblies — that Azure SQL Database does not expose. MI exists precisely for this case.
8.3 Custom in-house Oracle applications
It depends, and this is the real battleground. Work through these questions in order:
- How much PL/SQL exists, and does anyone understand it? Tens of thousands of lines of undocumented business logic is a conversion project measured in years.
- Does it use features with no clean equivalent — advanced queuing, complex partitioning strategies, Spatial, Text, materialized view query rewrite?
- Is the data volume or query pattern one where Exadata offload genuinely earns its cost?
- Is the application already changing for other reasons? A conversion attached to a rewrite that is happening anyway costs a fraction of a standalone conversion.
Where the answers point to a thin data-access layer over a manageable schema, PostgreSQL is frequently the right target and the savings are permanent. Where they point to deep engine coupling, Oracle Database@Azure lets the application move to Azure now and be modernised later — or never, which is a legitimate outcome.
8.4 Greenfield and cloud-native development
Winner: PostgreSQL, usually. No licence, huge extension ecosystem, deep familiarity across the developer market, and a straightforward operating model. Azure SQL Database is the equally sensible answer for teams whose skills and tooling are already Microsoft-centric.
8.5 Data warehousing and analytics
Split decision. If the warehouse must sit next to a transactional Oracle system and query it directly, Exadata's offload plus Autonomous AI Database's data warehouse workload type is a strong answer. If you are building a modern analytics estate, the more likely destination is Microsoft Fabric or Databricks, with any of these four acting as a source system. Notably, Oracle Database@Azure can mirror into OneLake with continuous zero-ETL synchronisation and offers native GoldenGate integration — so choosing Oracle does not exclude you from the Fabric analytics story.
8.6 SaaS multi-tenant platforms
Winner: Azure SQL Database. Elastic pools, per-tenant databases, and Hyperscale's fast provisioning and scaling are designed for exactly this shape. PostgreSQL with schema-per-tenant is a solid alternative. Oracle's licensing economics rarely suit a model where you need thousands of small databases.
8.7 Mission-critical, zero-data-loss systems
Winner: Oracle Database@Azure. RAC plus Data Guard plus Maximum Availability Architecture up to platinum tier remains the most complete answer to "this system must not lose a transaction, ever." The Azure-native platforms offer excellent availability; they do not offer this specific combination.
8.8 Workload fit summary
| Workload | Primary recommendation | Credible alternative |
|---|---|---|
| Oracle EBS, PeopleSoft, JDE, EPM, Retail | Oracle Database@Azure | None — support policy decides |
| Third-party SQL Server applications | SQL Managed Instance | SQL Server on Azure VMs |
| Custom Oracle app, heavy PL/SQL | Oracle Database@Azure | PostgreSQL, if a rewrite is funded |
| Custom Oracle app, thin data layer | PostgreSQL | Azure SQL Database |
| Greenfield microservices | PostgreSQL | Azure SQL Database |
| Multi-tenant SaaS | Azure SQL Database | PostgreSQL |
| Very large mixed OLTP and reporting | Oracle Database@Azure | Hyperscale with named replicas |
| Zero-data-loss financial systems | Oracle Database@Azure | Business Critical with auto-failover groups |
| Dev, test, and departmental databases | PostgreSQL or Base Database Service | Azure SQL Database serverless |
9.Migration Effort and Lock-In
The platform you choose determines not only what you pay, but how much project you buy.
9.1 Being honest about lock-in
Lock-in arguments are often used to justify a conversion, so they deserve scrutiny.
Choosing Oracle Database@Azure keeps you on Oracle — but you were already on Oracle, and the service is available on multiple clouds, so it arguably reduces cloud lock-in while preserving engine lock-in. Choosing SQL Managed Instance or Azure SQL Database keeps you on Microsoft's engine and, for the PaaS-specific behaviours, on Azure. Choosing PostgreSQL gives you the most portable engine in the comparison, though Azure-specific operational tooling still creates friction if you ever leave.
The uncomfortable truth is that converting a database to escape lock-in usually costs more than the lock-in does, unless the conversion is riding on a change that was happening anyway. Do the arithmetic rather than the ideology.
10.Operations, Security, and AI Integration
A frequently overlooked point in favour of Oracle Database@Azure is that it does not force a separate operating model. Because resources are created through Azure Resource Manager, the governance tooling you already run extends to them.
| Capability | Oracle Database@Azure | Azure-native databases |
|---|---|---|
| Azure RBAC and Policy | Yes — requests flow through ARM | Yes |
| Azure Monitor | Database logs, metrics, and events surface in Azure | Native |
| Microsoft Defender / Sentinel | Supported | Native |
| Entra ID for control-plane access | Yes; optional federation into the OCI tenancy | Native |
| Key Vault for encryption keys | Supported, but requires private endpoint plus DNS configuration and advanced networking | Native, simpler to configure |
| Azure Arc | Supported | Native |
| Cost Management | Yes — consumption lands on the Azure invoice | Yes |
| Second console required | Some database-level tasks still route through the OCI console or APIs | No |
| Microsoft Fabric / OneLake | Mirroring into OneLake plus native GoldenGate integration | Native mirroring |
The honest caveat is the last two rows. Oracle Database@Azure is deeply integrated, but it is not indistinguishable from a first-party Azure database: certain operations still require OCI, and Key Vault integration carries prerequisites that a native service does not. Budget for that in your operating model, and make sure the DBA team has OCI access before an incident rather than during one.
10.1 The AI angle
Both sides of this comparison now have a credible story for AI workloads, which was not true two years ago. Oracle Database 23ai provides vector search as a native data type inside the database, and Oracle Database@Azure can feed Microsoft Fabric, Power BI, Copilot Studio, and Azure AI Foundry. PostgreSQL has pgvector and the broadest open-source ecosystem for retrieval workloads. Azure SQL Database has added vector capabilities and sits naturally alongside the rest of the Microsoft AI stack.
In practice the deciding factor is rarely the vector feature itself; it is where the enterprise data already lives, and how much work it takes to get it somewhere a model can use it.
11.What Deployment Looks Like
Provisioning code says a lot about an operating model. Below is the same conceptual task — stand up a production-shaped database — on each platform, with Terraform. Names and sizes are illustrative; validate arguments against current provider documentation before using any of it.
11.1 Oracle Database@Azure
Two resources, and the second one depends on infrastructure that takes hours to provision.
resource "azurerm_oracle_exadata_infrastructure" "this" {
name = "exa-infra-prod"
resource_group_name = azurerm_resource_group.this.name
location = var.location
zones = ["1"]
display_name = "exa-infra-prod"
shape = "Exadata.X11M"
compute_count = 2
storage_count = 3
database_server_type = "X11M"
storage_server_type = "X11M-HC"
}
resource "azurerm_oracle_cloud_vm_cluster" "this" {
name = "vmc-erp-prod"
resource_group_name = azurerm_resource_group.this.name
location = var.location
cloud_exadata_infrastructure_id = azurerm_oracle_exadata_infrastructure.this.id
cluster_name = "erpprod01" # max 11 chars, no underscores
hostname = "erpdb"
gi_version = "19.0.0.0"
cpu_core_count = 8
memory_size_in_gbs = 240
db_node_storage_size_in_gbs = 240
data_storage_size_in_tbs = 4
license_model = "BringYourOwnLicense"
time_zone = "UTC"
# The delegated subnet is what makes this reachable from your VNet
subnet_id = azurerm_subnet.oracle_delegated.id
virtual_network_id = azurerm_virtual_network.this.id
backup_subnet_cidr = "192.168.252.0/22"
ssh_public_keys = [var.ssh_public_key]
}11.2 Azure SQL Managed Instance
One resource, but it needs a dedicated subnet with a route table and delegation of its own, and provisioning is measured in hours for the first instance in a subnet.
resource "azurerm_mssql_managed_instance" "this" {
name = "mi-erp-prod"
resource_group_name = azurerm_resource_group.this.name
location = var.location
administrator_login = "sqladmin"
administrator_login_password = var.mi_admin_password
license_type = "BasePrice" # BasePrice = Azure Hybrid Benefit applied
sku_name = "GP_Gen5"
vcores = 8
storage_size_in_gb = 512
subnet_id = azurerm_subnet.mi_delegated.id
# Zone redundancy is available on eligible tiers
zone_redundant_enabled = false
identity { type = "SystemAssigned" }
tags = { workload = "erp" }
}11.3 Azure SQL Database (Hyperscale)
Minutes, not hours. Note the deliberate absence of a storage size — Hyperscale grows on demand up to its ceiling.
resource "azurerm_mssql_server" "this" {
name = "sqlsrv-app-prod"
resource_group_name = azurerm_resource_group.this.name
location = var.location
version = "12.0"
administrator_login = "sqladmin"
administrator_login_password = var.sql_admin_password
minimum_tls_version = "1.2"
}
resource "azurerm_mssql_database" "this" {
name = "appdb-prod"
server_id = azurerm_mssql_server.this.id
sku_name = "HS_Gen5_8" # Hyperscale, 8 vCores
read_replica_count = 1 # HA secondary
zone_redundant = true
# Azure Hybrid Benefit is not available for new Hyperscale databases,
# so license_type is deliberately omitted here.
tags = { workload = "custom-app" }
}11.4 Azure Database for PostgreSQL
The simplest of the four, and the one where sizing storage correctly matters most because storage size drives IOPS.
resource "azurerm_postgresql_flexible_server" "this" {
name = "pg-app-prod"
resource_group_name = azurerm_resource_group.this.name
location = var.location
version = "16"
sku_name = "MO_Standard_E8ds_v5" # Memory Optimized, 8 vCores
storage_mb = 2097152 # 2 TiB - also sets the IOPS ceiling
administrator_login = "pgadmin"
administrator_password = var.pg_admin_password
# Private networking into your own VNet
delegated_subnet_id = azurerm_subnet.pg_delegated.id
private_dns_zone_id = azurerm_private_dns_zone.pg.id
backup_retention_days = 35
geo_redundant_backup_enabled = true
high_availability {
mode = "ZoneRedundant"
standby_availability_zone = "2"
}
maintenance_window {
day_of_week = 0
start_hour = 2
start_minute = 0
}
}
# Connection pooling is not optional at enterprise connection counts
resource "azurerm_postgresql_flexible_server_configuration" "pgbouncer" {
name = "pgbouncer.enabled"
server_id = azurerm_postgresql_flexible_server.this.id
value = "true"
}💡 What the code tells you
Oracle needs infrastructure before it needs a database, and both are slow. Managed Instance needs a purpose-built subnet. Azure SQL Database needs almost nothing. PostgreSQL needs you to think about storage sizing and pooling from the first line. Those differences show up again on day 200, not just day one.
11.5 The same query, four dialects
A small but honest illustration of conversion effort. Pagination — a trivial requirement — is written four different ways, and this is one of the easy cases.
-- Oracle (12c and later)
SELECT order_id, customer_id, order_total
FROM orders
ORDER BY order_date DESC
OFFSET 100 ROWS FETCH NEXT 25 ROWS ONLY;
-- SQL Server / Azure SQL / SQL MI
SELECT order_id, customer_id, order_total
FROM orders
ORDER BY order_date DESC
OFFSET 100 ROWS FETCH NEXT 25 ROWS ONLY;
-- PostgreSQL
SELECT order_id, customer_id, order_total
FROM orders
ORDER BY order_date DESC
LIMIT 25 OFFSET 100;
-- Oracle, legacy style still common in older codebases
SELECT * FROM (
SELECT a.*, ROWNUM rnum FROM (
SELECT order_id, customer_id, order_total
FROM orders ORDER BY order_date DESC
) a WHERE ROWNUM <= 125
) WHERE rnum > 100;Now multiply that by hierarchical queries, analytic functions with different syntax, sequence semantics, empty-string-versus-NULL handling, date arithmetic, and every packaged procedure in the schema. That is what "high migration effort" means in the table above.
12.A Decision Framework
Run each workload through these questions in order. The first one that produces a definitive answer is the answer — do not keep going.
✅ Expect a mixed estate
A well-run migration almost never lands on a single platform. A realistic outcome for a large enterprise is tier-one ERP on Oracle Database@Azure, a SQL Server application estate on Managed Instance, new development on PostgreSQL, and a SaaS product on Azure SQL Database. Insisting on one platform for everything is how organisations end up over-paying for small databases and under-provisioning large ones.
13.Thinking About Total Cost
List prices change constantly, so specific numbers here would be wrong within a quarter. What does not change is the shape of the cost, and that is what a business case should model.
| Cost element | Oracle Database@Azure | SQL MI | Azure SQL DB | PostgreSQL |
|---|---|---|---|---|
| Infrastructure floor | High on dedicated Exadata; much lower on Exascale and Base Database | None beyond the instance | None | None |
| Compute | Per ECPU or OCPU hour | Per vCore | Per vCore, or per second on serverless | Per vCore |
| Software licence | Bundled or offset by BYOL | Bundled or offset by AHB | Bundled; AHB restricted on Hyperscale | None |
| Storage | Included on dedicated compute models; backups charged separately | Provisioned | Consumed (Hyperscale) or provisioned | Provisioned, and it sets your IOPS |
| HA / DR replica | Data Guard target is additional capacity | Included in Business Critical | Replica count is billable | Standby is billable |
| One-off migration cost | Low | Low | Medium to high from Oracle | High from Oracle |
| Ongoing DBA effort | Moderate; lowest on Autonomous | Low | Low | Low to moderate |
13.1 The four questions that decide the business case
- Do you already own Oracle licences in active support? BYOL changes the Oracle number substantially. An organisation mid-way through an unlimited licence agreement is in a very different position from one buying fresh.
- Do you have an Azure commitment to burn? Oracle Database@Azure spend counts toward a MACC. If you have committed spend you are struggling to consume, the effective cost of the Oracle option drops sharply.
- What does the conversion actually cost? Price the migration project honestly — developer months, testing, parallel running, defect remediation, and the opportunity cost of the roadmap work not being done. Then compare it against several years of licence differential. Conversions frequently lose that comparison.
- What happens if you do nothing? The cost of staying on ageing on-premises hardware, with its refresh cycle and support risk, is the real baseline — not zero.
⚠️ The most common modelling error
Comparing the Oracle subscription against the PostgreSQL subscription and declaring PostgreSQL cheaper. It is, per hour. The comparison is only meaningful once the conversion project, the retest cycle, the application changes for connection pooling, and the risk premium are on the same spreadsheet. Sometimes PostgreSQL still wins by a mile — but you should know that, not assume it.
14.Common Mistakes
Choosing one platform for the whole estate
A single standard sounds like good governance and usually produces over-provisioned small databases and under-provisioned large ones. Standardise the decision process instead of the destination.
Assuming Exadata makes bad SQL fast
Smart Scan accelerates scans; it does not fix a missing index, a bad execution plan, or a chatty application. Teams have moved to Exadata expecting a free performance win and found the same bottleneck, at higher cost.
Forgetting the Hyperscale AHB cliff
New Hyperscale databases cannot use Azure Hybrid Benefit at all, and the databases that still can lose it at the end of December 2026. A multi-year business case built on that discount needs revisiting.
Migrating to PostgreSQL without pooling
An Oracle application with thousands of persistent sessions will overwhelm an unpooled PostgreSQL server. PgBouncer is not a tuning afterthought; it is part of the target architecture.
Under-sizing PostgreSQL storage
Disk size and throughput are the same purchase here, and that purchase only ever moves in one direction. Sizing the disk to the data rather than to the throughput requirement caps performance in a way that is awkward to undo.
Ignoring the delegated-subnet design
Oracle Database@Azure and SQL Managed Instance both require purpose-built subnets with specific rules. Networking is where these projects lose weeks, and it is entirely avoidable with early design.
Treating the POC as a formality
Vendor sizing tools produce a number. Your ten worst queries produce the truth. Skipping the proof of concept is how organisations discover a ceiling in production.
Confusing lock-in with cost
"Avoiding lock-in" is a valid strategic goal and a poor justification on its own. If the conversion costs more than the lock-in premium over the planning horizon, it is a preference, not a business case.
15.Master Comparison Table
Everything above, condensed. Use it as a checklist rather than a scorecard — the rows are not equally weighted, and which ones matter depends entirely on the workload.
| Oracle Database@Azure | SQL Managed Instance | Azure SQL Database | PostgreSQL flexible server | |
|---|---|---|---|---|
| Engine | Oracle Database 19c / 23ai | SQL Server (instance-scoped) | SQL Server (database-scoped) | Community PostgreSQL |
| Runs on | Oracle-managed Exadata in Azure datacenters | Azure-managed infrastructure | Azure-managed infrastructure | Azure-managed VM plus disk |
| Operated by | Oracle (platform) + you (database) | Microsoft | Microsoft | Microsoft |
| Storage offload | Yes — Smart Scan, storage indexes | No | Page server tier, no predicate offload | No |
| Active-active writes | Yes (RAC) | No | No | No |
| Max data size | Petabyte-class | 16 TB classic GP, 32 TB next-gen GP | 128 TB on Hyperscale | 32 TiB Premium SSD; more with SSD v2 |
| Compute range | Scales with Exadata infrastructure | Bounded by hardware generation | 2–128 vCores (160/192 preview) | Up to 96, or 128/192 on v6 |
| Licence | Included or BYOL | Bundled or AHB | Bundled; AHB restricted on Hyperscale | None |
| Counts toward MACC | Yes | Yes | Yes | Yes |
| Cross-region DR | Data Guard / Active Data Guard | Auto-failover groups | Auto-failover groups, geo-replication | Cross-region read replicas |
| Restore time at scale | Fast; ZDLRA available | Size-dependent | Snapshot-based, largely size-independent | Size-dependent |
| Migration from Oracle | Lift and shift | Not applicable | Conversion project | Conversion project |
| Second management plane | Some tasks via OCI console | No | No | No |
| Provisioning time | Hours for Exadata; minutes for Autonomous | Hours for a new subnet | Minutes | Minutes |
| Relative cost | Highest | Moderate to high | Moderate | Lowest |
| Best at | Packaged Oracle apps, tier-one OLTP, very large mixed workloads | SQL Server estates that need instance-level features | Modern apps, SaaS, very large single databases | Greenfield, cost-sensitive, portable workloads |
16.Frequently Asked Questions
Is Oracle Database@Azure faster than Azure SQL Database?
For large scan-heavy and mixed workloads, Exadata's storage offload gives it a genuine architectural advantage that cannot be matched by scaling a native service vertically. For ordinary OLTP at moderate scale, the difference is often negligible and does not justify the cost. The honest answer is workload-specific, which is why a proof of concept on your own queries matters more than any benchmark.
Can I run Oracle on Azure without Oracle Database@Azure?
Yes — Oracle on Azure Virtual Machines has been supported for years and remains appropriate for smaller or licence-constrained deployments. You take on all the operational work and lose the Exadata storage stack, but you also avoid the infrastructure floor.
Which is cheaper, Oracle Database@Azure or PostgreSQL?
PostgreSQL, per hour, essentially always. Whether it is cheaper overall depends on the conversion project, and that comparison is frequently much closer than it first appears. Model both including one-off costs before deciding.
Does SQL Managed Instance support everything SQL Server does?
Close to it, but not entirely. Microsoft maintains a documented list of feature and T-SQL differences, and a compatibility assessment is a standard first step in any MI migration. It is far broader than Azure SQL Database's surface, which is the main reason to choose it.
When should I choose Hyperscale over Business Critical?
When database size, backup and restore speed, or fast compute scaling matter more than the lowest possible transaction latency. Hyperscale supports databases up to 128 TB independent of compute size, and because recovery works from storage snapshots, restore duration barely tracks how much data you hold. Business Critical still wins on raw local-SSD latency.
Can I use Azure Hybrid Benefit with Oracle Database@Azure?
No — AHB is a Microsoft SQL Server and Windows Server programme. The Oracle equivalent is BYOL, applying Oracle licences you already own, and Oracle Support Rewards for customers with on-premises entitlements.
Is PostgreSQL enterprise-ready?
Yes, for a very wide range of workloads. What it lacks relative to Oracle is not robustness but specific capabilities: active-active write clustering, storage-tier query offload, and some of the mature tooling around very large partitioned estates. Most applications never touch those.
Can these platforms coexist?
Yes, and in practice they nearly always do. All four sit in the same virtual network, feed the same analytics estate, and appear on the same Azure invoice. A mixed estate is the normal outcome of doing this well, not a sign of indecision.
What if my workload outgrows SQL Managed Instance?
Microsoft's answer is Hyperscale — once storage demand passes what MI can hold, that is the documented next step. Plan for the fact that this is a migration with feature implications, not a configuration change.
How do I decide quickly for a large estate?
Segment first. Packaged applications resolve themselves on vendor support policy. Dev, test, and small departmental databases go to the cheapest platform that fits. That usually leaves 10–20 percent of the estate requiring real analysis, and that is where the decision framework in section 12 earns its keep.
17.Verdict
There is no winner here, and any article that declares one is selling something. There are four platforms with genuinely different centres of gravity.
✅ Key Takeaways
• Oracle Database@Azure is the right answer when the Oracle engine itself is doing work you cannot replicate — packaged Oracle applications, RAC, Exadata offload, Maximum Availability Architecture — or when a conversion is not funded. It is the most expensive per hour and by far the cheapest to migrate to.
• SQL Managed Instance is the right answer for SQL Server estates that need instance-scoped features. It exists to make that migration boring, and it succeeds.
• Azure SQL Database is the right answer for applications designed around a single database boundary, for multi-tenant SaaS, and — via Hyperscale — for very large databases that need fast scaling and near-instant restores.
• Azure Database for PostgreSQL is the right answer for greenfield work and for portable workloads where the licence saving is real and the conversion cost is low or already funded.
• The decision is per workload, never per estate. Segment first, analyse the hard 10–20 percent properly, and prove the answer with your own queries rather than a vendor's benchmark.
The genuinely new thing in this landscape is that "keep Oracle" and "move to Azure" stopped being opposites. For a decade, an Oracle estate was the reason a migration stalled. It no longer has to be — which means the conversation can finally be about what each workload actually needs, rather than about which vendor an organisation is willing to keep paying.
That is a better conversation to be having, and it is worth having it workload by workload rather than settling it in a strategy document.
Comments