Oracle: Database Rent and AI Infrastructure Risk

Evidence scope and standing

Oracle Corporation is four companies that reinforce each other but obey different economic laws. First, it is a database rent collector with one of the deepest installed bases in enterprise computing. Second, it is a cloud infrastructure challenger attempting to convert historical database gravity into new infrastructure consumption. Third, it is an enterprise applications vendor competing for the operational records of governments, hospitals, manufacturers, banks, and large enterprises. Fourth, and increasingly central to the equity story, it is a vendor of AI data center capacity: a company that assumes energy, GPU, network, financing, and counterparty risks to sell scarce compute capacity to model developers and large enterprises.

The central research question is whether Oracle’s old monopoly rent economics can survive the company’s shift towards a much more capital‑intensive infrastructure model. Public evidence indicates that Oracle has achieved a genuine inflection in cloud infrastructure growth. The sceptical reading is that this inflection is not simply a software‑margin story. It is partly a project‑finance story, partly an energy‑supply story, partly a GPU‑supply‑chain story, and partly a story of counterparty concentration. Oracle’s FY2026 results make this explicit: cloud infrastructure revenue grew much faster than the rest of the company, but free cash flow turned markedly negative while capital expenditure surged. Oracle’s own disclosure that a large portion of the RPO increase comes from large AI contracts, including customer‑prepaid or customer‑supplied GPUs, is unusually important because it shows that the reported backlog is tied to hardware funding and construction execution, not just conventional SaaS subscription visibility.

Canonical company record: Oracle Corporation. Public ticker: ORCL on the New York Stock Exchange. Canonical web properties include the corporate website, Oracle Cloud, Oracle Investor Relations, and Oracle documentation domains. The company is not a simple directory entry. Oracle is a critical enterprise infrastructure operator whose risk surface now spans software licensing, regulated workloads, multi‑cloud interconnection, data‑center construction, power availability, GPU procurement, public‑sector modernisation, and security‑incident response.

The public‑company frame

Oracle’s latest narrative as a public company is a sharp transition from a mature software‑cash generator to an AI‑infrastructure growth vehicle. In FY2026 Oracle reported total revenue of $67.4 billion, up 17 %, with total cloud revenue of $34.0 billion, up 39 %. Within that, cloud infrastructure revenue was $18.1 billion, up 77 %, while cloud applications revenue was $15.9 billion, up 11 %. The contrast matters: the applications business remains large and sticky, but the growth story is now OCI, not legacy software or SaaS alone. In the fourth quarter of FY2026 Oracle reported $19.2 billion of revenue, $9.9 billion of cloud revenue, $5.8 billion of cloud infrastructure revenue, and $4.1 billion of cloud applications revenue. Software revenue for the full year was $24.5 billion, down 1 %, supporting the view that Oracle is migrating customers from on‑premise software and maintenance to cloud services, rather than simply layering cloud revenue on top of an unchanged base.

The balance‑sheet and cash‑flow implications are more revealing than the growth rate. Oracle reported operating cash flow of $32.0 billion for FY2026, but negative free cash flow of $23.7 billion. Its cash‑flow statement shows capex of $55.7 billion in 2026, versus $21.2 billion in 2025. Net property, plant and equipment after depreciation rose from $43.5 billion to roughly $100.0 billion. Non‑current borrowings and other debt rose from $85.3 billion to $122.3 billion. These numbers are the financial signature of a company leaving software rent and moving into the ownership and operation of physical infrastructure.

Oracle’s reported remaining performance obligations (RPO) were the most dramatic evidence. RPOs ended Q4 2026 at $638 billion, up 363 % year‑on‑year and $85 billion higher than the previous quarter. Oracle stated that the bulk of the RPO increase in Q3 and Q4 came from large‑scale AI contracts in which the customer either prepaid Oracle for GPUs or purchased and supplied GPUs to Oracle; the prepaid portion and customer‑supplied hardware within these large AI contracts together total $75 billion. That is a strong demand signal, but also a warning that the quality of the backlog depends on delivery milestones, data‑centre energisation, customer concentration, GPU depreciation curves, and the future financial strength of a handful of AI buyers.

The public‑company thesis is therefore split. Oracle’s software side produces durable operating cash flow from deeply established enterprise systems. The infrastructure side demands large up‑front financial commitments and may generate attractive returns if AI demand remains supply‑constrained. The risk is that the accounting picture of the backlog may run ahead of physical delivery, and that cloud infrastructure revenue growth absorbs rather than frees cash during the build‑out phase.

The database‑rent machine

Oracle’s deepest economic moat remains the installed base of Oracle Database. It is not merely a product position. It is a transaction‑cost position. Oracle databases underpin ERP systems, billing systems, banking systems, claims systems, government records, manufacturing systems, telecom mediation layers, hospital records, and custom applications written over decades. The database’s value is not just the engine. It is the accumulated, stored procedures, operational tooling, DBA knowledge, failover design, compliance validation, performance tuning, disaster‑recovery procedures, and application certifications that surround it.

