Introduction to SQL

What is a relational database?

A relational database stores data in tables (also called *relations*). Each table has:

• Columns — named fields with a type (e.g. id INT, email TEXT).
• Rows — individual records.
• A primary key — one or more columns that uniquely identify a row.

Tables can reference each other via foreign keys, letting you split data across logical units without duplication.

users                    posts
-----                    -----
id  
name
email      id
user_id
 
title
1   
Ada
a@x        1
1
 
Hello
2   
Linus
l@y        2
1
 
World
                         3  
2
Hi
posts.user_id is a foreign key pointing at users.id. SQL is the language you use to ask questions across these tables.
What is SQL?
SQL is declarative — you say *what* you want, not *how* to get it:
SELECT name FROM users WHERE id = 1;
The database engine figures out the most efficient way to find that row (often using an index). You never write loops over rows yourself.
SQL has four sub-languages:
Sub
Stands for
Examples

DQL
Data Query
SELECT
DML
Data Manipulation
INSERT, UPDATE, DELETE
DDL
Data Definition
CREATE, ALTER, DROP
DCL/TCL
Control / Transaction
GRANT, REVOKE, BEGIN, COMMIT
You'll spend 90% of your time on DQL + DML.
SQL dialects
The SQL standard (ISO/IEC 9075) defines the core. Each database adds extensions and breaks small things:
Engine
Strengths
Quirks

PostgreSQL
Closest to standard, rich types (JSONB, arrays), powerful window/CTEs
Server install needed
MySQL / MariaDB
Ubiquitous in web apps
Looser standards compliance, weak CTEs in older versions
SQLite
Zero setup — a single file
Few types, no real ALTER COLUMN
SQL Server (T-SQL)
Strong tooling, common in enterprise
Vendor-specific syntax (TOP, [brackets])
BigQuery / Snowflake
Massive analytics
No row-level updates / different cost model
Learn standard SQL first — the differences are easy to look up later.
Try it in 60 seconds — SQLite
The fastest way to play is SQLite, which is just a file:
# macOS / Linux usually ship with sqlite3 already
sqlite3 demo.db
Then in the prompt:
CREATE TABLE users (
  id   INTEGER PRIMARY KEY,
  name TEXT NOT NULL,
  age  INTEGER
);
INSERT INTO users (name, age) VALUES
  ('Ada', 36),
  ('Linus', 54),
  ('Grace', 85);
SELECT name, age FROM users WHERE age > 40 ORDER BY age;
Output:
Linus|54
Grace|85
That's a complete, working SQL workflow — schema, data, query — in five lines.
Online sandboxes
If installing anything is too much friction:
[db-fiddle.com](https://www.db-fiddle.com/) — Postgres / MySQL / SQLite in your browser.
[sqlite.org/fiddle](https://sqlite.org/fiddle/) — official SQLite WASM playground.
[bit.io / Neon](https://neon.tech/) — free hosted Postgres.

Anatomy of a SELECT
Every query you'll write is a variation of this:
SELECT   columns          -- what to show
FROM     table            -- from where
WHERE    condition        -- which rows
GROUP BY columns          -- bucket the rows
HAVING   condition        -- filter the buckets
ORDER BY columns          -- sort
LIMIT    n;               -- cap rows
You write them in this order, but the database executes them roughly in the order:
FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY → LIMIT.
That mental model explains a lot of "why doesn't my alias work in WHERE?" mysteries later.
Conventions you'll see
UPPERCASE for keywords, lowercase for identifiers — SELECT name FROM users. Optional but standard.
Snake_case for column names — first_name, created_at.
Singular OR plural table names — pick one and stick with it.
End every statement with ; — required by some clients.
Comments — -- single-line and /* multi-line */.

What's next
In Phase 1 you'll get fluent at SELECT, WHERE, sorting and pagination. After that: joins (Phase 2), schema design (Phase 3), then window functions, CTEs and transactions (Phase 4). Sixteen topics, and you'll be writing the kind of SQL companies hire for.