Why SQL exists

The problem SQL solved

In the 1960s, data lived in hierarchical and network databases, and getting at it meant writing code that followed pointers from record to record. To find "all orders from customers in Oslo" you had to know how the data was physically linked, and you wrote loops to walk those links. If someone reorganized the storage, your code broke. In 1970 Edgar F. Codd, a mathematician at IBM, published a paper proposing the relational model. His idea was to store data as plain tables and let people ask questions about what they want, not about how to find it. A few years later two IBM colleagues, Don Chamberlin and Ray Boyce, designed a language for asking those questions. They called it SEQUEL, and it was later shortened to SQL (Structured Query Language) because of a trademark conflict. That's why some people say "sequel" and others say "S-Q-L". Both are fine.

Tables, and asking for what you want

A relational database is a collection of tables. Each table has named columns (with types) and any number of rows. In Codd's mathematical terms, a table is a relation, which is where the name "relational" comes from. It doesn't refer to relationships between tables, as many people assume. Here are two small ones, authors and books:

authors

books

And here's your first query:

SELECT title, year
FROM books
WHERE year < 2015
ORDER BY year;

It reads almost like English: give me the title and year from books, only for books published before 2015, sorted by year. Notice what's missing. There's no loop, no index lookup and no file handle. SQL is declarative. You describe the result you want, and the database's query planner works out the fastest way to get it. That's Codd's insight at work, and it's the biggest mental shift for developers who are used to writing step-by-step code.

Why there are several tables instead of one big one

Real data has relationships. Look at the author_id column in books. Instead of writing "N.K. Jemisin" into every one of her books, each book stores the id of a row in authors. If you need to fix a typo in an author's name, you fix it in one place. The same goes for tracking who borrowed which book: a separate loans table points back to a book by its id. When you need data from several tables, you combine them at query time with a join:

SELECT books.title, authors.name
FROM books
JOIN authors ON authors.id = books.author_id;

This lists every book next to the name of its author. Splitting data into tables and joining it back together is the heart of relational databases. It has a name, normalization, and much of becoming good at SQL comes down to getting comfortable with it.

More than reading data

SELECT gets most of the attention, but SQL also covers writing data and defining its structure. INSERT, UPDATE and DELETE change rows. CREATE TABLE defines a table's shape, including rules like "this column can't be empty" or "this must match an existing author id". Those rules matter: the database itself refuses bad data, no matter which app or person tries to write it. On top of that you get aggregation (count(), sum(), avg() with GROUP BY), which turns SQL from a lookup tool into an analysis tool. "How many books per decade?" is a single short query.

The landscape, and where to start

SQL is an ISO standard, but every database speaks its own dialect. PostgreSQL, MySQL, SQLite, SQL Server, Oracle and analytics engines like BigQuery and DuckDB share the same core, but they differ in the details and extras. The core you'll learn first (SELECT, WHERE, JOIN, GROUP BY) works almost the same everywhere, and it has barely changed in 40 years, so it's knowledge that lasts. For learning, SQLite (a whole database in one file, no server) or DuckDB are good places to start, and both can even run in the browser. The natural starting point is the one you've already seen: a single table and a SELECT.