The pricing remains striking. Oracle’s US public‑sector list price in May 2026 shows Oracle Database Enterprise Edition at $47,500 per processor for a perpetual licence, with $10,450 for software update and support. Real Application Clusters is listed at $23,000 per processor plus $5,060 support, Partitioning at $11,500 per processor plus $2,530 support, Advanced Security at $15,000 per processor plus $3,300 support, Diagnostics Pack at $7,500 per processor plus $1,650 support, and Tuning Pack at $5,000 per processor plus $1,100 support. Named‑user pricing is also shown, including $950 for Database Enterprise Edition and $209 support. These list prices are not average realised prices, and large enterprises negotiate heavily, but they illustrate the modular rent structure: the database licence is just the start; high availability, security, optimisation, diagnostics, partitioning, and other options add separate billable layers.

This is the economic core of Oracle’s historical pricing power. A customer running Oracle Database for a mission‑critical workload rarely evaluates the renewal decision as a green‑field technology choice. They evaluate the cost of migration failure. The database rent is therefore protected by the cost of rewriting application logic, validating data equivalence, retraining DBAs, re‑validating integrations, changing backup and recovery practices, and surviving an audit or regulatory review. In banking, insurance, healthcare, and the public sector, “migration” is not a weekend operation. It is a multi‑year operational‑risk programme.

DB‑Engines is not a revenue‑share source or a market‑share table. It is, however, a useful indicator of popularity and mindshare. In June 2026, DB‑Engines ranked Oracle first among database systems, ahead of MySQL, Microsoft SQL Server, PostgreSQL, and MongoDB; the same ranking also placed Snowflake sixth, Databricks seventh, and SAP HANA twenty‑second. That positioning supports the view that Oracle remains central in the minds of database users, even as newer analytical and data‑lake systems gain attention.

The economics of the installed base are also visible in Oracle’s licence‑management apparatus. Oracle License Management Services describes itself as the only Oracle licence authority that can verify Oracle programme requirements, and lists both the assurance service and the audit service. The official framing is compliance assistance, but from the customer’s perspective the threat of audit is part of the vendor’s negotiating leverage. Large customers do not pay Oracle merely because they like the database. They also pay to avoid uncertainty over processor counts, option usage, virtualisation boundaries, user counts, and support obligations.

Practitioner commentary reinforces the point. UpperEdge, an enterprise‑technology negotiation consultancy, describes Oracle licensing in VMware environments as a recurring customer pain point and argues that Oracle’s policy may require licensing an entire server farm or cluster, because the database could potentially run on connected servers. This is not a court ruling or a settled law. It matches a long‑standing customer pattern: Oracle’s licensing model can turn infrastructure‑architecture choices into commercial exposure.

The result is a rent‑extraction machine with three reinforcing loops. First, critical data remains where it is because migration is risky. Second, support and audit compliance turn technical dependency into recurring commercial leverage. Third, OCI gives Oracle a migration path that does not require handing the database rent to another hyperscaler. That is why Oracle’s cloud strategy must be read as defensive as much as offensive: OCI is a means to keep the database inside Oracle’s economic perimeter.

OCI as a cloud challenger

Oracle Cloud Infrastructure does not seek to win the hyperscale market by copying AWS feature‑by‑feature at equal scale. Its most plausible strategy is to win specific workloads where Oracle holds an asymmetry: Oracle databases, regulated enterprise systems, sovereign cloud deployments, high‑performance bare‑metal compute, multi‑cloud database proximity, and, now, AI training capacity.

The footprint is significant but uneven. Oracle’s documentation states that OCI regions are localised geographical areas made up of one or more availability domains. Availability domains are isolated from each other and do not share infrastructure such as power, cooling, or the internal availability‑domain network. The same documentation notes that Oracle has chosen to launch regions in new geographical areas with a single availability domain in order to expand rapidly. The commercial‑regions table shows a broad global footprint, but many regions have a single availability domain, while some important ones such as Frankfurt, London, Ashburn, Chicago, and Phoenix have three.

This architecture is commercially rational. A single‑availability‑domain region can meet data‑residency, latency, or government‑access requirements more quickly and cheaply than a fully built hyperscale region with multiple ADs. It also aligns with Oracle’s enterprise selling motion: customers often want a local database region, a sovereign region, a government realm, or a dedicated deployment rather than a huge developer platform. The sceptical point is that single‑AD regions are not equivalent to the mature multi‑AD region designs that customers associate with AWS, Azure, or Google Cloud for highly available cloud‑native workloads. Oracle’s own documentation states that multi‑region deployment aids business continuity and disaster protection. The availability‑domain model therefore matters when assessing whether OCI is a generalist hyperscale peer or a more specialised enterprise‑and‑database cloud.

