Case

When Databases Were a Hot Technology: The Rise of Oracle

The first Oracle logo, after the company was renamed from Relational Software, Inc.

On September 10, 2025, Larry Ellison became the richest person in the world, if only for a brief period. His wealth surged after Oracle, the business software company he founded in 1977, reported strong quarterly results that exceeded expectations. Oracle’s shares increased by more than 36% on that day, a spike that saw Ellison’s fortune swell by US$101B. It was, at the time, the largest single-day increase ever recorded.

Ellison was 81 years old. The bulk of his fortune remains tied up in Oracle, whose core database business was pivotal to its rise decades ago.

So, who is Larry Ellison? He was far less famous or talked about than Elon Musk, Mark Zuckerberg and Jeff Bezos when he dethroned Musk to become the richest person in the world.

Compared to chips, machine language and the latest Instagram filter, databases are a boring and obscure piece of technology. They certainly don’t dominate tech discourse. How did a database company make Ellison the richest person in the world?

Larry Ellison: Unlikely Founder

The linear path of ‘founder seeks an idea; founder lists a number of possibilities and does some market research; founder picks the best idea from that list and pursues it; the idea works and said founder builds an amazing business’ is pretty rare.

Ellison was 34 years old when he started Oracle. He took a circuitous path to business.

Ellison was born to his mother out of wedlock. He never met his biological father. His mother gave him up for adoption to her relatives when he was nine months old. He didn’t learn that he was adopted until he was 12 years old. And that his adoptive mother was his aunt.

He grew up in Chicago, in a working-class family of Jewish immigrants. Money was scarce. So was love and validation from his adoptive father, who never missed a chance to tell little Larry he was good for nothing. However, Ellison had a warm and loving relationship with his adoptive mother.

As a boy, Ellison showed a rebellious streak, even from his earliest years. He had little patience for authority or convention. He got into trouble with the Boy Scouts and with athletic teams, quit religion and, at age 13, refused to have a bar mitzvah.

He enrolled at the University of Illinois at Urbana-Champaign as a pre-med student and was quickly named the science student of the year. Initially, Ellison’s grades looked promising. But then his adoptive mother died, and he abruptly quit. Ellison was 20 years old.

He then attended the University of Chicago, where he studied physics and mathematics. He also had to learn basic programming as part of the physics curriculum. He enjoyed both physics and programming and learned how to program the latest IBM mainframe computer. Logic appealed to him. But again, Ellison was restless; he quit university after only one term. It was 1966. Ellison was 22 years old.

He may not have earned his degree, but the programming skills he acquired landed him a job as a contract programmer at Argonne National Laboratory in Illinois. He was good at his job. He was a fast worker and computer programming made a lot of money, which he used to his advantage by working only a few days a week. Working as a programmer also aligned with Ellison’s temperament: a non-conformist. He didn’t have to abide by what he believed were ‘absurd conventions’.

In the 2003 book Softwar: An Intimate Portrait of Larry Ellison and Oracle, Ellison tells author Matthew Symonds,

‘People—teachers, coaches, bosses—want you to conform to some standard of behavior they deem correct. They measure and reward you on how well you conform—arrive on time, dress appropriately, exhibit a properly deferential attitude—as opposed to how well you do your job. Programming liberated me from all that. I could work in the middle of the night. I could wear blue jeans and a T-shirt. I could ride my motorcycle to work. And I’d make more money if I could solve the problem faster and better than anyone else.’

It was the summer of 1966, and Ellison decided to head for Berkeley, California. Silicon Valley, as we now know it, was still in its early days. The software industry was primarily driven by government-funded defence and aerospace contracts, and programming as a discipline was still taking shape. But there were opportunities aplenty for a programmer as competent as Ellison.

But was he trying to build a career? No.

By his own admission,

‘Basically, programming gave me the freedom to screw around through my twenties. All I knew I was capable of was short bursts of energy. So I found jobs working on weekends as an IBM systems programmer. I would help run these huge data centers and fix the operating system on big IBM mainframes. Most people didn’t want to work weekends, so I had no trouble getting these jobs. Monday through Friday, I’d be hiking or rock climbing in Yosemite, kayaking down the Stanislaus or American River, or on a long bike trip down the California coast. I was in my twenties and having fun’.

