In 1983, Larry Ellison was working at a small company called Oracle (now, of course, the largest enterprise software company), fixing bugs in its database products. In the rear, however, Mike Stonebraker, a computer science professor and database legend, was catching up fast.

Later, Matthew Symonds, in His book Softwar, said:

“Larry Ellison didn’t pay a lot of attention to sales, and as far as Ellison is concerned, the most important contribution he can make to Oracle’s success is to overrule everything and focus on making the product better. He simply didn’t think he was capable of caring about all the other things a CEO was supposed to be responsible for. To some at Oracle, Ellison’s approach is part of an enlightened delegation, some say. “He is closer to abdication than mandate.” Of course, as a result, Ellison did have good reason to focus on the product.

At the same time, Mike Stonebraker started the Ingres Relational database project he oversaw at uc Berkeley and formed a company around it called Relational Technology, Inc. (RTI). Although the commercial version of Ingres came to market later than Oracle, Mike Stonebraker’s company grew faster than Oracle’s. In 1984, Oracle’s sales doubled to $12.7 million, while Ingres’ sales tripled to $9 million as RTI became more aware.

As Larry Ellison later said, “RTI was really kicking our ass [at the time], but they caught up because our new database product was changing a lot and we had software quality issues.”

Ingres’s Berkeley team has had more time to perfect its user language, QUEL, which many relationship experts consider to be essentially a high-level language, than Oracle developed SQL. Larry Ellison said: “Maybe QUEL is better than SQL, just as someone thinks French is better than English? But never mind, SQL wins just like English.”

Larry Ellison’s biggest concern is not the superiority of the language, but the sheer quantity of talent in Ingres. “It was painful for me that our development team wasn’t strong enough to keep up with the Ingres team. So we had to rebuild it. If Mike Stonebraker hires the best students from Berkeley, let’s hire the best students from Caltech, MIT and Stanford. We will also recruit the most experienced programmers in Silicon Valley. In a big change, we also hired a fantastic team from Xerox PARC, a famous research organization at the time, and one of them was Derry Kabcenell, who was one of the most important people to ever work at Oracle. “Thanks to Derry and the new team he led, we overcame the software quality issues in Oracle GENERATION 3 and delivered a great database product (of which we can be proud) that killed Ingres, our Oracle generation 4.”

Of course, the story is short, but the truth is much more than that. Oracle 4 is a really good product, at least better than Oracle 3, which had more bugs than discarded pomelos when it was released to the market. But 4 is not the reason for its success, even though it is technically superior to Ingres.

It worked because of the strength of IBM, and because Mike Stonebraker made a terrible mistake.

Oracle 4 was released, and after months of persuasion from IBM and Oracle, THE American National Standards Institute (ANSI) declared SQL the standard relational database language. Matthew Symonds wrote:

Ingres struggled to maintain its momentum due to the reliability of Oracle 4 and Oracle’s growing sales force, but the real threat was the decision by the American National Standards Institute (ANSI), backed by IBM, to adopt SQL as the standard relational database language. Mike Stonebraker didn’t even bother to show up at the committee meeting to make the (very strong) case for adopting QUEL over SQL because he was ideologically opposed to setting technical standards.

These are the actions of an academically arrogant academic, not of a prudent businessman protecting his company’s interests. Larry Ellison said: “Mike Stonebraker invented QUEL and stuck with it like a proud father, while IBM and Oracle supported the SQL standard. The lack of SQL support has hurt Ingres badly, while its lack of portability and consistency has left Ingres lagging far behind other databases. All of this combined to cause Ingres’s downfall.”

Going back to the language itself, how good is QUEL? Matthew Symonds gives an example: Many relationship experts think this is essentially a high-level language, and many underestimate how much respect QUEL was held by the pioneers who invented modern relational databases.

For example, in 1985, the year QUEL and Ingres failed, database legend CJ Date worked with Codd, the inventor of IBM’s relational model, on IBM’s relational model-writing a paper in which he argued that QUEL was the best of both languages.

Why is that? The argument is that QUEL is closely related to Codd’s relational calculus, while SQL is not. QUEL is also a carefully designed language, written by engineers who were under intense pressure to bring an IBM database called System R to market. To prove that the relational database model can be a viable architecture for data storage systems (sources). It seems ridiculous today, but back then, the prevailing view was that relational databases were little more than a toy. The System R engineers, and Larry Ellison a few years later at Oracle, did the work for them to prove that RDBMSes was the future. As a result, the engineers who created SQL focused on database performance rather than language design, never expecting that the user interface they invented would become standard.

So what’s wrong with SQL? What’s wrong with deviating from the relationship model outlined by Codd?

Late last year, I had such a discussion with Thanh, the lead 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, and Codd’s relational model is great. But as an expression of that model, SQL is flawed.”

Thanh later explained in a review he wrote:

“… The language (SQL) is not easy to put together. Most SQL users are unaware of this fact. The relational algebra on which SQL is based is absolutely composable, but SQL is not due to the inherent limitations of the language (because it is designed to resemble natural language). When you write “select X from position Z”, you are actually constructing objects in algebra in the way that “select X from a” => “where Z” => “select X”, you can actually compose each part separately. If you are familiar with DPlyr, Spark or Pandas, you will get this information immediately.”

To the best of my knowledge, it is absurd that QUEL’s calculus is closer to Codd’s. The world is not black and white, but if there is a parallel universe in which QUEL is now SQL, the “best” language has found its place. But that’s not the way the world works. If the world worked differently, we wouldn’t write on keyboards or speak English. Better technological alternatives such as Dvorak and Esperanto will be taken over.

In short, the world has now standardized on SQL, and the dream of an alternative history exists only in the minds of those who fought in the early database wars. It was just a quirk of history that System R was built inside IBM, the most powerful company in the computer industry at the time. Then the engineers building System R came up with a weird language interface, which was a quirk, and then IBM took that language and pushed it to a standard, which was a quirk… It continues to this day.

Of course, legendary Mike Stonebraker didn’t stay quiet, starting his own company in 1982 by creating the Ingres codebase. Defeated in the bitter database wars of the 1980s, he returned to Berkeley in 1985 and began the database project after Ingres.

Then PostgreSQL was born.

** Disclaimer: ** This article is edited and translated by Tencent Cloud database product team. The original content is from DB Weekly English official website (dbweekly.com). If reprinted, please indicate the source. The purpose of the translation is to convey more information related to the latest global database field, and it does not mean that Tencent cloud database product team agrees with its views or confirms the authenticity of its content. If other media, websites or any other form of legal entities or individuals use, the copyright owner must be legally authorized in writing and bear all legal responsibilities. Shall not be reproduced in the name of Tencent cloud database team without authorization, or embezzle Tencent cloud database team name to release information. Due to the author’s limited translation skills, the translation process is inevitable mistakes, if there is any fallacy, please criticize and correct readers.

This article is published by OpenWrite, a blogging tool platform