The public OCI regions page states that OCI has 41 commercial cloud regions across 26 countries, including 14 countries plus the EU with two or more regions for in‑country disaster recovery. It also highlights globally consistent pricing, a private Oracle‑managed backbone between regions, encrypted traffic between regions and availability domains, 10 TB per month of free outbound bandwidth with lower pricing thereafter, more than 40 regions worldwide, and more than 70 compliance standards, including SOC, PCI DSS, HIPAA, HITRUST, and GDPR. These claims sit at the heart of Oracle’s economic pitch: OCI is not just compute, storage, and networking; it is cost predictability, compliance, and database proximity.

Oracle’s service‑availability page states that every OCI region supports more than 200 cloud services and that OCI offers uniform pricing across all public cloud regions, including Dedicated Region. It also lists multi‑cloud services, including Oracle AI Database@AWS, Oracle AI Database@Azure, Oracle AI Database@Google Cloud, and interconnection services for Azure and Google Cloud. The specific region‑pairing tables matter because they show that Oracle’s multi‑cloud strategy is not just marketing. Oracle deliberately places its database services adjacent to AWS, Azure, and Google Cloud regions so that applications can stay with the dominant hyperscalers while the database rent stays with Oracle.

This is an astute inversion of cloud competition. AWS, Azure, and Google Cloud have captured much of the developer and application layer. Oracle is not trying to undo all of that. It is trying to make Oracle Database an attached service inside or adjacent to those clouds. The customer gets low‑latency access to Oracle databases without migrating fully to OCI. Oracle retains the database consumption, the support relationship, and potentially the enterprise‑account control. In economic terms, Oracle is trying to tax data gravity even when the application gravity belongs to another cloud.

AI infrastructure: the capacity vendor

Oracle’s AI‑infrastructure strategy is larger and more unusual than a standard cloud GPU product launch. The company is selling capacity into a market where leading model developers need land, power, liquid cooling, high‑bandwidth networks, GPU supply, storage throughput, and rapid execution. The scarcity is not just about chips. It is about operational capacity that is powered, networked, permitted, and working.

Oracle’s AI‑infrastructure page states that OCI Supercluster can run up to 131,072 GPUs and lists scalability performance including more than 100,000 GB200 Superchips, 131,072 B200 GPUs, 65,536 H200 GPUs, 32,768 A100 GPUs, 16,384 H100 GPUs, and 16,384 AMD MI300X GPUs per cluster. It also highlights bare‑metal instances, custom RDMA over Converged Ethernet design, cluster‑network latency of 2.5–9.1 microseconds, cluster‑network bandwidth up to 3,200 Gb/s, front‑end network bandwidth up to 400 Gb/s, local NVMe storage, and high‑performance file storage. These are not standard enterprise‑cloud talking points. These are AI‑factory talking points.

The relationship with OpenAI is the clearest public signal of Oracle’s capacity strategy. In July 2025, OpenAI announced it had struck a deal with Oracle to develop 4.5 gigawatts of additional Stargate data‑centre capacity in the United States. OpenAI noted that together with Stargate I in Abilene, the partnership would bring Stargate to more than 5 gigawatts of AI data‑centre capacity under development, running more than 2 million chips. OpenAI also said that parts of the Abilene facility were operational and that Oracle had started delivering Nvidia GB200 racks in June 2025, with early training and inference workloads underway.

In September 2025, OpenAI expanded the Stargate narrative, announcing that five new AI data‑centre sites in the United States with Oracle and SoftBank would bring planned Stargate capacity to almost 7 gigawatts and more than $400 billion of investment over three years. The July Oracle deal represented a partnership exceeding $300 billion over five years, and the Oracle‑related sites in Shackelford County, Texas; Doña Ana County, New Mexico; the Midwest; and a potential expansion near Abilene could deliver more than 5.5 gigawatts. This is utility‑scale infrastructure, but the economics look more like energy‑intensive industrial capacity leasing than conventional enterprise software.

Crusoe, Oracle’s infrastructure partner in Abilene, stated in September 2025 that the first phase of the Abilene campus was online on OCI, that construction had started in June 2024, that the first two buildings were energised within a year, that Oracle had begun delivering Nvidia GB200 racks in June 2025, and that the planned eight‑building campus would support hundreds of thousands of GPUs on a single integrated network fabric. This is corroborating partner evidence, albeit still from a self‑interested party. It supports the view that Oracle is not simply registering paper demand; it is participating in a real physical deployment.

But capacity vending introduces a different risk class. A database licence has negligible marginal cost once the software is built. A GPU cluster carries depreciation risk, power risk, maintenance risk, network risk, liquid‑cooling risk, firmware risk, supply‑chain risk, and utilisation risk. A customer delay, a change in model training, a chip‑generation transition, or a power constraint can hurt returns. Oracle’s RPO disclosure partially reduces the funding concern since customers have prepaid or supplied GPUs, but it does not remove execution risk. It may even highlight how the largest AI customers negotiate bespoke terms that differ from normal cloud consumption.

Capital intensity and energy constraints

