One company built a business on being first to ship it

The paper and the gap

In 1970, Edgar F. Codd published "A Relational Model of Data for Large Shared Data Banks" while working at IBM's San Jose research laboratory. The paper was precise, mathematical, and immediately consequential — it described how data could be organised into relations, queried without knowing the physical storage layout, and manipulated through a formal calculus. IBM's own researchers understood it. What IBM's product divisions did not do, for reasons that remain a case study in institutional caution, was ship a commercial relational database on any competitive schedule.

That gap was the founding condition of Oracle Corporation. Larry Ellison and his co-founders read Codd's work, along with IBM's own published research on what would become SQL, and made a decision that would define enterprise software for decades: they would build a commercial relational database before IBM did. Oracle's first commercial release shipped in 1979, technically ahead of IBM's own DB2, which did not reach general availability until 1983. The four-year lead was not a coincidence of engineering — it was a deliberate race against a competitor that had invented the category and then hesitated to exploit it.

The product had rough edges. Early versions of Oracle made claims about SQL compliance that outran the implementation, and the company's sales culture was aggressive in ways that became legendary within the industry. None of that slowed the market adoption, because the alternative — hierarchical and network databases that required programmers to navigate physical data structures explicitly — was genuinely worse for the kinds of applications businesses wanted to build.

How the lead became a moat

Being first mattered less than what being first made possible: pricing power, customer entrenchment, and a decade of operational data about how enterprises actually used relational databases at scale. Oracle translated all three into a business model that has outlasted every subsequent threat to replace it.

The pricing structure Oracle developed reflected the leverage of a near-monopoly on credible enterprise relational technology. Licences were sized by processor count, then by core count as hardware evolved, with multipliers that varied by processor type — a structure opaque enough that most customers could not easily audit their own exposure. Maintenance contracts, priced as a percentage of licence value, ran at rates that made the initial licence look modest by comparison. A customer who had built ten years of application logic against Oracle's specific dialect of SQL, its proprietary extensions, and its particular approach to stored procedures was not in a position to renegotiate aggressively. The relational model gave the category its technical foundation; Oracle gave that foundation a commercial architecture designed to be difficult to leave.

The real lock-in was not contractual — it was structural. Oracle's PL/SQL, its proprietary procedural extension to standard SQL, accumulated inside enterprise applications the way sediment accumulates: invisibly, over years, until the layer was thick enough to be load-bearing. Sequences, database links, materialized views implemented in Oracle-specific syntax, partitioning features licensed separately — each was a reasonable choice at the time of implementation and a switching cost thereafter. Data migration off an Oracle estate is rarely a database migration in any simple sense; it is an archaeology project conducted under time pressure.

SAP's commercial rise complicated Oracle's position without resolving it. SAP built its ERP products through the 1980s and 1990s on top of relational databases, including Oracle, which created a peculiar dependency: SAP customers were often Oracle customers by requirement, not by preference. The relationship between the two companies oscillated between partnership and competition for years, particularly after Oracle moved into the applications market through acquisitions — PeopleSoft in 2005, Siebel in 2006, BEA Systems in 2008 — that transformed it from a database vendor into an enterprise software stack competing directly with the companies that ran on its own database engine.

The documented costs

The FoxMeyer bankruptcy in 1996 is the most cited catastrophe in ERP implementation history, but Oracle's name runs through a different register of documented failures — not collapses, but quietly enormous cost overruns in migrations, audits, and licence compliance actions. Oracle's Global License Management Services division conducted compliance audits that became a recognised feature of the customer relationship: an audit triggered, typically, by a corporate acquisition, a hardware refresh, or a contract renewal negotiation, and concluded with an unplanned licensing bill. The practice was legal, disclosed in contract terms, and by all available reporting, highly effective at revenue generation.

The public sector record is instructive. Across multiple jurisdictions, government agencies negotiating Oracle licences without specialist advice consistently paid more than comparable private-sector organisations. The UK government's Crown Commercial Service eventually produced guidance specifically addressing Oracle licence risk after a series of expensive compliance findings. The pattern — a technically complex pricing model, an information asymmetry between vendor and customer, and a negotiating dynamic shaped by the customer's fear of audit — was consistent enough to constitute a business strategy rather than an incidental outcome.

Workday, which launched in 2005 targeting Oracle's and SAP's human capital management customers with a SaaS delivery model, represented a structural rather than merely competitive threat: if the application ran in the vendor's cloud on the vendor's infrastructure, the customer's Oracle database footprint shrank. Salesforce had made the same argument for CRM since 1999. Both companies grew substantially at the margins of Oracle's installed base without, for many years, displacing its core. The core — financial systems of record, general ledger, subledger accounting — remained on-premise and on Oracle long after the adjacent applications had migrated elsewhere.

What Oracle understood, and sustained through forty years of product strategy, is that the month-end close is not a workload you experiment with. Finance directors who had closed the books on Oracle for a decade were not going to schedule a database migration for a quarter when the audit was also due. The political economy of enterprise IT rewarded stability and penalised the person whose name was on the change request when something went wrong. Oracle's entrenchment was partly technical, partly contractual, and partly a function of how organisations assign blame.

The relational model was published by a researcher at IBM who received no material benefit from the commercial systems built on his work. Codd's 1970 paper described a mathematical structure; Oracle turned that structure into a revenue stream that has compounded for more than four decades. The distance between those two facts is where the enterprise software industry lives.