On the work front, fun looked like drifting between companies.

During the early 1970s, he joined Amdahl, a company that would go on to become a competitor to IBM in mainframe computers. Ellison worked as a programmer at Amdahl. But he was laid off in 1973.

He then joined Ampex, the company that had invented the magnetic tape recorder. Ampex was then working on a technology to significantly increase the amount of information computer databases could store. The Ampex terabit memory system project was funded by the CIA and code-named Oracle.

In 1976, Ellison moved to Precision Instruments (soon to be renamed Omex), which, like Ampex, was working on mass computer storage systems. Here, for the first time, Ellison had a title. He was made the vice president of R&D.

This hardly reads like the origin story of someone who would eventually become a titan of the tech industry. But then Larry Ellison was smart and restless, and he hadn’t yet found a problem that could hold his attention.

He wondered if he could run a company. He wasn’t fired up by great ambition or a grand vision, but felt that owning a company would simply allow him to go on with his life with more control and with greater potential rewards.

A small consulting company perhaps, he thought.

Why a consulting company? Ellison reasoned that consulting would allow him to work on a lot of interesting projects and earn more money. He just needed to find projects that were ‘hard’ enough for him but harder for others. In his words,

‘The ideal ‘hard’ job is one that is generally perceived as being difficult but can quickly succumb to a bit of cleverness. All we needed were a few really smart people who could do these so-called hard jobs quickly, and we would make a lot of money while not working all that hard. That had been my favorite approach to work from the beginning’.

His job at Omex provided the opportunity. Omex was preparing to invite bids for writing the software for its mass storage system. Ellison told his boss that he knew two exceptional programmers and asked if they could put together a bid. He had Oates and Miner, his colleagues at Ampex, in mind. His boss didn’t mind because that would save Omex time and money.

Bob Miner, a software engineer, and Ed Oates were Ellison’s supervisors at Ampex. The three of them formed a company – Software Development Laboratories (SDL), in 1977. This was the company that would later become Oracle.

Ellison became the president of SDL.

SDL put in a bid of US$400,000, which was a third of the price quoted by the next lowest bidder. Not surprisingly, they won the contract from Omex.

Ellison stayed with Omex to design and supervise the project while Miner and Oates got down to writing the code with the help of a brilliant young programmer named Bruce Scott.

Miner did not just write code. He brought to the table deep systems experience, gleaned from working on storage and database projects at Ampex. While Ellison was the visionary and market reader, Miner was the engineer who turned those ideas into tangible products.

Oates, the other co-founder and partner-in-crime, was equally willing to work from first principles and experiment. Together with Ellison and Miner, he rounded out the very small core team of SDL.

SDL was Ellison’s brainchild, and till then, he had done most of the legwork. He felt a strong sense of ownership with the tiny company. So, when it came to negotiating SDL’s ownership, he backtracked from his earlier proposal of an even three-way split and demanded a 60/20/20 split. According to the terms of the new proposal, Ellison would own 60% of the company. Miner and Oates got 20% each and could earn more stock through performance.

Although he was now running a consulting agency, as he had once wished to, Ellison was already doubting if it ever had been a good idea. As he said to his biographer Symonds:

‘I wanted to get out of the consulting business. Consulting proved to be much more work than I ever imagined. My ‘hard problems, cleverly solved’ business model did not scale up beyond a few people, proving I was not nearly as clever as I thought. I was working eighty hours a week—at least. We were making a lot of money, but we were working insanely long hours’.

Ellison, Miner and Oates decided to close up shop and venture into product. A software product provided the maximum leverage – build a product, sit back and sell it over and over again.

They just needed to figure out what to build.

Database technology, before Oracle

A database is simply a collection of stored data that computer applications can access and manage. The software that protects it and manages it is called a ‘database management system’.

In the 1970s, computers were downright expensive and ridiculously unwieldy. A large computer was the size of several refrigerators! It was no wonder that only governments and businesses used them. A typical business would pay US$200,000 to US$1M for a computer system, and then hire a few programmers to write, say, payroll software — software that was built custom for the business.