The primary constraint on Oracle’s AI strategy is not commercial demand. It is deliverable capacity. The practical bottlenecks are land, grid interconnection, power generation, transformers, switchgear, water‑ or liquid‑cooling design, permits, fibre routes, GPU procurement, labour, and the ability to operate high‑density clusters reliably. Oracle’s 2026 cash‑flow statement shows this transition clearly: capex reached $55.7 billion and free cash flow turned negative despite strong operating‑cash generation. Oracle raised $43 billion of debt and $5 billion of equity finance during FY2026 and said it expects to raise roughly $40 billion through debt and equity in 2027, including a previously announced $20 billion at‑the‑market equity issuance.

The power evidence around Abilene shows why this is an industrial‑infrastructure play. AP reported in March 2026 that Microsoft was taking over an adjacent expansion of the Abilene AI data centre after OpenAI declined to proceed with it, while Crusoe continued to complete six more buildings for OpenAI and Oracle. AP also reported that the broader Abilene complex was expected to provide 2.1 gigawatts of computing capacity, that the Microsoft project included a 900‑megawatt on‑site power plant, and that the existing OpenAI‑Oracle project had a 350‑megawatt gas‑fired plant described by Oracle as backup power while the data centres drew mainly from the regional grid. This is journalistic evidence rather than a contract filing, but it is consistent with the physical scale implied by the official announcements of OpenAI and Crusoe.

A second unofficial signal is the local tax economics. Business Insider reported that Oracle was contesting the property‑tax assessment of its Stargate data‑centre site in Abilene and that the project was eligible for an 85 % property‑tax abatement. The same report said that Crusoe had committed to spend up to $3.5 billion and create 357 full‑time jobs, with Oracle benefiting as a sub‑tenant. This points to local‑incentive and tax‑minimisation economics, not wrongdoing. It shows that data‑centre capacity is negotiated not only in boardrooms but also through local tax bases, property assessments, and economic‑development deals.

The capital‑market concern is not imaginary. Reuters reported in September 2025 that Moody’s flagged counterparty risk in Oracle’s large AI contracts, noting reliance on a small number of AI companies and describing Oracle’s data‑centre build‑out as effectively one of the world’s largest project financings. Reuters reported Moody’s view that Oracle’s debt would rise faster than EBITDA, contributing to prospective leverage of around 4x before EBITDA catches up, and that free cash flow would likely remain negative for an extended period before breaking even. This is a credit‑analyst signal, not a default forecast, but it is a useful corrective to equity‑market enthusiasm about the backlog.

Counterparty risk is amplified by the economics of the leading AI buyers. Reuters, citing The Information, reported in September 2025 that OpenAI had raised its projected cash burn through 2029 to $115 billion as it accelerates infrastructure spending. The report also noted that OpenAI had deepened its Oracle partnership and added Google Cloud among its providers. This is a secondary report of a private company forecast rather than audited evidence. It is nonetheless directly relevant: the main upside for Oracle in AI infrastructure depends on customers whose own cash flows, fundraising, and strategic compute choices remain highly dynamic.

Interconnection economics and the multi‑cloud trade‑off

Oracle’s multi‑cloud strategy is a direct response to a structural problem: the enterprise application layer has moved to AWS, Azure, and Google Cloud faster than Oracle could convert those customers to OCI. Rather than insisting that customers move everything to OCI, Oracle embeds or places Oracle database services adjacent to the customer’s cloud topology of choice.

The economics are simple. Moving a database is expensive and risky. Moving an application server or an analytics workload is easier. If Oracle can reduce the latency and egress pain between the hyperscalers’ applications and Oracle databases, it can retain the database account while letting customers run the rest of their architecture elsewhere. The interconnection strategy therefore turns cloud rivalry into cloud proximity. Oracle does not need to become the default cloud for all workloads to preserve the database rent. It needs to remain the trusted system‑of‑record for the data those workloads query and update.

The economics of OCI’s public regions support this positioning. Oracle advertises a redundant private backbone between regions and 10 TB per month of free outbound bandwidth with lower prices beyond. Its service‑availability page lists Oracle AI Database@AWS, Oracle AI Database@Azure, and Oracle AI Database@Google Cloud, along with specific interconnection pairings for Azure and Google Cloud. The implication is that Oracle competes on the cost of data movement and operational continuity, not just on compute price.

For customers, the trade‑off is attractive but not neutral. Oracle database services inside or next to other clouds reduce migration pressure and can avoid a forced rewrite. But they also preserve Oracle’s position in the architecture. The customer can escape on‑premise hardware and some data‑centre burden, while remaining bound to Oracle database semantics, support obligations, options, and commercial‑negotiation cycles. Multi‑cloud can therefore lower operational friction while extending vendor dependence.

Enterprise applications and switching costs

Oracle’s applications business is less dramatic than the AI‑infrastructure story, but it remains strategically important. Fusion Cloud ERP, HCM, SCM, EPM, NetSuite, industry applications, and Oracle Health give Oracle access to business processes, not just technical infrastructure. Applications generate data, workflows, and user habits. Databases store them. Cloud infrastructure runs them. AI features can attach to them. This is the full‑stack enterprise strategy.

