SQL (Structured Query Language)

What is SQL?

SQL, short for Structured Query Language, is the standard language for reading and writing data in a relational database, one that stores its data in tables of rows and columns. Almost every system built on tables speaks it, from the database behind an invoicing app to the data warehouse behind a company's reports.

It has been around a long time. IBM researchers Donald Chamberlin and Raymond Boyce designed the language in the mid-1970s to put Edgar Codd's relational model into practice. They first called it SEQUEL, but that name was already trademarked, so the vowels were dropped and it became SQL. Fifty years on, it is still the common tongue of data work.

What makes SQL worth learning is not its age but the way you write it: you describe the answer you want, and the database decides how to produce it.

You describe the result, not the steps

SQL is a declarative language. In an imperative language like Python or C#, you spell out each step: open the table, loop over the rows, keep a running total, skip the ones you do not want. In SQL you state the shape of the result and leave the procedure to the database.

Take a plain request: give me the total sales per customer for 2025.

SELECT customer, SUM(amount) AS total
FROM sales
WHERE year = 2025
GROUP BY customer;

Nothing in that query says which index to use, whether to scan the whole table or seek into it, or in what order to read the rows. A part of the engine called the query optimizer decides all of that. It weighs the available indexes and table sizes, picks a strategy, and writes it down as an execution plan, the concrete recipe the database follows. The same query can run two different ways on two different days if the data underneath it changes.

That is the trade: you give up fine control over the procedure and get a short, readable request plus an engine that is usually better than you at finding the fast path.

The four things SQL statements do

People talk about SQL as one language, but its statements fall into four jobs. You rarely need the labels in daily work, though they explain why a permission or a rollback behaves the way it does.

Reading and changing data. This is the part most people mean by SQL. SELECT reads rows, INSERT adds them, UPDATE changes them, and DELETE removes them. A single order in a web shop can fire an INSERT and several UPDATEs behind the scenes. This constant read-and-write traffic is the OLTP side of the OLTP and OLAP distinction.

Defining structure. CREATE, ALTER and DROP statements set up the tables, columns, data types and constraints that data has to fit. This is where you decide that an order date must be a real date and a customer number must be unique. Getting that structure right leans on database normalisation, the practice of splitting data across tables so each fact lives in one place.

Controlling access. GRANT and REVOKE decide who is allowed to read or change what. A reporting account, for example, usually needs to read data and nothing more.

Managing transactions. COMMIT and ROLLBACK draw a boundary around a group of changes so they all succeed together or all fail together, the all-or-nothing promise behind ACID transactions. If a payment debits one account but the credit fails, a rollback undoes the whole thing. How strictly the database keeps concurrent transactions apart is its own topic, transaction isolation, and reusable blocks of this logic are often packaged as a stored procedure.

The order a query really runs in

SQL reads like an English sentence, top to bottom, starting with SELECT. The database does not run it that way. It evaluates the clauses in a fixed logical order that begins with FROM, and SELECT is almost the last step.

For a typical query the logical order is FROM and any JOIN first, then WHERE, then GROUP BY, then HAVING, then SELECT, and finally ORDER BY. Microsoft documents this same binding order for SQL Server, and other engines follow the same standard.

This order is not trivia. It explains a rule that trips up almost everyone at some point. Look again at the query above, where SELECT gives the sum an alias, total. Because WHERE runs before SELECT, that alias does not exist yet when WHERE is evaluated. Write WHERE total > 1000 and the database rejects it. To keep only the bigger customers you filter the aggregate in HAVING, which runs after grouping, and even there the standard wants the full expression, HAVING SUM(amount) > 1000, not the alias. ORDER BY is the one clause that runs after SELECT, so ORDER BY total DESC works fine. The same alias is invisible to one clause and available to another, purely because of when each clause runs.

The same evaluation model is what lets richer features slot in cleanly. A window function runs at the SELECT stage and can look across nearby rows without collapsing them into one, and a common table expression lets you name a query and build the next one on top of it. Both ride on the same fixed order.

NULL means unknown, not empty

SQL has a special marker, NULL, for a value that is missing or not yet known. It is not zero and not an empty string. It is the absence of a value, and it pulls a third truth value into the language. Alongside true and false, an SQL comparison can also come back unknown.

Any comparison with NULL returns unknown. In PostgreSQL's own words, 7 = NULL yields neither true nor false but null, because it is not known whether an unknown value equals seven. Even NULL = NULL is unknown, since two unknown things cannot be shown to be equal.

This changes how filters behave. A row survives a WHERE clause only when the condition is true, and unknown is not true, so the row is dropped. Suppose a status column is NULL for some invoices:

SELECT count(*) FROM invoices WHERE status <> 'paid';

That count leaves out every invoice whose status is NULL, because NULL <> 'paid' is unknown rather than true. To include them you have to say so, with WHERE status <> 'paid' OR status IS NULL. Testing for the marker itself always uses IS NULL and IS NOT NULL, never = NULL, which is always unknown and matches nothing.

One standard, many dialects

SQL is a genuine standard. It became an ANSI standard in 1986 and an international ISO standard the year after, and it is still maintained today as ISO/IEC 9075. The current edition is SQL:2023, which added a native JSON data type and a way to query property graphs.

The standard fixes the core, but every vendor extends it and the edges diverge. The clearest example is asking for the first few rows of a result. The standard way, introduced in SQL:2008, is FETCH FIRST 10 ROWS ONLY. PostgreSQL and MySQL instead use LIMIT 10, and Microsoft's T-SQL uses SELECT TOP (10). All three do the same job with different words. Date functions, string functions and the syntax for stored logic vary in the same way, so a query rarely moves between engines untouched.

That is why people talk about dialects: T-SQL in SQL Server, Azure SQL and the warehouse endpoints of Microsoft Fabric; PostgreSQL, which stays close to the standard; and the SQL that MySQL speaks. The reassuring part is that the core, SELECT with joins and GROUP BY, is the same everywhere, so learning one dialect gets you most of the way into all of them.

SQL beyond classic databases

SQL long ago outgrew the transactional database. A data warehouse is queried in SQL by default, and often stores precomputed results as a materialized view so dashboards stay fast. A lakehouse, which keeps its data in open files, gets a SQL layer bolted on top; in Microsoft Fabric every lakehouse comes with a read-only SQL endpoint over its tables. BI tools lean on it too, and Power BI in DirectQuery mode turns each click in a report into live SQL against the source.

The newest turn is letting an AI write the query. NL2SQL tools, including Copilot in Fabric, turn a plain-language question into SQL for you. That saves real time on joins across many tables, but it moves the work from writing to checking. A generated query often looks right and runs without error while quietly double-counting rows or filtering too wide. You still need to read SQL well enough to catch that before the numbers reach a decision.