If you ran a company, payroll software meant that you had to store information about your employees. It is highly likely that you would store this information in a database management system — one that you would have to purchase from an external vendor. You also would also need your payroll system to be able to organise, manage and access employee information in a handy way to carry out functions like calculating paychecks and producing tax reports.

Why purchase a database as a separate piece of software? Then, as now, database management systems were built with safety features in mind. For instance, databases were supposed to guard against multiple updates to the same record (for instance, if two users attempt to update the same employee’s information at the same time). They were also supposed to protect data from corruption — say from a power outage, or a corrupted disk. For these reasons and others databases were regarded as specialised software, worthy of purchase.

With this functionality in mind, multiple companies started building their own databases to sell to other businesses. At the time, software packages were written for specific machines. A database written for an IBM mainframe would not work on a different company’s mainframes (or even on a different ‘family’ within IBM’s portfolio of computers). One consequence of this technology was that — once businesses built their payroll systems or internal line-of-business software on top of a given database — switching was extremely difficult. This ‘lock-in’ effect extended to both the database software as well as the computer it was running on.

In the 1970s, databases were still quite rudimentary. They stored bits of data linked to each other in a specific hierarchy. For instance, most employee information would be part of a department record. So, if somebody wanted to generate a paycheck for Bob in the Finance department, the software had to first find the records for all departments, sift through that list to find the Finance department, then list all the employees within that department, run through that list to find Bob’s employee record, look up their paycheck history, check the current pay period’s timesheet, then extract the tax and benefits records applicable to Bob, and finally, calculate gross pay, deductions and net pay.

Databases that used this approach were called ‘hierarchical databases’, and using them was like pulling teeth. A programmer had to ‘navigate’ from one set of records to other connected records, and keep navigating until they landed on the record they were searching for.

One standard for interacting with these early databases was a ‘data model’ called CODASYL. It included a basic command language to interact with database systems. It was meant to be the industry standard except for the inconvenient fact that it was used by everyone … except IBM.

Unfortunately, IBM machines made up the bulk of the computer market at that time.

At that time, companies that made databases included IBM with its own product, IMS — a hierarchical but not CODASYL database — and Cullinet Corporation — who did provide a CODASYL-compatible database for IBM users. As mentioned previously, both these products were ‘navigational’ databases.

Other companies that came out with their own CODASYL-based products were Eckert-Mauchly Computer Corporation (the maker of Univac), Honeywell Incorporated and Siemens AG for mainframe computers, and Digital Equipment Corporation (DEC) and Prime Computer Corporation for minicomputers.

A mainframe computer, the dominant form of computer from the post-World War II period through to the 1970s, was roughly the size of a standard room. A typical mainframe setup cost millions of dollars. Minicomputers emerged in the 1970s. These were smaller – about the size of a large refrigerator – as well as cheaper, costing anything between tens of thousands and hundreds of thousands of dollars.

While working at Ampex, Ellison had written a database management system for the PDP-11 minicomputer. The PDP-11, developed by DEC, was the most successful minicomputer of its era. In Softwar, he is candid and admits that the system was essentially a ripoff of Cullinet’s successful IDMS mainframe database.

Ellison wondered: if SDL produced a novel database software application for minicomputers, they could perhaps enter the product business.

Minicomputers were already triggering a surge in computer purchases. By the middle of the 1970s, both large and mid-sized corporations were demanding minicomputers that provided computing power without mainframe-scale cost and complexities. Minicomputers were also the arena where, compared to mainframes, IBM had less dominance.

But what innovative database product could SDL come up with?

As the database war was raging, in 1970, an IBM researcher, Edgar F. Codd, published his seminal paper ‘A Relational Model of Data for Large Shared Data Banks’ that introduced the ‘relational model’ of data as a way to organise and access a database. Ellison had some familiarity with the idea; he had stumbled onto it during one of his early meetings with the CIA, a client, whilst he was at Ampex.

In the relational model, data is stored as linked two-dimensional tables with rows and columns, like an Excel spreadsheet. However, unlike Excel, each table in the relational database has a specified set of named columns. The name of each column is unique for a particular table, though not necessarily across tables. Each entry in a particular column is of the same data type (for instance — a column titled “Salary” can only consist of numbers).