Switching costs are especially high where Oracle applications intersect with regulated processes. ERP systems encode financial controls, purchasing rules, tax logic, inventory processes, and audit trails. HCM systems encode payroll, benefits, workforce classification, and compliance. Healthcare systems encode clinical workflows, patient records, and interoperability obligations. Public‑sector systems encode procurement law, budget appropriations, personnel classifications, and records‑retention requirements. A customer may not like Oracle and still be economically rational in renewing.

Oracle’s application position also reinforces OCI. A Fusion, NetSuite, or Oracle Health customer is easier to sell adjacent OCI services than a neutral cloud buyer. Conversely, an OCI database customer is easier to sell application modernisation than a purely AWS‑native account. This is not automatic. SAP, Workday, ServiceNow, Salesforce, Microsoft, and industry‑specific vendors compete for the process layer. But Oracle’s cross‑sell logic is credible because the same CIO or agency technology office often holds the risk for both application continuity and database continuity.

The sceptical point is that enterprise applications have a different growth ceiling from AI infrastructure. Oracle Cloud Applications revenue grew 11 % in FY2026, versus 77 % for cloud infrastructure. Applications are sticky and profitable but are not the source of the current re‑rating narrative. The applications business is better understood as a stabiliser and a data‑gravity generator than as the main source of upside.

Public sector and regulated industries

Oracle has exceptionally deep exposure to public‑sector and regulated workloads. Oracle’s US Defense Cloud page states that Oracle Cloud supports DoD customers through OCI, that Oracle U.S. Defense Cloud is authorised for DISA Impact Levels 2, 4 and 5, and that Oracle National Security Regions are air‑gapped IL6‑authorised environments for Secret and Top Secret workloads. The same page emphasises globally consistent pricing across deployment models and no egress fees in national‑security regions. This matters because public‑sector workloads value accreditation, isolation, procurement vehicles, and continuity more than developer‑fashion cycles.

Healthcare is the most important regulated‑industry test because of Oracle’s Cerner acquisition. The Department of Veterans Affairs’ EHR modernisation programme remains a cautionary tale. The GAO testified in 2025 that the VA’s EHR modernisation had made incremental improvements but still lacked up‑to‑date information on the duration of the modernisation or reliable estimates of its cost. The GAO also stated that many surveyed users reported reduced productivity and that substantial previous recommendations remained open. This is not solely an Oracle failure; large public‑sector health‑IT programmes are complex, and the VA is the contracting authority. But it is a real signal that Oracle Health’s regulated‑workload opportunity carries implementation and political risk.

The public‑sector opportunity is therefore double‑edged. Oracle can win because governments already run Oracle databases and back‑office systems, and because accredited cloud regions are hard to replicate. But every public‑sector win can become a public‑performance dossier. Cost overruns, deployment delays, security incidents, or user dissatisfaction become Congress, auditor, and media matters rather than private customer feedback.

Security and outage track record

Oracle’s security and reliability record must be analysed with nuance. All hyperscalers and enterprise‑software vendors suffer vulnerabilities, outages, and customer‑impacting incidents. The question is not whether incidents occur but whether the company communicates clearly, remediates swiftly, and maintains trust in regulated environments.

Oracle’s public‑status model has a limitation that matters for intelligence work. Oracle documentation states that the OCI Status dashboard displays service‑level or region‑level outages, while customer‑specific outages are communicated via Console Announcements. This means the public status page may under‑represent incidents that affect specific customers, tenancies, identity paths, or configurations.

Unofficial outage monitoring illustrates the visibility gap. DataCenterDynamics reported in May 2025 that users reported an OCI outage in Europe, with reports suggesting an issue lasting roughly six hours affecting identity and including central Germany, while Oracle’s status page listed no incidents for that month at the time of writing. This is external reporting based partly on user reports and third‑party outage signals, not an official root‑cause analysis. It does not prove systemic unreliability, but it shows that public cloud‑status pages may not cleanly reflect customer experience.

Security reports are more concerning because Oracle’s enterprise products are deeply embedded. Reuters reported in April 2025 that Oracle had notified customers that a hacker had breached a system and stolen old customer login credentials, that the FBI and CrowdStrike were investigating, and that the stolen data included Oracle customer login credentials dating as recently as 2024, even though Oracle told customers the system had been unused for eight years. Reuters also reported that Oracle said the incident was separate from a healthcare‑sector customer incident. This is corroborated journalistic evidence based on customer communications and people close to the matter, not a full forensic report. It is nonetheless important because Oracle’s trust proposition rests heavily on the confidence of regulated and critical customers.

The broader risk is not that Oracle has particularly poor security. It is that Oracle’s footprint creates wide‑blast‑radius opportunities for attackers. E‑Business Suite, PeopleSoft, JD Edwards, Siebel, Oracle Database, WebLogic, Java, Cerner/Oracle Health, and OCI all sit inside sensitive enterprise workflows. The more Oracle markets itself as the secure home for public‑sector, healthcare, and AI workloads, the more security transparency becomes a competitive variable.

