Why do so many apps still talk to their databases in a 1970s language?

The full story

The episode's narration, word for word. Numbers link to the sources below; timestamps play that moment.

The question 0:00

Your banking app, your phone's contacts, the shop that just took your order: behind a great many apps is a database, and very often the app talks to it in a language called SQL ^1,2. SQL grew out of an idea published in 1970 ^3,4. New programming languages arrive every few years. So why do so many apps still talk to their databases in a language from the 1970s?

Check the premise 0:28

In Stack Overflow's 2025 survey, 58.6 percent of the people who answered that question had done serious work in SQL in the past year, more than had used Python ². The four databases they used most, PostgreSQL, MySQL, SQLite and Microsoft SQL Server, all speak SQL ². SQLite alone is in every Android phone and every iPhone, and, by its makers' own estimate, it is used more than all other database engines combined ¹.

What a database is 1:05

First, some words. A database is an organised store of data that programs can ask questions of. The program that keeps it and answers is the database engine ⁵. Your app doesn't reach in and rummage around; it sends a question, written as a line of SQL, and gets back rows of answers ^5,6.

Before 1970: navigating 1:27

It wasn't always like that. In the 1960s, data was stored as records physically linked or nested together, and getting at it took real expertise ⁷. Specialists often wrote a whole program just to fetch one piece of information, following link after link through the data ⁷. Charles Bachman, a pioneer of those linked databases, embraced the idea: his 1973 Turing Award lecture was titled "The programmer as navigator" ⁸.

Codd's promise 2:00

Edgar Codd, known as Ted, was an Oxford-educated mathematician who had flown for the RAF in the Second World War ^7,9. At IBM's research lab in San Jose, California, he published a paper in June 1970 with a bold first sentence ^3,7. It said that future users of large databases must be protected from having to know how the data is organised inside the machine ³.

Tables, rows, values 2:27

His idea was to keep data in tables, which he called relations ³. Each row is one fact, and the order of the rows doesn't matter ³. Here are two tiny tables we made for this episode: employees, and which floor each department is on. Nothing links them with hidden pointers ⁷. The employees table just says "TOY", and so does the floors table: the connection is a matching value ⁷.

SEQUEL 2:55

In 1973, two IBM researchers, Donald Chamberlin and Raymond Boyce, moved to San Jose and joined a project to build Codd's idea for real, called System R ^7,10. In 1974 they published a language for asking questions of tables, called SEQUEL, a Structured English Query Language ⁴. Their paper described a shift in computing, from procedural to declarative ⁴. Boyce never saw what it became: he died suddenly that same year ¹¹.

A 1974 query, run today 3:31

Here's the first SEQUEL example in that 1974 paper, word for word ⁴. Select the names, from the employees table, where the department is toys ⁴. We ran it, unchanged, in SQLite on a laptop in 2026, on our little table. Back came two names, Ana and Chen. A question written fifty-two years ago still runs as written.

What, not how 3:59

That's what declarative means ⁵. In the Python from episode nine, you'd write the steps: go through every row, check the department, print the name. In SQL you only describe the answer you want ⁵. SQLite's own documentation puts it this way: you tell the system what you want, not how to compute it ⁵. Choosing the how is the job of a part of the engine called the query planner ⁵.

Planners and joins 4:27

For one query, there can be thousands, even millions, of ways to get the answer, and the planner tries to pick a fast one ⁵. In System R, Patricia Selinger built a planner that estimated what different ways would cost, and picked a cheap one ⁷. It matters most when you combine tables. This query joins employees to floors by their matching department, and asks who works on floor two ³. You never say which table to read first; the planner decides ⁵.

The index 5:00

So how does a database find one row among millions, fast? Without help, it reads every row and checks each one, which SQLite calls a full table scan ⁵. The fix is an index, and the back of a book is the classic comparison ¹². Instead of reading every page, you look the word up in a sorted list, which points you to the right page ¹².

An index, run 5:26

We built a table of a million customers and asked SQLite how it would find one by name. Its answer was to scan the whole table. Then we added an index, and asked again, with exactly the same query. This time SQLite said it would search using the index. A sorted list of a million names can be halved down to one in at most twenty steps, instead of up to a million checks ⁵. The analogy breaks in one place: every time the data changes, the database has to update the index too, so indexes slow down writing ¹².

The name and the standard 6:05

SEQUEL didn't keep its name ¹³. Chamberlin remembered a British aircraft maker, Hawker Siddeley, saying it owned the trademark, and he thinks he was the one who took out the vowels, leaving S Q L ^13,14. IBM built products on it, but a small company that later became Oracle was among the first to sell it, in 1979; one engineer there later put it as "IBM invented the language, but Oracle shipped it first" ^15,14. Then it became a shared standard: American in October 1986, international in June 1987 ^16,17. The standard is still being revised; its latest edition came out in June 2023 ¹⁸.

Why it lasted 6:53

That's much of the answer to our question. Because SQL says what you want and not how, databases could get faster underneath for decades without anyone rewriting their questions ^5,12. Because it became a standard, a skill learned on one database mostly carries to another. To be fair, almost no database follows the standard exactly, and each has its own dialect ¹⁴.

Code meets data 7:20

But there's a catch, and it's one of the most dangerous security mistakes in software ¹⁹. It happens when an app takes what you typed, like your name, and glues it straight into the text of its SQL ²⁰. Then the database can't tell your input apart from the app's own instructions ²⁰. That mistake is called SQL injection, and it has been understood for decades ^21,20.

