The Oracle of Surveillance: How Larry Ellison Built America's Invisible Empire
Part 1: The Database That Named Itself
In the summer of 1977, three men pooled $2,000 and started a company in Santa Clara, California. One of them, a college dropout who had bounced between jobs the way a pinball bounces between bumpers, put in $1,200 of his own money. No venture capital. No angel investors. No Stanford connections pulling strings behind the curtain.
And their first real client was the Central Intelligence Agency.
That's not a punchline and it's not a conspiracy theory you found on a forum at 3 AM. That documented and verified fact has simply been hiding in plain sight for nearly fifty years.
The company those three men built is now worth over $400 billion and sits at the center of the global cloud infrastructure, processes financial transactions for most of the world's banks, manages healthcare records for entire nations, and runs the backend systems of militaries on four separate continents. In the last decade alone, it has spent over $110 billion buying its way to omniscience, swallowing companies the way a python swallows prey: slowly, completely, and with no intention of letting go.
That company is Oracle, and this is their villainous origin story.
Not the version you've read in Fortune profiles or heard in TED talks or seen dramatized in the kind of hagiographic business journalism that treats billionaires like folk heroes. This is the real version, the version with the NSA contractor and the coin flip and the dead man who actually wrote the code.
The Paper IBM Buried
Before Oracle was Oracle, before it was even a company, it was an idea. And the idea didn't belong to Larry Ellison.
It belonged to a dead Englishman named Edgar Frank Codd.
Edgar Frank "Ted" Codd was born in 1923 in the village of Fortuneswell on the Isle of Portland, in Dorset, England. He studied mathematics and chemistry at Oxford. He flew for the Royal Air Force during World War II, a decorated pilot who survived the kind of war that turned most young men into ghosts or drunks or both. After surviving the war, in 1948 he ended up at working at IBM. He was 25 years old, brilliant in the way that makes corporate managers deeply nervous, and already was developing a reputation for caring more about being right than being liked.
IBM in the late 1940s and 1950s was not the lumbering bureaucracy it would later become, it was the frontier. The machines were room-sized, the problems were genuinely unsolved, and for a mathematician with Codd's talent, it was the only game in town.
But Codd had principles, incredibly inconvenient principles.
In 1953, at the height of the McCarthy era, with Senator Joseph McCarthy's anti-communist hearings turning the American scientific community into a minefield of loyalty oaths and blacklists, Codd did something remarkable, he left. He packed up and moved to Ottawa, Canada, because he refused to live under the shadow of a political witch hunt. He was an Englishman who had fought fascism in the skies over Europe and was not about to bend the knee before a senator from Wisconsin who saw communists behind every chalkboard.
After the height of McCarthyism, Codd decided to return to IBM in 1957 after speaking with his former manager and in 1965, he earned his PhD in computer science from the University of Michigan, at the age of 42, because Codd did things on his own schedule and not a moment before he was ready. And then, in June of 1970, working out of IBM's San Jose Research Laboratory in California, he published a paper that would change the architecture of human knowledge.
The paper was called "A Relational Model of Data for Large Shared Data Banks." It appeared in Communications of the ACM, Vol. 13, No. 6. Twelve pages. Dense with mathematical notation, and abstract in a way that made most business executives' eyes glaze over within seconds. And it was absolutely, fundamentally revolutionary.
What Codd proposed was deceptively simple. Instead of storing data in rigid, hierarchical trees where every piece of information had to know its exact position in a predetermined structure, you could store it in tables. Rows and columns. Relations. And you could query those tables with formal logic, asking questions the original designers of the database never anticipated and never needed to anticipate.
Before Codd, if you wanted to ask a database a question it wasn't designed to answer, you were out of luck. You would have to rebuild the entire data structure from scratch. After Codd, you could ask anything, and the data would rearrange itself to answer you.
Think about what that means. Really think about it. A system where you could store everything, about everyone, and then ask any question about any of it, in any combination, at any time. Cross-reference a name with an address with a phone record with a travel itinerary with a bank transaction, and it would return you the answer instantly.
If you were in the business of selling widgets, that was a nice efficiency improvement.
If you were in the business of collecting information on people, on organizations, on governments, on entire populations, Codd's relational model wasn't just an improvement…
It was the Holy Grail.
IBM had this paper. IBM owned this paper. IBM employed the man who wrote it.
And IBM buried it.
Not maliciously, exactly. Not in some smoke-filled room with men in dark suits shredding documents. IBM buried it the way large corporations always bury things that threaten their existing revenue streams: through institutional inertia, internal politics, and the gravitational pull of quarterly earnings reports.
See, at IBM was making enormous money selling IMS, its hierarchical database system. IMS worked. IMS had customers. IMS had an entire sales force that understood it, could demo it, could explain it to procurement officers over steak dinners. Codd's relational model would render IMS obsolete, and every executive at IBM who had staked their career on IMS, who had hit their quarterly numbers selling IMS licenses, who had corner offices because IMS was printing money, knew it.
So they sat on it.
As Mike Wilson documented in his book The Difference Between God and Larry Ellison, IBM's internal response to Codd's paper was essentially to develop a research prototype called System R, staff it with people who had no connection to Codd, deliberately exclude Codd himself from the project, and then make absolutely certain it never shipped as a commercial product. They let Codd present at conferences. They let him publish follow-up papers. They let the academic world fall in love with the relational model. They let universities build teaching curricula around it. And then they locked the implementation in a drawer and went back to selling IMS.
This is how paradigm shifts get strangled in the crib. Not by ignorance. Not by malice, really, but simply because it threatened the bottom line.
The irony is exquisite. IBM had assembled, in one building, the theoretical breakthrough and the engineering talent to build the most important piece of software in the history of computing. They had the inventor. They had the blueprint. They had the money. And they chose, deliberately and repeatedly, to protect a product they already sold rather than build the product the world actually needed.
System R did produce one lasting artifact, though. The query language its developers created, called SEQUEL and later shortened to SQL, would become the universal language of relational databases. So IBM managed to invent the language without ever shipping the product. They wrote the dictionary for a country they refused to build.
Codd watched all of this happen. He watched his employer bury his work. He watched younger researchers at other institutions begin implementing his ideas. He watched the relational model escape IBM's gravitational field and begin taking root in universities, in government research labs, in the imaginations of programmers who read his 1970 paper and understood immediately what it meant.
Codd would eventually receive the Turing Award in 1981, the highest honor in computer science, for work his own employer refused to turn into a product. He died in 2003 at the age of 79, having watched from the sidelines as other people built empires on his ideas. The company that finally made his vision real, that took his twelve pages of mathematics and turned them into the most consequential database product in history, was not IBM.
It was three guys in Santa Clara with $2,000.
But we're getting ahead of ourselves.
Inside the Machine
To understand where Oracle came from, you have to understand Ampex, and to understand Ampex, you have to understand what America's intelligence apparatus was building in the 1960s and 1970s, when surveillance was not yet a consumer product you carried in your pocket but instead, was very much a government capability being refined behind classified walls.
Ampex Corporation was founded in 1944 by Alexander M. Poniatoff, a Russian emigre and engineer, in San Carlos, California.
The name was an acronym: (A)lexander (M). (P)oniatoff (Ex)cellence. The "Ex" was for excellence. Silicon Valley naming conventions have always been a little much.
The company's public reputation was built on audio and video recording technology. Bing Crosby was an early investor and adopter. They made the machines that recorded television broadcasts, the tape systems that let studios time-shift programming. Respectable work. Glamorous, even. The kind of company you'd be proud to tell your mother you worked for.
That was the front of the house.
The back of the house was the National Security Agency.
Ampex held classified contracts with the NSA to build systems for signals intelligence. SIGINT. The art and science of intercepting, recording, storing, and analyzing electronic communications. Two programs in particular matter for this story, and their code names have the distinctly American quality of being simultaneously absurd and chilling.
The first was code-named KETCHUP, later sanitized to KETCHUM. KETCHUM was a 42-track signal intercept system. Forty-two simultaneous tracks of recorded signals intelligence. In the 1960s. When most recording systems handled one or two tracks. When the average American home had a single-channel reel-to-reel if they had anything at all. Ampex was building machines that could drink from 42 firehoses at once.
The second program was code-named GOODMAN. Where KETCHUM captured the raw signal flood, GOODMAN was the replay and analysis system. The tool that let analysts go back through what KETCHUM had captured and actually make sense of it. Find the needle. Pull the thread. Connect the dot you didn't know existed to the dot you'd been staring at for six months.
During the Cuban Missile Crisis of 1962, KETCHUM/GOODMAN systems were deployed to help monitor Soviet communications. This is the level of work we're talking about. This is not a company making tape decks for recording studios. This is a company embedded in the most sensitive intelligence operations of the Cold War.
This is the environment Larry Ellison walked into.
Ellison arrived at Ampex in the early 1970s, a young programmer with an incomplete resume and an unfinished education. He was not yet Larry Ellison, billionaire yacht racer, island owner, sixth-richest person on Earth. He was Larry Ellison, guy who couldn't seem to finish anything. Born in 1944 on the South Side of Chicago to an unwed mother who gave him up at nine months old, raised by his great-aunt and great-uncle in a middle-class Jewish household, he had attended the University of Illinois at Urbana-Champaign and the University of Chicago without graduating from either. He drifted to California the way a lot of young people drifted to California in those years: because it was far away from where he'd been, and that seemed like enough of a reason.
But here's the thing about Ellison that gets lost in the dropout narrative. He wasn't stupid, in fact, he was the direct opposite of stupid. He was the kind of intelligent that institutions can't contain, the kind that chafes against curricula and deadlines and the particular indignity of being told to learn something at someone else's pace. He taught himself programming. He read voraciously. He had the specific, dangerous combination of extreme intelligence and extreme impatience that either produces founders or felons.
He did programming work at Fireman's Fund and a couple of other shops. Nothing that stuck. Nothing that suggested the trajectory to come. That all changed when he landed at Ampex.
At Ampex, Ellison was a programmer working on database-related projects. More specifically, he worked in an environment absolutely saturated with intelligence community contracts, security clearances, classified briefings, and the particular culture that develops when your employer's real customer is an agency whose budget is itself classified and whose very existence was, for decades, officially denied by the U.S. government.
This is where he met Bob Miner.
Miner was Ellison's manager at Ampex. And if Ellison was the unstable element, all kinetic energy and ambition and raw charisma bouncing off the walls, Miner was the ballast. The weight that kept the ship from capsizing. Born on December 23, 1941, in Cicero, Illinois, a working-class suburb of Chicago famous mainly for Al Capone having used it as a base of operations, Miner was the son of Iranian Assyrian immigrants whose family traced its roots to the village of Ada in the West Azerbaijan province of Iran. He earned a BS in Mathematics from the University of Illinois in 1963, came west to California, and built a quiet reputation as the kind of programmer who actually understood what he was building. Not just how to build it, but why. Not just the syntax, but the semantics.
The dynamic between Ellison and Miner at Ampex is one of those professional relationships that only makes sense in retrospect, when you can see where it led. Ellison was the mouth. Miner was the hands. Ellison could sell a vision of the future to anyone in any room, make them believe they were already living in it, make them reach for their checkbooks. Miner could make that vision actually function. Could turn the slideshow into software. Could sit at a terminal for sixteen hours and emerge with something that worked.
At Ampex, surrounded by NSA contracts and the quiet hum of classified machinery, they developed a shared understanding of what databases could do, what they were being used for, and where the real money was. They saw what the intelligence community wanted. They saw what Codd's paper had made theoretically possible. And they saw that IBM, the only company with both the paper and the resources to build it, was never going to ship it.
They also developed something else. A shared knowledge of exactly who was buying this technology and exactly what they intended to do with it.
When people tell the founding story of Oracle, they usually start with the garage. The dropout. The dream. The scrappy startup that took on IBM and won. They almost never start with the NSA signals intelligence contractor where the founders cut their teeth, building storage and retrieval tools for an intelligence community that wanted to record everything on Earth and then search all of it.
But that's where it started.
In the machine.
Three Men and a Coin Flip
On June 16, 1977, Software Development Laboratories was incorporated in Santa Clara, California. SDL. Three letters. The most boring, forgettable, deliberately anonymous name imaginable for what would become the most consequential database company in history.
The three founders: Larry Ellison, Bob Miner, and Ed Oates.
Oates is the one nobody talks about. The third man in a story that gets told as a two-man show. Born in 1946, he had come into the orbit of Ellison and Miner through one of those coincidences that Silicon Valley loves to claim as evidence of its meritocratic magic. He met the founders through a connection to a high school lab partner. That's it. Not a Stanford networking event. Not a venture capital introduction at a Palo Alto wine bar. A high school lab partner who happened to know the right people at the right time.
The total capitalization of Software Development Laboratories was $2,000. Ellison put in $1,200 of his own money. Miner and Oates split the remaining $800 between them. No outside investors. No angel round. No seed funding. They never took venture capital. Not at founding, not during growth, not ever.
This is a detail that gets glossed over constantly in the retelling of Oracle's origin story, and it shouldn't be, as it's genuinely unusual. Every other major technology company of that era, and nearly every one since, took outside money. Apple took Mike Markkula's $250,000 in 1977 and went on to raise millions more. Microsoft had a sweetheart licensing deal with IBM that functioned as a massive capital injection. Google took $25 million from Kleiner Perkins and Sequoia Capital in 1999. Facebook took $500,000 from Peter Thiel, then millions from Accel Partners.
SDL took $2,000 of its founders' own cash and told Wall Street to go find someone else.
But why?
Because they didn't need investors. They had something better.
They already had a big customer.
The Central Intelligence Agency.
The CIA contract was worth $50,000. Twenty-five times the company's total capitalization, and they already had a project name.
Oracle.
And the deliverable, described in language that should make the hair on the back of your neck stand up if you've been paying any attention at all to this story, was a system that could "answer any question about anything."
Pause on that. Roll it around in your mouth. "Answer any question about anything."
This wasn't a payroll application. This wasn't an inventory management system for tracking widgets in a warehouse. This wasn't a customer relationship database for a regional insurance company. This was a tool designed for the Central Intelligence Agency, an organization whose entire institutional reason for existing is the collection, correlation, analysis, and exploitation of information, and the specification called for a system that could answer any question about anything.
The relational database model that Ted Codd had published seven years earlier, the one IBM refused to build into a commercial product, was exactly the technology that could deliver on that promise. Tables of data that could be queried in any direction, joined in any combination, cross-referenced and interrogated in ways the original designers never imagined and never needed to imagine. The CIA didn't want a better filing cabinet. They didn't want a faster way to sort index cards.
They wanted an oracle.
And now you know where the name came from.
Here's the part that kills me every time I come back to it. According to Mike Humphries, a colleague who heard the story directly from Bob Miner, the decision to take the CIA contract instead of pursuing a different project, a compiler for the PDP-4 minicomputer, came down to a coin flip.
A literal coin flip.
Stay with me here. Three men standing in a room in Santa Clara, California, in the summer of 1977, flipping a coin to decide whether they'd spend their nascent company's first months building a compiler or building a database for the Central Intelligence Agency. Heads or tails. The coin comes up CIA. And the entire trajectory of global data infrastructure, of surveillance technology, of the relationship between Silicon Valley and the intelligence community, pivots on that moment.
You can choose to believe that's just how startups worked in 1977. Informal. Scrappy. Seat-of-the-pants decisions made over beers and coin flips because nobody had a business plan and nobody cared. And maybe that's all it was. Maybe the coin really did decide.
Or you can look at the fact that two of the three founders had just come from an NSA signals intelligence contractor. That they had spent years immersed in classified database projects for the intelligence community. That the CIA was ready with a $50,000 contract and an actual project code name before the company was barely incorporated, before it had an office or a product or even a second customer. That the project specification read like a wish list pulled directly from the intelligence community's deepest operational desires.
And you can ask yourself: how many coin flips are really coin flips?
I'm not saying the fix was in. I'm not saying the CIA recruited Ellison and Miner out of Ampex like a handler running an asset. I'm saying that the infrastructure was already there. The relationships were already there. The knowledge of what the intelligence community wanted, and the technical understanding of what Codd's model could deliver, was already there. The coin flip, if it happened at all, was a formality. The gravitational pull of the intelligence community had been drawing these men toward this moment for years.
Coincidence is a word people use when they don't want to draw the line between the dots.
SDL took the CIA contract. They built the system. They called it Oracle, after the project code name their client had given them. And they kept building.
Version 2 (There Was No Version 1)
The first version of Oracle that SDL shipped to an external customer was called Oracle Version 2.
There was no Version 1.
This was not an accident. This was not a numbering error. This was not the result of some internal prototype being counted as the first release. This was deliberate deception, and the reasoning behind it, reportedly attributed to Ellison himself, is both brazen and illuminating: "Who would buy Version 1 from four guys in California?"
Nobody blinked. Nobody said, "Wait, shouldn't we start at 1?" The lie was baked in from the very beginning, and it was so casual, so instinctive, that it barely registered as a lie at all. It was just how you did business.
Think about the psychology embedded in that single question. Before the product even existed in a shippable commercial form, the founders understood that perception mattered more than reality. That the appearance of maturity, of a track record, of having already been through one cycle of development and refinement, was more valuable to a buyer than the actual truth of the product's history. They weren't just selling software. They were selling confidence. Selling the illusion of institutional solidity. Selling a lie that said "we've been at this longer than we have."
This instinct, the willingness to bend the truth when the truth was inconvenient, to let the customer believe something that wasn't quite real, would define Oracle's corporate culture for the next five decades. It would infuriate competitors, regulators, and customers in roughly equal measure. And it would work spectacularly.
The fourth person in the room during those early days was Bruce Scott. Employee number four, hired at 24 years old. Scott wasn't a founder, but he was foundational. If Miner was the architect of Oracle's database engine and Ellison was the salesman who could convince a drowning man to buy a glass of water, Scott was the bricklayer. He wrote enormous quantities of the early Oracle code, the actual implementation of Codd's relational model that would become the foundation of a multi-billion-dollar empire.
Scott later described working with Ellison with a metaphor that has stuck with me since I first read it: "It was like working with a guy who kept hitting the product with a hammer to see what would break, and then telling the customer it was unbreakable."
That hammer. That's the Oracle story in a single image.
Scott is also responsible for one of the most enduring and ubiquitous artifacts in the entire history of database technology. Every Oracle DBA in the world, every database administrator who has ever installed Oracle, tested Oracle, troubleshot Oracle at 3 AM while their pager screamed, knows the default demonstration credentials: username SCOTT, password TIGER. Scott was Bruce Scott. Tiger was the name of his daughter's cat.
A cat named Tiger, belonging to the daughter of a 24-year-old programmer in Santa Clara, California, in the late 1970s, is now embedded in the muscle memory of hundreds of thousands of database administrators worldwide. Her name is typed into terminal windows in Tokyo and Frankfurt and São Paulo and Bangalore every single day. Security auditors have been flagging SCOTT/TIGER as a vulnerability for literally decades, and it still shows up in production databases with the regularity of a bad habit nobody wants to quit. That is either beautiful or terrifying, depending on how you feel about the security posture of systems that store your medical records and financial data. Which Oracle does. For most of the planet.
And the habit never broke. In 2026, a casual scan of Oracle's own public certificate transparency logs turned up 2,669 subdomains broadcasting internal naming conventions to anyone with a browser and ten minutes of curiosity. Physical facility codes. Network topology hints. Device naming patterns that let you map the architecture like reading a blueprint left on a park bench. The company that built a system to "answer any question about anything" still can't stop answering questions about itself. Forty-eight years of the same reflex. SCOTT/TIGER all the way down.
The company changed names the way a con artist changes towns. Always moving, always rebranding, always shedding the last identity before anyone looked too closely at it. Software Development Laboratories became Relational Software Inc., RSI, in 1979. RSI became Oracle Systems Corporation in 1982. Oracle Systems Corporation became simply Oracle Corporation in 1983. Each name change shed a layer of origin story. Each new name was slightly grander, slightly more authoritative, slightly further from the reality of a handful of exhausted programmers working brutal hours in a rented office to make a database that wouldn't crash during demos.
But here's the thing that gets lost in all the chaos and hustle. Underneath the salesmanship, underneath the version numbering tricks and the name changes and Ellison's legendary, industry-defining capacity for creative truth-telling, the product was real. The technology actually worked. Codd's relational model, implemented by Miner and Scott and a growing team of engineers who were very, very good at what they did, was genuinely revolutionary. You could ask it questions no one had anticipated. You could combine data in ways that made hierarchical databases look like stone tablets. You could build applications on top of it that would have been architecturally impossible two years earlier.
The product was real. The salesmanship was often fiction. But the product was real.
And the CIA already knew it. They'd known it since 1977, when three guys in Santa Clara, two of them fresh from an NSA contractor, told Langley they could build a system to answer any question about anything. The agency didn't take that meeting because they were curious about startup culture. They took it because they understood, before almost anyone else in the world, what a working implementation of Codd's relational model would mean for intelligence operations.
Soon, the rest of the United States government would understand it too.
Government From Day One
Oracle's first commercial customer outside the intelligence community was not a bank. Not a hospital. Not a manufacturing company. Not a retailer.
It was the United States Air Force.
Wright-Patterson Air Force Base in Dayton, Ohio, signed on in 1979. Wright-Patterson, for those who don't track military installations, is one of the most important logistics and intelligence hubs in the entire U.S. defense infrastructure. It houses the Air Force Research Laboratory. It hosted Project Blue Book, the Air Force's UFO investigation program. It is not a backwater posting. It is a nerve center.
And it was Oracle's first paying commercial customer.
The same year SDL renamed itself Relational Software Inc. The same year the company started shipping Version 2 and pretending Version 1 had existed.
This is not coincidence. This is a pattern.
The company born from a CIA contract got its first paying commercial customer from the Department of Defense. Its second and third and fourth major customers were overwhelmingly government agencies, defense contractors, and intelligence-adjacent organizations. The federal government didn't just support Oracle in its early years. The federal government was Oracle's market in its early years. Without those contracts, without the government's willingness to bet on a tiny company with a product called Version 2 and no Version 1, there is no Oracle. Full stop. The company dies in a rented office in Santa Clara, and Ted Codd's relational model waits for someone else to commercialize it.
But Oracle didn't die, it grew.
And it grew fast.
By 1983, just six years after its founding, Oracle was the largest relational database company in the world. Six years. From a $2,000 capitalization and a single CIA contract to global market dominance in the time it takes some venture-backed startups to finish their Series A. That trajectory doesn't happen on product quality alone, though the product was good. It doesn't happen on sales talent alone, though Ellison could sell sand in a desert. It happens when your customer base has effectively unlimited budgets funded by the U.S. taxpayer, when your technology solves a problem that the most powerful institutions on Earth consider existential, and when the people evaluating your product have the security clearances to know exactly what it can do because they've seen it do it.
The IPO came on March 12, 1986. In one of those historical coincidences that's almost too perfect, Microsoft went public the very next day, March 13. Two companies that would come to define the global technology landscape, going public within 24 hours of each other. Oracle reported $55 million in annual revenue and had approximately 450 employees. It was, by any measure, already a major technology company.
But the IPO did something beyond raising capital. It made Oracle visible in a way it hadn't been before. It drew Wall Street analysts. It drew journalists. It drew attention. And with attention came the beginning of a transformation that would accelerate over the next four decades.
Oracle began building a revolving door between itself and the U.S. government that would spin with increasing speed for decades. Military officials retired from the Pentagon and joined Oracle's consulting division. Oracle executives took advisory positions in government agencies. Government procurement officers who had approved Oracle contracts showed up on Oracle's payroll a few years later. Consulting contracts flowed in both directions. Data migration projects multiplied.
The line between Oracle the private corporation and the government that had birthed it grew thinner and thinner until, in certain corridors of Washington, in certain Pentagon procurement offices, in certain intelligence community briefing rooms, it was effectively invisible.
A CIA director would sit on Oracle's board of directors. We will get to that story in detail in a later installment of this series. For now, just file that fact away. Let it sit in the back of your mind like a low electrical hum you can't quite place but can't quite ignore.
And decades later, the database built for the CIA would find new political patrons. A think tank with a plan. A project with a number. A personnel system designed to reshape the federal government from the inside out. Oracle would build that too. That story comes later.
The company that started with a CIA contract would end up with a CIA director helping to govern it. The company built to "answer any question about anything" would spend the next four decades embedding itself in every database, every cloud system, every government network where questions were being asked and answers were being stored.
From Day One, Oracle was a government company wearing a commercial mask. The mask got nicer over the years. More polished. The suit got more expensive. The lobbying operation got more sophisticated. The marketing got slicker. But underneath all of it, from that first $50,000 check signed at Langley to the multi-billion-dollar federal cloud contracts of today, the underlying relationship never changed.
It just scaled.
And scaled. And scaled.
Oracle went from databases to applications to middleware to cloud infrastructure. It bought PeopleSoft in a hostile takeover so brutal it became a Harvard Business School case study. It swallowed Sun Microsystems whole, acquiring Java and MySQL and Solaris and an entire hardware division in a single gulp. It bought over 130 companies in a two-decade acquisition spree that reshaped the entire enterprise technology landscape.
But all of that comes later. Right now, in the mid-1980s, Oracle is a publicly traded company with deep government roots, a product that works, a sales culture that would make a used car lot blush, and a void at its center that is about to become permanent.
The Ghost of Bob Miner
Bob Miner died on November 11, 1994. Veterans Day. He was 52 years old.
The cause was an aggressive and almost invariably fatal cancer of the tissue lining the lungs. It is a cancer caused, in the overwhelming majority of cases, by exposure to asbestos. The son of Assyrian immigrants from a village in the mountains of western Iran, the quiet mathematician from a working-class suburb of Chicago, the man who actually built the database that Larry Ellison sold to the world, was dead before Oracle's real story had even begun.
Miner never saw the cloud. Never saw the acquisition spree that would consume more than a hundred companies. Never saw Oracle become a surveillance infrastructure company masquerading as an enterprise software vendor. He built the engine. And then he was gone.
The people who knew him, who worked beside him in those early years, describe a person fundamentally different from the company he helped create. Where Ellison was bombastic, Miner was measured. Where Oracle's sales culture rewarded aggression and creative truth-telling and the willingness to promise features that didn't exist yet, Miner valued precision and honesty and the quiet satisfaction of code that actually worked. He was the conscience of the operation. The person in the room who would look at Ellison and say, "We can't promise that, Larry. That's not what the product does."
When he died, that voice went silent. And nobody replaced it.
It is impossible to know what Oracle would have become if Miner had lived another twenty or thirty years. Maybe nothing different. Maybe Ellison's gravitational pull was always too strong, the market forces too powerful, the government's appetite too insatiable for one quiet engineer to redirect the course of a company already moving at escape velocity. Maybe the machine was always going to become what it became.
But there's a version of the story where the man who actually understood the technology, who knew what it could do because he'd built it with his own hands at a keyboard, who had the moral weight and the institutional standing to push back against its worst possible applications, was still alive when the decisions that mattered most were being made.
We don't live in that version.
We live in the one where Bob Miner is a footnote in someone else's biography, where Larry Ellison is the main character of every telling, and where a company born from a CIA project called Oracle became a corporation called Oracle and nobody ever thought that was strange.
His grave is in the Hills of Eternity Memorial Park in Colma, California. The town of Colma has more dead residents than living ones. It's where San Francisco sends its cemeteries. Bob Miner, the man who built the database that knows where everyone is, rests in a town of the dead, surrounded by people who can no longer be queried.
The Red Thread
So that's where it started. A buried paper. An NSA contractor. Three guys, two thousand dollars, and a coin flip. A CIA project code-named Oracle that became a company called Oracle, selling a technology designed to answer any question about anything to the people most interested in asking questions about everyone.
In the next installment, we're going to follow the thread forward. We're going to look at what Ellison built in the years after Bob Miner's death. At the ideas about surveillance that would terrify civil libertarians if they understood the infrastructure already in place. And at the precise moment when Oracle stopped being a database company and started being something else entirely.
Something much bigger. Something much darker. Something that touches your medical records, your financial data, your government identity, and a network of contracts so vast and so interconnected that mapping them requires the very technology Oracle sells.
The database named itself. Think about that. A CIA project called Oracle became a product called Oracle became a company called Oracle. The code name stuck because it was never just a code name. It was a mission statement. It was a promise, made to the intelligence community in 1977, that this technology would see everything, know everything, and answer any question about anything.
That promise has been kept. In ways that Ted Codd never imagined, that Bob Miner never lived to see, and that the rest of us are only beginning to understand.
The red thread doesn't end here. It's just starting to unspool.
We'll see you all at the next drop, but until then always remember to Follow The Red Threads.
Sources
Every claim is sourced. Feel free to check our work.
Edgar Frank Codd & The Relational Model
Codd, E.F. "A Relational Model of Data for Large Shared Data Banks." Communications of the ACM, Vol. 13, No. 6, June 1970. ACM Digital Library
Codd biographical details and IBM history: Computer History Museum
Codd's Turing Award (1981): ACM A.M. Turing Award
IBM's System R and suppression of the relational model: Wilson, Mike. The Difference Between God and Larry Ellison (William Morrow, 1997)
Ampex Corporation & NSA Programs
Ampex founding and history: Computer History Museum — Ampex
KETCHUM/GOODMAN signal intercept programs: Declassified NSA history documents, National Security Archive at George Washington University
Cuban Missile Crisis signals intelligence operations: NSA — The Cuban Missile Crisis
Oracle Founding
SDL incorporation (June 16, 1977), $2,000 capitalization, CIA contract: Wilson, Mike. The Difference Between God and Larry Ellison (William Morrow, 1997)
CIA "Oracle" project code name and "answer any question about anything" specification: Symonds, Matthew. Softwar: An Intimate Portrait of Larry Ellison and Oracle (Simon & Schuster, 2003)
Coin flip anecdote attributed to Bob Miner via Mike Humphries: Wilson, The Difference Between God and Larry Ellison
No venture capital funding: Oracle SEC filings, IPO prospectus (1986)
Larry Ellison Background
Birth, adoption, education history: Symonds, Softwar (2003); Wilson, The Difference Between God and Larry Ellison (1997)
Ellison at Ampex: Forbes profile
Bob Miner
Biographical details, Iranian Assyrian heritage, University of Illinois: Wilson, The Difference Between God and Larry Ellison
Death (November 11, 1994), pleural mesothelioma: Find a Grave — Bob Miner
Hills of Eternity Memorial Park, Colma, CA: Public records
Bruce Scott & SCOTT/TIGER
Employee #4 status, default credentials origin: Oracle Magazine interview archives
"Hitting the product with a hammer" quote: Wilson, The Difference Between God and Larry Ellison
Ed Oates
Third co-founder, high school lab partner connection: Symonds, Softwar
Version 2 (No Version 1)
Deliberate version numbering decision: Symonds, Softwar; Wilson, The Difference Between God and Larry Ellison
Company Name Changes
SDL → RSI (1979) → Oracle Systems Corporation (1982) → Oracle Corporation (1983): Oracle SEC filings; Oracle corporate timeline
Wright-Patterson Air Force Base
First commercial customer (1979): Wilson, The Difference Between God and Larry Ellison
Wright-Patterson history and mission: Wright-Patterson AFB official site
Oracle IPO
March 12, 1986, $55M revenue, ~450 employees: Oracle IPO prospectus, SEC EDGAR filings
Microsoft IPO March 13, 1986: SEC EDGAR
Certificate Transparency / OSINT
2,669 Oracle subdomains from public CT logs: Original research, crt.sh public database query (March 2026)
Methodology: Certificate Transparency specification, RFC 6962