Competition: hyperscalers, data clouds, applications, and open source

Oracle competes with different vendors at different levels.

Against AWS, Azure, and Google Cloud, Oracle remains a challenger. Synergy Research Group estimated enterprise cloud‑infrastructure spending in Q1 2026 at roughly $129 billion, with AWS at 28 % global share, Microsoft at 21 %, and Google at 14 %. Synergy also noted that the top three are even more dominant in public cloud, while Oracle was among the fastest‑growing second‑tier providers. CRN’s summary of Synergy data placed Oracle at 4 % global cloud‑infrastructure market share in Q1 2026, up from 3 % in Q4 2025 and Q1 2025. That is the right scale of comparison: Oracle can grow quickly, but it remains much smaller than the big three in general cloud infrastructure.

Oracle’s wedge against the big three is not generic cloud breadth. AWS has developer‑ecosystem depth, Azure has enterprise Microsoft distribution and identity proximity, and Google has data/AI engineering credibility. Oracle’s wedge is narrower: database economics, bare metal, high‑performance networking, predictable egress, and multi‑cloud database placement. It is more credible for Oracle to win “run Oracle Database, Exadata‑like workloads, AI clusters, and regulated enterprise systems” than to become the default home for all new startups and cloud‑native development.

Snowflake competes with Oracle for analytical data gravity. Snowflake reported product revenue of $1.23 billion in Q4 FY2026, up 30 %, remaining performance obligations of $9.77 billion, a net revenue retention rate of 125 %, and 733 customers with trailing‑12‑month product revenue exceeding $1 million. Snowflake’s argument is not to replace all Oracle transactional databases. It is to become the governed analytical and AI data layer across clouds. This threatens Oracle when customers shift reporting, warehousing, data‑sharing, and AI workloads off Oracle databases and onto a neutral data cloud.

Databricks competes through the lakehouse and AI‑platform model. In February 2026, Databricks announced it had crossed an annualised revenue run rate of $5.4 billion, growing more than 65 % year‑on‑year, with more than 800 customers consuming at an annualised run rate above $1 million and more than 70 above $10 million. It also highlighted Lakebase, a serverless Postgres database for AI agents, and Genie, a conversational AI assistant. The strategic threat is not only analytics. Databricks is trying to pull enterprise data engineering, governance, AI development, and increasingly AI‑operational data services into a single platform.

SAP competes with Oracle at the application level and, through HANA, at the database/application‑platform level. SAP’s 2026 outlook foresees €25.8–26.2 billion of cloud revenue at constant currencies, up 23 %–25 %, and €36.3–36.8 billion of cloud and software revenue. Oracle Fusion ERP, HCM, and SCM compete directly with SAP’s cloud ERP migration cycle, while SAP’s grip on the ERP process layer can erode Oracle’s database leverage where customers standardise on S/4HANA and the SAP cloud stack.

Open‑source database ecosystems are the long‑term attrition threat. PostgreSQL, MySQL, MariaDB, SQLite, ClickHouse, Cassandra, and other systems do not need to displace Oracle’s largest legacy databases immediately. They only need to become the default choice for new workloads. PostgreSQL in particular has become the enterprise default for many new relational applications because it is capable, extensible, cloud‑managed by every major provider, and free of Oracle‑style licensing complexity. Oracle’s risk is not a sudden cliff. It is generational replacement: new applications start on Postgres or cloud‑native databases, analytics shifts to Snowflake or Databricks, and Oracle remains concentrated in high‑value legacy systems. That is still a large business, but it changes the growth maths.

Pricing power and its limits

Oracle has pricing power where three conditions come together: the workload is critical, the migration path is risky, and Oracle retains licence or support leverage. That describes much of the database installed base. It also describes some government and regulated workloads. It does not necessarily describe commoditised cloud compute.

In databases, Oracle can sustain pricing through support renewals, option licensing, audits, enterprise licence agreements, and cloud‑migration credits. The customer can negotiate hard, but the outside option is often expensive. In applications, pricing power depends on process lock‑in, depth of integration, and implementation history. In OCI, pricing power is weaker for generic compute and storage because AWS, Azure, and Google Cloud set the broader market expectations. Oracle’s cloud‑pricing pitch therefore emphasises predictability, lower egress fees, licence portability, and performance for Oracle workloads rather than generic premium pricing.

In AI capacity, pricing power depends on scarcity. When GPUs, power, and high‑density data‑centre capacity are scarce, Oracle can win attractive commitments from model developers. When supply loosens, when customers build their own chips, when training demand shifts toward inference optimisation, or when GPU generations change faster than depreciation schedules, pricing power can compress. That is the key economic difference between database rent and AI‑capacity rent. Database rent is protected by accumulated switching costs. GPU‑capacity rent is protected by scarcity, which can be cyclical.

