A Short Story About SQL’s Biggest Rival

The year was 1983. Larry Ellison, over at a tiny company called Oracle, was focused on the fallout of a buggy database product rewrite. In the rearview mirror, catching up quickly, was computer science professor and eventual database legend Michael Stonebraker.

In his book, Softwar, author Matthew Symonds tells the story like so:

Ellison was still not giving much of his attention to what was or wasn’t happening in sales. As far as Ellison was concerned, overwhelmingly the most important contribution he could make to Oracle’s success was to concentrate on making the product better. He simply didn’t regard himself as competent to concern himself with all the other things that a CEO is supposed to be responsible for. To some at Oracle, Ellison’s approach was one of enlightened delegation. “You could say that,” he says. “But it was closer to abdication than delegation.”

In fact, Ellison had every reason to concentrate on the product. Mike Stonebraker had taken the Ingres relational database project he had overseen at the University of California at Berkeley and formed a company around it called Relational Technology, Inc. Although a commercial version of Ingres had come to market a little later than Oracle, Stonebraker’s outfit was growing faster than Ellison’s. In 1984, Oracle’s sales had doubled to $12.7 million, while Ingres, as RTI was increasingly known, had tripled its sales to $9 million. Ellison says, “They were really kicking our butts. They were catching up fast because we had just rewritten our database product and we were having software quality problems. Sound familiar?”

The Berkeley team at Ingres had had much more time to refine their user language, QUEL, than Oracle had to develop SQL, and many relational experts thought it was intrinsically a superior language. Ellison says: “Maybe QUEL is better than SQL. Maybe French is better than English? It didn’t matter: English and SQL were going to win.” What Ellison was most worried about was the sheer engineering talent at Ingres. “It had become painfully clear to me that our development organization wasn’t good enough to keep up with the team at Ingres. So we had to rebuild it. If Stonebraker was hiring the best kids from UC Berkeley, we would hire the best kids from CalTech, MIT, and Stanford. We would also recruit the very best experienced programming talent in the Valley. In a real coup we hired a superb team from Xerox PARC. One of those guys, Derry Kabcenell, was among the most important people ever to work at Oracle. Thanks to Derry and the new engineering team he led, we overcame the software quality problems in Oracle Version 3. He delivered a superior database product—a product we could be proud of—a product that would kill Ingres. We called it Oracle Version 4.”

Of course, this story is simplistic at best. Oracle Version 4 was a good product — certainly better than Oracle Version 3, which was released to the market with more bugs than a discarded pomelo. But it didn’t win because it was technically superior to Ingres. It won because IBM was powerful, and because Stonebraker made a mistake.

Later that year, after months of persuasion by IBM and Oracle, the American National Standards Institute (ANSI) declared SQL the standard relational database language. Symonds writes:

With the solidity of Version 4 and Oracle’s increasingly aggressive sales force, Ingres was hard pressed to maintain its momentum, but the real threat was the decision of the American National Standards Institute (ANSI), supported by IBM, to declare SQL the standard relational database language. Mike Stonebraker of Ingres didn’t even bother to show up at the committee meeting to make the (quite strong) case for adopting QUEL because he was ideologically opposed to setting technology standards. It was the behavior of an intellectually arrogant academic rather than a prudent businessman protecting the interests of his company. Ellison says, “Stonebraker invented QUEL and stuck with it like a proud father, while IBM and Oracle supported the SQL standard. Lack of SQL support hurt Ingres badly. But so did lack of portability and read consistency. And Ingres had fallen far behind in performance. All this together conspired to kill off Ingres as a competitor in the database market.”

How good was QUEL, really?

Symonds makes a passing remark in ‘many relational experts thought it was intrinsically a superior language’, but if anything that understates the degree with which QUEL was respected within the cluster of pioneers who invented the modern relational database.

In 1985, for instance, the year that QUEL and Ingres lost, database legend C.J. Date — who worked on the relational model at IBM with Edgar Codd (the inventor of said relational model)  — wrote a paper in which he argued that QUEL was the superior of the two languages.

Why? The crux of the argument was that QUEL hewed closely to the relational calculus laid out by Codd, whereas SQL did not. QUEL was also a language that was designed thoughtfully; SQL was written by engineers who rushed an IBM database named System R to market, under immense pressure to prove that the relational database model could be a viable architecture for data storage systems (source). It seems a little ridiculous today, but at the time, mainstream opinion believed that relational databases were nothing more than little toys. The System R engineers — and, in a few years, Larry Ellison over at Oracle — had their work cut out for them to prove that RDBMSes were the future. And so it was that the engineers who created SQL were focused on database performance, not language design, and they never expected the user interface they invented to take off and become a standard.

Well, ok, I hear you say, what are the problems with SQL? What’s wrong with drifting from the relational model as outlined by Codd?

I was involved in one such discussion late last year, with Thanh, the chief engineer at Holistics. “What do you think of SQL?” he asked, and I replied — as most classically-trained programmers do — “I think it’s ok. Why do you ask?”

“Oh I think SQL is flawed.”

“But Codd’s relational model —“

“Yes, Codd’s relational model is great. But, as an expression of that model, SQL is flawed.”

In a Slack comment he wrote (in a different context, and nearly one year later), Thanh explained:

… The language (SQL) is not very composable. This is a fact that most SQL users are not aware of. The relational algebra that SQL is based on is absolutely composable but SQL is not due to the inherent limitation of the language (as it was designed to be natural language-like). When you write "select x from a where z", you are actually building something along the lines of "from a" => "where z" => "select x" in the algebra and you can actually compose each portion separately. If you are familiar with dplyr, Spark or pandas you would get this instantly.

As far as I can tell, QUEL — which hewed more closely to Codd’s relational calculus — was ridiculously composable. We might have once lived in a world where QUEL and SQL would have continued to duke it out, and where the ‘best’ language might have found its own niches.

But alas, that isn’t how the world works. If the world worked differently, we wouldn’t still be writing on QWERTY keyboards, or speaking English; technically superior alternatives like Dvorak and Esperanto would have taken over. The world has since standardised on SQL, and the dreams of an alternate history exists only in the heads of those who had a hand in the early database wars. It was simply a quirk of history that System R was built within IBM, the single most powerful company in the computer industry at the time; it was a quirk that the engineers who built System R came up with a fiddly language interface as an afterthought, and it was a quirk that IBM then took that language and pushed it to become a standard … one that has lasted till today.

Of course, there was a silver lining to the whole saga. Stonebraker had forked the Ingres codebase in 1982 to create his company. Defeated by the bruising database wars of the 80s, he returned to Berkeley in 1985, and started a post-Ingres database project. Naturally, he named that database post-gres — as in, after Ingres.

And thus PostgreSQL was born.