← Blog··Updated 21 May 2026·6 min read

SQL or 'sequel': a short history of two pronunciations

Two pronunciations of SQL have coexisted for nearly fifty years. Why the language was renamed in the first place, and what each pronunciation preserves, turns out to be more interesting than the debate that surrounds it.

AI-assisted postDrafted with help from Claude, edited and fact-checked by Mart. See transparency policy →
British Airways Hawker Siddeley Trident 3B in flight

Hawker Siddeley Trident 3B in British Airways livery, in service 1971–1986. The Trident was built by the Hawker Siddeley aviation group, whose Hawker Siddeley Dynamics Engineering Limited subsidiary held the UK trademark on "SEQUEL" — which is the reason IBM was forced to rename the language to SQL in the late 1970s.

Two pronunciations, one language

The SQL community has carried two pronunciations of its language's name almost since the language was published, and it has done so without ever resolving the question in either direction. In any given engineering meeting, some people will say "S Q L," letter by letter, and others will say "sequel," and both groups are using the language correctly. The official standards land on one answer; the inventors of the language land on the other; the vendor documentation is split roughly along open-source versus Oracle lines. Each pronunciation has a documented history, and the two histories are not the same story.

This post is not an argument for one pronunciation over the other — both are defensible, and most of the people I have learned the most database engineering from have used the older form. The interesting part of the question is not which side is right. The interesting part is how the language ended up with two viable answers in the first place, and that story is worth telling on its own merits.

SEQUEL did not start out as SQL

The story begins at the IBM San Jose Research Laboratory in the early 1970s, where Donald D. Chamberlin and Raymond F. Boyce were thinking about how to make Edgar F. Codd's relational model usable for people who did not want to write set algebra. Their first attempt was a language called SQUARE — Specifying Queries in A Relational Environment — and it was, by Chamberlin's own subsequent admission, difficult to use. SQUARE leaned heavily on subscripted and superscripted notation; you could write a working query in it, but typing one out on the terminals of the time was an exercise in mechanical patience rather than expressive software design.

So Chamberlin and Boyce wrote a successor. They literally called it a sequel — Structured English Query Language — and pronounced the acronym the way the English word sounds, because the English word is what they typed. The 1974 SIGFIDET paper introducing it was titled SEQUEL: A Structured English Query Language. Inside IBM and in the early academic citations, the language was "sequel" because the word on the cover was sequel. The new language drove development of System R, IBM's prototype relational database, and quickly attracted external attention. The first commercial product implementing the language, Oracle V2, shipped in 1979 from a small company that later renamed itself Oracle Corporation. By that point everybody who had touched the language had been pronouncing it "sequel" for half a decade. The pronunciation was load-bearing in oral tradition before the language was load-bearing in industry.

A British aircraft engineering company owned the word

The interesting middle of the story is that the spelling did not last. Hawker Siddeley Dynamics Engineering Limited — a UK subsidiary of the Hawker Siddeley aviation group, primarily known for industrial control and aerospace electronics — held an active trademark on the word "SEQUEL." When IBM started looking at moving the language toward a product release in the late 1970s, the legal team came back with the obvious blocker: the four-letter brand the team had been using since 1974 was already a registered mark of a UK aerospace company in an adjacent technical domain, and IBM was not going to fight that trademark fight for a research-lab acronym. The name had to change.

Chamberlin and Boyce dropped the vowels. SEQUEL became SQL. The new spelling is what survived a trademark conflict, not what was chosen for aesthetics. Several Hacker News threads have surfaced the original IBM internal account of the renaming over the years, and the story is consistent across the early IBM technical reports: the language was renamed because the trademark on the original name was in someone else's hands, and the renaming was a legal compromise rather than a stylistic decision.

This is the moment the two pronunciations diverge. The written form changes to SQL; the spoken form, for the people who had been using the language for five years already, does not. Both forms remain in use after the rename, and the divergence becomes a permanent feature of the language's culture.

The standards landed on "ess cue el"

The first formal SQL standard was ANSI X3.135-1986, and one of the small but specific decisions it took was to declare the official pronunciation of the name. The standard's prose uses "ess cue el," letter by letter, throughout. The standard was adopted by ISO the following year as ISO 9075, and every revision of what is now ISO/IEC 9075 has used the same pronunciation in its informative text. The current edition, ISO/IEC 9075:2023, runs to nearly a dozen parts and uses S Q L throughout its prose.

The standards bodies took a position; the position was that the post-trademark spelling should also drive the pronunciation. It is one of the two data points the community has been navigating since.

The documentation has not converged

A short tour of vendor documentation is more entertaining than I expected when I first started looking, because the result is a roughly evenly-split bench rather than a uniform consensus.

  • MySQL — owned by Oracle since 2010 — instructs users in its own reference manual to pronounce the product as "My ess que ell," letter by letter.
  • PostgreSQL carries pronunciation guidance in the project FAQ and the development mailing list archives that consistently lands on "post-gres-Q-L" or its older "post-gres-ess-que-ell" form, both initialisms.
  • SQLite addresses pronunciation directly in its About page, spelling out "ess queue ell ite."
  • Microsoft SQL Server is mixed. The formal Microsoft documentation uses "S Q L Server" in writing; the in-house culture at Microsoft and most of the partner ecosystem says "sequel server" out loud. The brand has not formally resolved the disagreement.
  • Oracle Database has used sequel for the flagship since the earliest days, and the convention has persisted in product documentation and marketing material.

The wrinkle that I find genuinely interesting is internal to Oracle. The company sells more SQL than anyone else, ships MySQL with letter-by-letter pronunciation guidance, and pronounces its other flagship product the opposite way inside the same building. Neither pronunciation is wrong inside Oracle; both are codified in different parts of the company's portfolio. The split exists within a single vendor as well as across the industry.

What each pronunciation preserves

Each of the two pronunciations carries a piece of the language's history that the other does not.

"Sequel" preserves the original team's spoken tradition. Donald Chamberlin himself has continued to pronounce the language that way in his published retrospectives, interviews, and oral histories, and the word is older than the trademark issue that forced the spelling change. There is no version of the SQL community that does not include the language's inventors, and the language's inventors say "sequel." Anyone who uses that pronunciation is in the company of the people who designed the language, which is hardly bad company to be in.

"S Q L" preserves the trademark story. The letters are what they are because the original word was legally unavailable, and pronouncing the spelling out loud is a small reminder that the language was renamed under duress rather than chosen for elegance. The pronunciation also aligns with the spec, with most of the open-source ecosystem, and with the conventions that the standards bodies have been carrying for forty years. The case for the letters is documented in the documentation itself.

Both pronunciations have a legitimate story behind them. Most of the SQL engineers I have worked with use one or the other without much thought about which, and the conversation between them works regardless of which side either party is on.

A closing observation

I tend to say "S Q L" myself, mostly because that is what the documentation and the standards say. Both pronunciations are in wide use and both are well understood, and the more interesting question is the one underneath the debate — which is why the language ended up with two pronunciations in the first place.

Read next