SQL for Data — Ask Your Data Questions

What you'll learn

• Why SQL is a must-have for data scientists
• SELECT, WHERE, GROUP BY, ORDER BY
• Aggregations: COUNT, SUM, AVG
• You'll replicate a GROUP BY query in code

Data usually lives in a database 🗄️

You met SQL in the backend track — for data scientists it's just as essential, because company data almost always lives in SQL databases. Before you can analyze anything in pandas, you often have to pull it with SQL. It's consistently one of the most-requested skills in data job listings.

The analyst's core query pattern:

SELECT   city, AVG(age) AS avg_age, COUNT(*) AS people
FROM     users
WHERE    age >= 18
GROUP BY city
ORDER BY avg_age DESC;

Read it top to bottom like a sentence:

• SELECT — which columns/summaries you want (here: city, average age, count).
• FROM — which table.
• WHERE — filter rows before grouping (adults only).
• GROUP BY — collapse rows into groups (one row per city).
• ORDER BY — sort the result (highest average age first).

The aggregation functions do the summarizing across a group:

• COUNT(*) — how many rows
• SUM(x) — total
• AVG(x) — average
• MIN(x) / MAX(x) — smallest / largest

This one query answers "what's the average age and headcount per city, for adults, ranked?" — the exact kind of question a business asks daily. Notice it's the same filter → group → aggregate → sort loop as pandas. SQL and pandas are two dialects of the same idea; data scientists fluently switch between them.

Combining tables: JOIN 🔗

Real databases split data across many tables to avoid repetition — an orders table doesn't repeat a customer's full name and email on every row; it just stores a customer_id and points to a separate customers table. To answer a real question, you usually need to combine them. That's what JOIN does.

SELECT   orders.id, customers.name, orders.amount
FROM     orders
JOIN     customers ON orders.customer_id = customers.id;

This says: "for every order, look up the matching customer (where the ids line up) and pull their name alongside the order." The most common type is an INNER JOIN (what plain JOIN means by default) — it only keeps rows that have a match in both tables. If an order references a customer_id that doesn't exist in customers, that order is silently dropped from the result.

That's often not what you want. A LEFT JOIN keeps every row from the first (left) table, filling in NULL for any customer fields it couldn't find a match for:

SELECT   orders.id, customers.name
FROM     orders
LEFT JOIN customers ON orders.customer_id = customers.id;
-- every order appears, even ones with a missing/deleted customer

Why this matters for a data scientist: choosing INNER vs LEFT JOIN silently changes how many rows end up in your analysis. Picking the wrong one is one of the most common, hardest-to-notice bugs in a data pipeline — your row count can shrink and nobody notices until a total looks wrong.

Summary

• SQL pulls data from databases; it's essential for data scientists
• SELECT / WHERE / GROUP BY / ORDER BY + aggregations (COUNT/SUM/AVG)
• Same filter→group→aggregate→sort loop as pandas
• You replicated a GROUP BY SUM query

Practice: free interactive SQL at sqlbolt.com and mode.com/sql-tutorial. Next: Data Visualization — turning your query results into charts that tell a story.