Unlike the hierarchical model, the relationships between the separate tables in the relational system are not wired up in a tree-like structure. A programmer does not need to navigate to the right record. It is possible to locate information by writing queries, such as “give me all the records where ‘Salary’ is more than 100,000”.

Even better, programmers working with relational databases do not need to understand how the stored data is represented in order to retrieve it. That made the relational model more flexible and accessible to non-programmer users than if they were to use the hierarchical databases. In a relational database, users just had to ask for data by describing what they wanted, instead of navigating a fixed path through the data.

To put it mildly, the relational model was a game changer. Unfortunately, Ellison found Codd’s papers too theoretical to be used as a basis for a product.

Four years later, IBM published a series of research papers by Don Chamberlain about a prototype relational database called System R, complete with System R’s Structured Query Language, or SQL. SQL’s appeal was that it was the only language someone needed to learn to work with relational databases.

Now this was promising. System R may have only been a prototype, but it demonstrated to Ellison that a relational database was possible to build.

According to Ellison,

‘Bob thought that the relational database strategy was risky, but he left the final decision up to me. I thought that relational was clearly the way to go. It was very cool technology’.

Most industry pundits believed that relational databases couldn’t run fast enough to be commercially viable. Indeed, System R was but a toy. It was nowhere near ready for production. As for IBM, they did the foundational research, backed their claims and built a prototype, but then didn’t ship a product. They had a reason to hold their horses.

IBM already had their own database line, the hierarchical system IMS, and it was raking in substantial profits. So they weren’t about to let loose the relational database and cannibalise their own revenue. As IBM dithered, Oracle saw an opportunity.

Ellison and his team decided to use IBM’s work as an architectural blueprint to build their own database product. They didn’t invent the relational data model, but they wanted to be the first company to commercialise the idea.

However, Miner was right: this was a risky bet. The relational database model was very much unproven. Nobody knew if it could even become commercially viable technology. But for Ellison, the greater the perceived risk, the fewer the risk-takers. In fact, no one was even trying to come up with a commercial relational product. The only noteworthy work that was happening was pure research projects that were definitely not gunning to achieve peak performance and reliability.

The other risk was if better-funded vendors entered the fray and competition suddenly heated up. Then Ellison and SDL would surely lose. It was then evident that SDL could only win, and win big, if they developed a reliable product and marketed the technology before anyone else.

Finally, Ellison decided that their relational database would target minicomputers. He reasoned that even if IBM shipped a relational product, it would most likely be for their own mainframes.

Ellison wanted to avoid taking IBM head-on. (In reality, as a startup, SDL simply couldn’t afford to do so.) With luck, Ellison hoped, SDL would have the entire minicomputer market to themselves.

A startup trying to get a foothold

The team at SDL got down to building a relational database for minicomputers.

The money that they received from Omex paid for SDL to create a prototype of what would go on to become the Oracle database. The prototype was, technically, a failure, but SDL was still gaining value by developing intellectual property. In doing so, it was shifting their business model, from being a consulting firm to becoming a software company. In that era dominated by hardware-plus-code firms, SDL, a company that sold software as its main product, was an outlier.

In 1979, SDL changed its name to Relational Software, Inc. (RSI) and moved to 3000 Sand Hill Road. This new location, near Palo Alto, was an area that housed several prominent venture capital firms. RSI’s first customer was the CIA.

The CIA had been interested in the relational model since Codd first published his paper and had keenly tracked the work being done by IBM’s System R research group. The intelligence agency did not miss the implications of and therefore the potential of the new technology.

Sadly, IBM was not interested in developing System R further. So, the CIA had to find somebody who could build a commercial product. It entrusted Dave Roberts with the task of finding a vendor.

Roberts zeroed in on RSI. He had two reasons for choosing the tiny firm. He learned that Bob Miner, whom he had earlier worked with on Ampex’s terabit memory project, was a part of RSI. Roberts was also impressed that RSI had committed to SQL, an IBM creation. To his mind, these two things made RSI immensely credible.

What also got the CIA hooked was the fact that RSI designed its database to run on DEC’s PDP-11 minicomputers. These minicomputers were used extensively in government, especially within the intelligence community, because the machines were small enough to fit into aeroplanes and submarines.