Unofficial signals and trust

Corroborated public evidence: Oracle’s FY2026 results, the RPO disclosure, capex, operating cash flow, free cash flow, cloud revenue, and financing plans are official company disclosures and high‑confidence for the reported historical figures. Interpretation of future returns remains uncertain.

Corroborated technical evidence: the OCI regions documentation, service‑availability tables, multi‑cloud listings, AI‑infrastructure specifications, and public‑regions claims are official Oracle evidence. They are high‑confidence as descriptions of Oracle’s stated architecture and commercial offering, but not independent proof of customer satisfaction or delivered performance at every location.

Corroborated partner evidence: the statements from OpenAI and Crusoe about Stargate, Abilene, GB200 rack delivery, capacity targets, and site development are high‑confidence as statements of the involved parties. They do not constitute independent audit evidence of final delivered capacity, utilisation, or economics.

Medium‑confidence analyst signal: the Moody’s risk framing, as reported by Reuters, is a credible credit‑market signal. It does not prove that Oracle’s AI contracts will underperform, but it correctly identifies project finance, leverage, customer concentration, and the duration of negative free cash flow as central risks.

Medium‑confidence counterparty signal: the Reuters report on OpenAI’s projected cash burn, citing The Information, is useful but unaudited. It is relevant because Oracle’s AI backlog depends partly on the financial capacity and strategic consistency of a small number of AI buyers.

Medium‑confidence local‑infrastructure signal: the AP report on Abilene expansion and the power plant, and the Business Insider report on the property‑tax assessment and abatements, are credible journalistic indicators of local energy and incentive dynamics. They do not constitute complete project economics or legal findings.

Medium‑confidence customer/operator signal: UpperEdge’s commentary on Oracle and VMware licensing reflects practitioner experience in enterprise negotiations. It is not an official legal interpretation, but it is relevant because customer fear of licensing exposure is part of Oracle’s economic moat.

Medium‑confidence outage signal: the DataCenterDynamics report on an OCI outage in Europe relies in part on user reports and third‑party outage indicators. It is an external signal rather than a confirmed Oracle incident report, and it is useful primarily for assessing the gap between public status dashboards and customer‑perceived incidents.

Evidence register

Oracle FY2026 results: high‑confidence official evidence for revenue, cloud growth, RPOs, prepayments, capex pressure, operating cash flow, and free cash flow. Key caveat: management forecasts and AI‑market commentary are forward‑looking.
Oracle public‑sector price list: high‑confidence evidence for Oracle Database Enterprise Edition and option list prices. Caveat: list prices are not contractual realised prices for enterprises.
DB‑Engines ranking: medium‑confidence popularity signal for database mindshare. Caveat: not a revenue share, installed‑base share, or workload‑volume measure.
Oracle License Management Services: high‑confidence official evidence that Oracle maintains a formal compliance/audit apparatus. Caveat: the official framing emphasises customer assistance, not negotiation pressure.
UpperEdge licensing commentary: medium‑confidence practitioner evidence on customer pain around Oracle licensing and virtualisation. Caveat: vendor‑advisory perspective, not a court ruling.
OCI regions and availability‑domain documentation: high‑confidence evidence for the region/AD architecture and the single‑AD expansion model. Caveat: does not measure actual availability or capacity per region.
Oracle public cloud regions page: high‑confidence official evidence for commercial‑region count, backbone, egress allowance, compliance claims, and pricing posture. Caveat: official marketing page, not an independent performance benchmark.
OCI service‑availability and multi‑cloud tables: high‑confidence evidence for Oracle’s multi‑cloud database strategy and service listings. Caveat: availability does not prove adoption or usage.
Oracle AI‑infrastructure page: high‑confidence official evidence for stated GPU‑cluster scale and network claims. Caveat: technical claims must be validated workload‑by‑workload.
OpenAI July 2025 Stargate announcement: high‑confidence involved‑party evidence for the 4.5 GW Oracle partnership and early Abilene workloads. Caveat: not an audited delivery schedule.
OpenAI September 2025 Stargate expansion: high‑confidence involved‑party evidence for planned site expansion, projected 7 GW capacity, and capability of Oracle‑related sites. Caveat: planned capacity can change.
Crusoe Abilene announcement: high‑confidence partner evidence for energised buildings, GB200 rack delivery, and design intent for hundreds of thousands of GPUs. Caveat: partner has a business interest in the narrative.
Reuters on Moody’s Oracle AI‑contract risk: medium‑high‑confidence evidence of credit‑analyst concern about counterparty risk, leverage, and free cash flow. Caveat: analyst assessment, not an operational failure.
Reuters on OpenAI cash burn: medium‑confidence counterparty‑risk signal. Caveat: Reuters attributes the forecast to The Information and OpenAI did not comment in that report.
AP on Abilene expansion and power: medium‑high‑confidence evidence of power‑plant dynamics and site allocation. Caveat: site allocation can change as customers renegotiate capacity needs.
Business Insider on Abilene tax assessment and abatement: medium‑confidence evidence of local‑incentive economics. Caveat: not a full public‑finance audit.
Oracle U.S. Defense Cloud page: high‑confidence official evidence for DISA/FedRAMP/IL authorisation positioning. Caveat: accreditation does not equal workload performance.
GAO on VA EHR modernisation: high‑confidence government‑oversight evidence on Oracle Health/Cerner implementation risk. Caveat: programme risk is shared among the agency, integrators, vendor, and governance model.
Reuters on Oracle credential incident: medium‑high‑confidence security‑history evidence based on customer communications and people close to the matter. Caveat: not a full forensic report.
DataCenterDynamics on OCI Europe outage reports: medium‑confidence external outage signal. Caveat: relies in part on user reports and third‑party indicators.
Synergy/CRN cloud market share: medium‑high‑confidence market‑share context for hyperscaler competition and Oracle’s challenger status. Caveat: third‑party estimates, definitions vary by market segment.
Snowflake, Databricks, and SAP financial disclosures/announcements: high‑confidence current competitive‑scale indicators for data‑cloud, lakehouse/AI‑platform, and enterprise‑applications competition. Caveat: Snowflake and SAP are public‑company disclosures; Databricks is a private‑company self‑report.