A harmless demonstration 7:45

Here's the mistake, made harmlessly, in an empty database that only exists in memory. Our name is O'Brien, with an apostrophe. In SQL, an apostrophe marks where a piece of text ends ²². So the O becomes the name, and Brien spills out as if it were part of the command ²⁰. The database reports a syntax error. Here that's all it is, but if the leftover text had been valid instructions, the database would have run them ²⁰.

Bobby Tables 8:18

In 2007, the web comic xkcd imagined a school ringing a mother whose son's name contained database instructions ²³. The school had lost that year's student records, and she called him Little Bobby Tables ²³. It's funny because it's real. In MITRE's 2025 list of the most dangerous software weaknesses, SQL injection ranked second ¹⁹. In March 2024, America's cyber-security agency and the FBI warned that companies were still shipping this flaw, two decades after it was well understood ²¹.

The fix: keep data as data 8:56

The fix has been known for decades, and it's simple ^24,21. You write the SQL with a placeholder, a question mark, and hand the name over separately ^6,24. This is called a parameterised query ²⁴. The database reads the command first, then treats whatever fills the placeholder purely as data ^24,21. We ran it, and O'Brien went in and came back out, apostrophe and all. Like a name box on a form: whatever you write in it is read as a name, never as an instruction. The analogy has a limit: placeholders work for values, not for the names of tables or columns ²⁴.

NoSQL, fairly 9:39

So has anything replaced it? In the 2000s, Google and Amazon hit scales where they chose other designs ^25,26. Google's Bigtable was built for petabytes of data across thousands of servers ²⁶. Amazon's Dynamo kept shopping carts always available, and, by its own paper, gave up some consistency when things failed ²⁵. In 2009, databases like these got a name, NoSQL, often read as "not only SQL" ²⁷. They're a trade-off chosen for a job, not a wholesale replacement: Redis and MongoDB are widely used, often alongside SQL databases ^2,27.

So why? 10:24

So why do so many apps still talk in a 1970s language? Because Codd's idea let programs ask for data without knowing where it sits, and SQL turned that into plain questions ^3,4. The engines kept getting smarter underneath, and the same questions kept working ⁵. Just keep the data apart from the code ²¹. All season we've been writing code, and next we look at where people write it. What does an IDE actually do?

Sources

Every factual claim in the episode is tied to one of these. Spotted an error? Tell us.

1. SQLite, "Most Widely Deployed and Used Database Engine" (updated 21 April 2026) — sqlite.org
2. Stack Overflow Developer Survey 2025, Technology — survey.stackoverflow.co
3. E. F. Codd, "A Relational Model of Data for Large Shared Data Banks", Communications… — seas.upenn.edu
4. Donald D. Chamberlin and Raymond F. Boyce, "SEQUEL: A Structured English Query… — s3.us.cloud-object-storage.appdomain.cloud
5. SQLite, "Query Planning" — sqlite.org
6. Python 3 documentation, "sqlite3: DB-API 2.0 interface for SQLite databases" — docs.python.org
7. IBM, "The relational database" (IBM History) — ibm.com
8. Charles W. Bachman, "The programmer as navigator" (1973 ACM Turing Award lecture),… — web.archive.org
9. Wikipedia, "Edgar F. Codd" (accessed 7 October 2026) — en.wikipedia.org
10. Paul McJones (ed.), "The 1995 SQL Reunion", section "Prehistory" — mcjones.org
11. Paul McJones (ed.), "The 1995 SQL Reunion", section "Ray Boyce" — mcjones.org
12. PostgreSQL documentation, "Indexes: Introduction" — postgresql.org
13. Paul McJones (ed.), "The 1995 SQL Reunion: People, Projects, and Politics", SRC… — mcjones.org
14. Wikipedia, "SQL" (accessed 7 October 2026) — en.wikipedia.org
15. Paul McJones (ed.), "The 1995 SQL Reunion", section "Oracle" — mcjones.org
16. American National Standards Institute, ANSI X3.135-1986, "Database Language SQL",… — nvlpubs.nist.gov
17. ISO, "ISO 9075:1987 Information processing systems: Database language — SQL"… — web.archive.org
18. ISO, "ISO/IEC 9075-1:2023 Information technology: Database languages SQL — Part 1:… — web.archive.org
19. MITRE, "2025 CWE Top 25 Most Dangerous Software Weaknesses" (page updated 15 December… — cwe.mitre.org
20. MITRE, "CWE-89: Improper Neutralization of Special Elements used in an SQL Command… — cwe.mitre.org
21. CISA and FBI, "Secure by Design Alert: Eliminating SQL Injection Vulnerabilities in… — cisa.gov
22. SQLite, "SQL Language Expressions" — sqlite.org
23. Randall Munroe, xkcd #327, "Exploits of a Mom", 10 October 2007 — xkcd.com
24. OWASP Cheat Sheet Series, "SQL Injection Prevention Cheat Sheet" — cheatsheetseries.owasp.org
25. Giuseppe DeCandia et al., "Dynamo: Amazon's Highly Available Key-value Store", SOSP 2007 — allthingsdistributed.com
26. Fay Chang et al., "Bigtable: A Distributed Storage System for Structured Data", OSDI 2006 — static.googleusercontent.com
27. Wikipedia, "NoSQL" (accessed 7 October 2026) — en.wikipedia.org

Researched and scripted with AI assistance, fact-checked claim by claim, with synthetic narration and diagrams drawn in code. How we make episodes.