RSI started working for the CIA. The money that came from the CIA allowed RSI to focus on completing the first commercial version of the Oracle database instead of having to chase venture capital, which was hard to come by anyway.

Ellison recalls the sheer thrill he experienced when they realised that their product actually worked. He likens his emotions to the excitement the Wright brothers must have felt when their plane took off from the ground.

Ellison named their product Oracle Version 2. He reckoned that no one, not even the government, would want to buy Version 1 of an entirely new kind of database from five unknown guys in California. Version 2 sounded like it was a product that has been tested and all its issues fixed.

Moving from a prototype to a usable product was a slog. Despite the rechristening, Oracle Version 2 was still plagued by serious performance issues that sceptics had predicted. The engineers plodded along; they rewrote the code, fixed bugs and tweaked performance issues until, finally, they had a breakthrough. In the final performance test, it ran faster than the CODASYL system, which was, at that time, the fastest PDP-11 database. Oracle Version 2 also delivered ten times the performance improvement it needed to be commercially viable.

Ellison tells Symonds how excited he was:

‘On my way out that evening I ran into Tony Spoor, our auditor, in the elevator lobby. I was a bit light-headed and euphoric, still trying to fully grasp the import of our performance test results. I spontaneously decided to explain what it all meant. After laboriously rattling off the details of our performance test results, I said ‘Tony, do you know what this means? Do you? Do you know what this means?’ He said, ‘Ugh . . . no.’ I said that it means Oracle’s worth at least $100 million’.

Ed Oates, Bruce Scott, Bob Miner and Larry Ellison celebrate Oracle’s first anniversary in 1978. (Source)

Hustling, and yet struggling

Not many people other than Larry Ellison could perceive Oracle’s worth.

Larry Ellison remembers,

‘When Oracle was formed in 1977, venture capitalists wouldn’t spend a dime investing in software [...] in fact, I can recall talking to a couple of venture capitalists and, in fact, I can recall not talking to a couple of venture capitalists — I was left waiting in their anterooms. When they heard the investment was about software, they wouldn’t even see me.
In fact, their receptionist would search my briefcase before I left to make sure I didn’t take a current copy of Business Week with me as I left the room. Oracle started without a dime of venture capital. I put in $1,200 and the other two guys put in $400 each, and with that $2,000 we started Oracle’.

Oracle had no choice but to rely on sales revenue to keep operations going. Sales was hard because customers were very sceptical. After all, it was Oracle’s first commercial database product and the earliest database product to use the relational model and SQL. This made adoption trebly difficult: first, customers might not have heard of the relational model. If they had heard of it, they likely did not believe that it worked. Finally, even if they were convinced that it worked, they would have to learn a completely new language to interact with the database.

The only way to convince people that it worked, though not perfectly, was to demonstrate the database system to anyone who could envision a use for it.

Ellison, always in the thick of things, took to the road to sell. He would make a presentation at one agency on Monday, which would bring in a phone call on Tuesday to schedule a demo at another agency on Wednesday. One week, he flew to and from Washington, D.C. three times.

Oracle’s hot new database was getting talked about within the intelligence community. In just a little over six months, RSI signed deals with the CIA, Navy Intelligence, Air Force Intelligence and the NSA (National Security Agency).

But reality is always messier than what outsiders perceive or can fathom. None of this early traction brought in financial security. The client roster looked impressive while the company coffers were running dry.

Two factors converged to cause RSI’s financial crisis. Ellison and his team decided to stop doing consulting work once RSI started making database sales to government agencies. They needed all hands on deck to work on finishing the product.

They had only US$235,000 in the bank, which was not adequate even in those days. Their meagre bank balance would not have been a problem if the money from the government was flowing in. But Ellison had not anticipated just how long it took from the moment the government said they were going to buy to the moment they actually paid out the money. This was a lesson RSI learnt the hard way.

What Ellison and his team learnt was this: when the US Government buys anything, they have to go through a congressionally mandated process, which includes publishing the pending purchase in the Commerce Business Daily to invite competitive bids or to allow other entities to protest the purchase. So, a typical government vendor would only be paid six to nine months after they closed the deal.