Watchpoints over 12–36 months

First, track the conversion of AI RPO into recognised OCI revenue. The key question is not whether Oracle can announce a backlog, but whether it can energise sites, deploy clusters, meet service levels, and convert commitments into revenue without margin disappointment.

Second, track capex, net debt, and free cash flow together. A rising OCI revenue line with persistently negative free cash flow would imply Oracle is buying growth with capital intensity. A stabilisation of capex intensity relative to revenue would support the bullish case.

Third, track customer concentration in AI infrastructure. If OpenAI or a small group of AI companies accounts for a disproportionate share of the backlog, credit‑market scrutiny will remain justified.

Fourth, track power procurement and site execution. Relevant signals include interconnection queues, on‑site generation, gas‑turbine orders, transformer availability, local tax disputes, water/cooling constraints, and construction milestones at Abilene, Texas; Shackelford County, Texas; Doña Ana County, New Mexico; the Wisconsin/Midwest sites; and any additional Stargate locations.

Fifth, track whether prepaid or customer‑supplied GPU structures become more common. These structures reduce Oracle’s upfront financial burden but may also indicate that large AI buyers have enough leverage to shape Oracle’s economics.

Sixth, track OCI region maturity. More multi‑AD regions, clearer regional‑capacity disclosures, improved status transparency, and evidence of non‑Oracle workloads would support OCI’s claim to be a broader hyperscale challenger.

Seventh, track the adoption of Oracle Database@AWS, @Azure, and @Google. This is one of Oracle’s most important strategic moves because it allows Oracle to keep the database rent inside competing clouds.

Eighth, track database support and audit behaviour. If Oracle intensifies audits or uses licence pressure to push migration to OCI, short‑term revenue may benefit but customer resentment and open‑source migration incentives will rise.

Ninth, track displacement by PostgreSQL and open source in new workloads. Oracle’s legacy base is hard to move, but the default choices for new workloads determine the long‑term addressable market.

Tenth, track Snowflake and Databricks penetration in Oracle‑heavy accounts. The risk is not only database replacement; it is analytical data gravity moving away from Oracle systems‑of‑record.

Eleventh, track SAP’s cloud ERP migration. SAP’s success in moving ERP customers to S/4HANA Cloud can weaken Oracle’s application and database leverage in accounts that historically run SAP on Oracle databases.

Twelfth, track Oracle Health. VA deployment progress, user satisfaction, cost estimates, Congressional oversight, hospital references, and cybersecurity posture will determine whether Cerner becomes a regulated‑industry growth driver or a persistent drag.

Thirteenth, track security transparency. Oracle’s value proposition for governments and regulated industries depends on incident‑disclosure discipline, patch cadence, identity resilience, and customer trust.

Fourteenth, track gross‑margin composition. Database and support economics are structurally different from GPU‑capacity economics. If AI infrastructure becomes too large a share of growth, Oracle’s consolidated margin profile could look less like classic software and more like capital‑heavy infrastructure.

Fifteenth, track the debt‑market reaction. Signals from Moody’s and other credit markets could become leading indicators of Oracle’s ability to absorb AI‑infrastructure risk without raising its cost of capital.

Sixteenth, track whether Oracle’s AI‑infrastructure customers build in‑house chips or diversify their cloud providers. Customer vertical integration can turn today’s scarcity premium into tomorrow’s pricing pressure.

Seventeenth, track regulatory and sovereignty demand. Oracle’s positioning in government, sovereign, and dedicated‑cloud markets is a differentiated asset if data‑residency and national‑security requirements tighten.

Eighteenth, track public‑sector wins and delivery outcomes. New contracts help Oracle’s top line, but implementation performance determines whether public‑sector exposure builds trust or creates political risk.