What skills does SQL cover?
From reading a single table to reasoning about query performance
SQL (Structured Query Language) is how you read from and write to a relational database. Almost every backend, data, or analytics role expects it — whether you're calling it from an ORM, writing reports directly against a warehouse, or tuning a slow query in production.
The core split is between Data Definition Language (DDL), which shapes the schema — tables, constraints, indexes — and Data Manipulation Language (DML), which reads and writes the rows inside it. Most day-to-day work lives in DML: SELECT statements, joins, aggregates, and subqueries.
Once the basics are solid, the ceiling is high: window functions, common table expressions, recursive queries, and query optimization are what separate someone who can write a query from someone who can write a query that scales.
The SQL Roadmap
Work through these in order — each step builds on the one before it
Learn the Basics
What a relational database is, and the syntax every query is built from.
Data Definition Language (DDL)
Shape the schema itself — creating, changing, and removing tables.
Data Manipulation Language (DML)
Reading and writing rows — the part of SQL you'll use every day.
Aggregate Queries
Collapse many rows into a summary — totals, averages, and counts.
Data Constraints
Rules that keep bad data out of the table in the first place.
JOIN Queries
Combine rows across tables — the core skill for querying real schemas.
Subqueries
A query nested inside another — useful once a single SELECT isn't enough.
Advanced Functions
Built-in functions for numbers, strings, conditionals, and dates.
Views & Indexes
Saved queries for reuse, and structures that make lookups fast.
Transactions & Data Integrity
Keep changes atomic and consistent, and control who can touch what.
Performance Optimization
Make queries fast at scale, not just correct on a small table.
Advanced SQL
The patterns that show up in interviews and in serious analytics work.
GitHub Projects
Real, buildable projects to put on your own GitHub
Design & Query a Schema
Spin up PostgreSQL locally, design a normalized schema for a small app, and write the DDL, constraints, and CRUD queries by hand before reaching for an ORM.
Query Practice Set
Work through a structured set of exercises covering joins, aggregation, and subqueries against a shared sample database — a solid rehearsal for interview-style SQL.
Analytics on a Sample Dataset
Load a ready-made sample database and write reporting queries against it — window functions, CTEs, and pivoted summaries make good targets.
Roles & Access Control
Set up multiple database roles on a test instance, practise GRANT / REVOKE, and explore how permissions and views can be combined to limit what each role can see.
Frequently Asked Questions
Common questions from people starting out with SQL
Is SQL easy to learn?
The basics — SELECT, WHERE, simple joins — are approachable within a few days, since the syntax reads close to plain English. What takes longer is developing intuition for joins across many tables, subqueries, and writing queries that stay fast as data grows.
Do I need to learn SQL if I already use an ORM?
Yes. ORMs are convenient for common cases, but debugging slow queries, writing complex reports, or reasoning about an execution plan all require reading and writing raw SQL directly.
What's the difference between SQL and NoSQL?
SQL databases store data in structured tables with fixed schemas and enforce relationships between them; NoSQL databases like MongoDB favor flexible, often document-based structures. SQL tends to win on complex queries and data integrity, NoSQL on horizontal scaling and schema flexibility.
What's the difference between WHERE and HAVING?
WHERE filters individual rows before any grouping happens; HAVING filters groups after a GROUP BY and aggregate functions have been applied. A common mistake is trying to filter on an aggregate like COUNT() with WHERE — that has to go in HAVING instead.
Which JOIN should I use?
Use INNER JOIN when you only want rows that match in both tables, LEFT JOIN when you want every row from the first table regardless of a match, and FULL OUTER JOIN when you want unmatched rows from either side. Self and cross joins are for narrower, less common cases.
How do I prepare for a SQL interview?
Be comfortable writing joins and aggregates from memory, understand subqueries versus CTEs, practise window functions like ROW_NUMBER and RANK, and be ready to explain how you'd optimize a slow query — indexes, execution plans, and reducing unnecessary subqueries are common talking points.
Track complete
From a single SELECT to window functions and query tuning — that's the range most database-facing roles expect. Keep practising against real schemas, and let the direction you're headed (backend, analytics, or database administration) guide which parts you go deeper on.
Where next?
Keep exploring by domain or drill into a single skill