Just when it looked like RSI was taking flight, it came perilously close to running out of cash. But the team found a solution to their money woes: stop paying the salaries of some people, starting with Larry Ellison.

Improvising with portability

Larry Ellison once met a Japanese executive who described their creed about competition and market share: Anything less than 100% was not enough. Ellison was inspired by the business philosophy and wanted RSI to reach a broader customer base. For this, Oracle had to be able to run on just about any computer that RSI’s potential customers might own. A majority of these businesses operated a heterogeneous mix of machines but wanted to run only one database.

The Oracle database needed to be portable.

So, Ellison had the database rewritten in C.

The C programming language had been created in the early 70s, and was built around a novel idea. Conceptually, it was simple: you would write your program in one programming language (C) and then use a compiler to translate your C program into machine code that could be executed on different computer architectures. In this manner you would only have to write your program once, and would magically be able to run your program on as many different computers as possible. If Oracle rewrote their database in C, they would — in theory — be limited only by the number of C compilers available for different computers.

This was a mammoth task. The rewrite would take years. The money for the rewrite came from a loan arranged and guaranteed by Don Lucas, a prominent venture capitalist in Silicon Valley. It is worth noting that earlier, Ellison and Miner had refused Lucas’s offer of equity investment. They chose to utilise debt instead of giving up equity. It was a gamble because at that time the C programming language was only a few years old; it had never been used to write something so complex. The rest of the industry could not even spell C!

At that time, DEC’s VAX, which debuted in 1977, was the most powerful minicomputer on the market. It was basically the PDP-11 on steroids. All of RSI’s intelligence agency clients were buying them up as quickly as DEC could make them. The VAX machine also appealed to RSI’s corporate customers. They agreed that these machines were capable and reliable enough to take over — at a departmental level — several tasks that had, up to that point,only been done on mainframes.

It’s worth taking a step back to admire Ellison’s decision. The simpler option would have been to rewrite Oracle’s existing version 2 product (which could only run on the PDP-11) for the VAX. This was what Miner wanted. However, Bruce Scott, their first hired engineer, pushed aggressively for the C rewrite, since they could recompile the database for any new architecture in the future. But this meant giving up on new feature development for the entire duration of the rewrite. Ellison backed Scott, and RSI buckled down for a rough development process.

Version 3 of Oracle’s database, rewritten in C, was finally released in 1983, about five years after the rewrite started. This version was able to run on the VAX. This ensured that it would run on the minicomputer that would dominate market share over the next decade. By 1984, more than 70% of RSI’s income from software licensing came from DEC’s machines and the lion’s share of it from their VAX machines.

Making the Oracle database portable made it durable and (almost) ubiquitous. Even today, Oracle is the only database that can run on all the main operating systems in corporate environments, from Microsoft's Windows to all the different versions of UNIX to open-source Linux and MVS (Multiple Virtual Storage) on legacy mainframes.

This was a signature Larry Ellison move – audacious and dismissive of conventional wisdom. But it was not reckless.

Ellison told Symonds, ‘... I only ever picked the high-risk approach when I thought that it would increase our chance of winning and our share of reward’.

The portability decision put Oracle in good stead. For the next decade, it could focus on developing ever more advanced features, whilst never worrying again about portability — for instance, whenever a new class of computer architecture emerged.

Turning an idea into a scalable and sustainable company

By the time Oracle Version 3 was shipped in 1983, RSI had renamed itself Oracle Systems (later, Oracle Corporation) to align with their flagship product. It also moved to an 84,000-square-foot office in Belmont, California. Outwardly, it looked like they had finally arrived, but the prevailing opinion about their product still remained sceptical.

The majority of corporate customers still saw the relational model as nothing more than a toy. Is it useful, the technical press wondered. IBM doubted if relational databases could ever process transactions. These doubts persisted despite Ellison passionately making a case for the product. He had to fight for 10 years to get people to believe in his conviction.

Selling Oracle’s database almost required missionary work. Ellison was the chief evangelist, but it needed more than him and Bob Preger, their first salesman, to convince customers. Oracle needed to become a sales organisation.

Don Lucas’s friend, who had a background in sales, had once told Ellison:

‘If you have a good product, the more salespeople you have, the more you’ll sell. If you want to sell twice as much, get twice as many salespeople’.

The Oracle database, now newly portable, was a good product. Or at least Ellison thought so. So he hired more salespeople.

Over the next few years Ellison built a formidable sales force that included, among others, the computer scientists who had written theses on the relational model. The job of Ellison’s sales representatives was to schedule a meeting with prospects where the reps could come onto the customer’s premises.

Once the sales reps arrived at the prospect’s offices, they would explain the Oracle database, ask the prospects how they wanted to use the system and then build it in front of them, right then and there.

Slowly, sales began to grow. Expanding overseas was the next — logical — move, but Oracle was cash strapped. They decided to expand with minimal capital outlay.

Oracle began to sign deals with local distributors instead of opening owned offices. There were two sales management teams: Tom Peddersen Associates in continental Europe and, in England, the U.K. branch of CACI, a renowned systems integrator and consultancy firm. Oracle later bought out its distributors when the business had proven to be successful.

Oracle’s sales culture overseas differed distinctly from what was practised in the U.S. The European team’s strategy was to earn business on a regular basis by nurturing long-term relationships with customers. This was the ‘farming’ strategy. By contrast, their U.S. sales team followed a ‘hunting’ strategy. They tried to sell the most they could to one customer, close the deal and move on to ‘hunt’ the next customer.

For a considerable stretch of time, Oracle’s overseas sales grew faster than in the U.S. Over time, Ellison realised that the U.S. sales strategy was unsustainable. However, it would take another decade for the U.S. sales team to stop being hunters and start behaving like farmers.

A crowded battlefield, but now mostly empty

Oracle’s rise was anything but inevitable.

The database market of the 1970s and 1980s was crowded.

There was the Boston-based Cullinet, with a market value of around US$100M. In Ellison’s words:

‘Cullinet was our role model. We never thought we could get as big as they were because they had an expensive mainframe product and we were focused on these cheap little minicomputers’.

And then legendary computer scientist and database researcher Mike Stonebraker launched Ingres — a former research project patterned after System R — as a commercial offering in 1981. Even though Ingres came to the market after Oracle, it was already growing faster than Oracle. In 1984, while Oracle had doubled its sales to US$12.7M, Ingres had tripled theirs to US$9M. Oracle had just rewritten their database and was facing quality issues, so Ingres caught on fast.

In 1985, IBM released DB2, a relational database for mainframes. It, however, never dominated the market Oracle operated in, choosing instead to focus on relational products for mainframes. Ellison got this right, at least.

Two newer rivals, Informix and Sybase, posed varying degrees of threat to Oracle’s fast-growing business.

Informix operated in the nascent UNIX market. However, at that time, UNIX was more used in universities than in corporate computing environments, so Informix never became a serious challenger.

Sybase, on the other hand, rose from relative obscurity to become a dangerous competitor. It had built the first database specifically designed for client/server computing. Their architecture fit right into how companies were deploying business software: the application ran on user machines while the database handled shared data on a server.

Oracle’s Version 5 supported the client/server paradigm, and 5.1 incorporated a feature that enabled distributed queries – the client sends one query, and the database server can fetch data from multiple locations. The feature is a natural fit with client/server systems. However, Sybase had a first mover advantage; their purpose-built client/server design was a competitive wedge that took market share away from Oracle.

Sybase also had a number of technical innovations that stole Oracle’s thunder. For instance, the Sybase database was a programmable database server. Users could write programs, called stored procedures, that ran inside the database itself. For instance, instead of your payroll software sending dozens of SQL commands to calculate Bob’s pay, it could call one stored procedure that would run all the calculations within the database itself.

Sybase’s server possessed two additional features – referential integrity and two-phase commit.

Referential integrity meant that the database system itself prevented broken links between related records. For instance, if Bob’s record points to the Finance department, Sybase’s server will stop someone from deleting the Finance department record.

On the other hand, the two-phase commit feature ensures that a transaction succeeds and gets reflected across multiple databases. For instance, if one database records Bob’s salary being deducted and another records the money being transferred to his bank account, a two-phase commit can ensure both transactions taking place together, or neither at all.

These technological advantages, which Oracle’s databases lacked at that time, made Sybase attractive to businesses that were building complex client-server applications. These businesses switched to Sybase, and never switched back.

If this landscape feels familiar, it’s because it is. To an outsider looking at the database ecosystem of the time, there were multiple credible contenders, genuine technical trade-offs between the products and absolutely no way to foretell which combination of standards, timing and execution would decide the winner. This is simply what it looks like on the inside of a technological gold rush.

Indeed, there was no conceivable reason to bet on Oracle over Cullinet, Ingres or Sybase because nobody could foresee how events might unfold for each of the challengers.

Cullinet was the first software company to be listed on the New York Stock Exchange. It was the first to reach US$100M in revenues. But they remained tethered to their platform built around the CODASYL model. With relational databases becoming the dominant standard, Oracle overtook Cullinet in the mid-1980s.

Ingres was a serious technical rival. The sheer engineering and programming talent at Ingres, recruited from Stonebraker’s students and research lab in UC Berkeley, prompted Ellison to scout for brains from CalTech, MIT and Stanford. He hired a superb team from Xerox PARC, and on this team was Derry Kabcenell, a software engineer whose recruitment would prove to be pivotal to Oracle’s fortunes.

Oracle’s aggressive hiring of top talent ensured the databases kept improving. Kabcenell fixed the quality issues plaguing Version 3 and, a year later in 1984, delivered Version 4 packed with a new read consistency feature.

Read consistency meant that when a query was in process, the database saw only a single, stable snapshot of the data. The query executes as if no other data was changing at that exact moment, even though other transactions may be actively reading or writing to the same database. For instance, read consistency ensures that employees being added to an HR database whilst a query is in progress will not be counted twice, once in the old scan and then once again with the addition.

It was yet another shot across the bow in the back-and-forth of new database features.

In 1986, the American National Standards Institute (ANSI), supported by IBM, declared SQL the standard relational database language. This was notable — and, in the end, critical for defeating Ingres.

Ingres’s Berkeley-honed engineering team had refined their user language, QUEL, to such perfection that many relational experts considered it to be intrinsically superior to SQL. Mike Stonebraker believed he had a compelling case for adopting QUEL as the ANSI standard. But he chose not to turn up at any of the ANSI committee meetings, because he was ideologically against the notion of setting technology standards. He behaved more like an arrogant academic than a prudent businessman.

Oracle never questioned the technical elegance of the QUEL language. But they didn’t switch from SQL, either. Their decision to remain steadfastly aligned with SQL paid off. After the ANSI standard was passed, Ingres began losing ground to Oracle’s Version 4.

Finally, Oracle eventually overtook Sybase, despite the latter’s early architectural and marketing edge. Sybase faltered because it made several strategic errors: it botched up a version upgrade, failed to integrate its database with hot enterprise software from SAP and PeopleSoft, and finally, licensed its code to Microsoft, who became a fierce competitor in the database market within a matter of years.

It would seem many of Oracle’s competitors lost through unforced errors. This is accurate, but it is not the only reason for Oracle winning the database war.

Oracle entered the market early, at a time when the relational model was unproven and competition was sparse. It picked a market wedge – minicomputers – where the most powerful incumbent was hesitant to go all in.

It bet on a technology – SQL – and remained pragmatically aligned with it. That SQL later became the industry standard couldn’t have been predicted by Ellison. He merely took the opportunities as he saw it.

Ellison had a propensity for grandiosity and a penchant for hyperbole. So nobody was surprised when a few months before Oracle’s IPO in early 1986, he declared that the company would double its revenues every year. Indefinitely. Of course, nobody believed him.

A year later, with revenues of US$131M, Oracle claimed to be the world’s biggest database software company.

Oracle databases are still used widely today. As Ellison reminds us so proudly:

‘The Oracle database is used to keep track of basically everything. The information about your banks, your checking balance, your savings balance, is stored in an Oracle database. Your airline reservation is stored in an Oracle database. What books you bought on Amazon is stored in an Oracle database. Your profile on Yahoo! is stored in an Oracle database.’

A triumph, if there ever was one.

Sources

Finished reading this case?