← All modules

SQL0 — SQL Foundations for Data Engineering

Why this module exists

You already know how to write a SELECT. That is not what this module is for.

This module is about the handful of SQL behaviours that produce a plausible number that is wrong, and that survive code review because the query looks fine. Every one of them is also a standard interview question, because interviewers know they separate people who have shipped data pipelines from people who have written queries.

Four of them account for most of the damage:

1. NULL is not a value, and comparing to it doesn't do what it looks like it does.
2. A join can multiply your rows, and SUM will not tell you it happened.
3. COUNT(*) and COUNT(col) are different questions.
4. Redshift accepts a primary key declaration and does not enforce it — and the planner believes you.

The fourth is the one that ends careers quietly, and it's specific to the warehouse this course's QuickSight track sits on top of.

The one idea to hold onto

SQL will not error when it is wrong. It will return a number.

   A COMPILER SAYS          SQL SAYS
   ┌──────────────┐         ┌──────────────────────┐
   │ type error   │         │ 4,182,309.44         │
   │ line 12      │   vs    │                      │
   └──────────────┘         │ (this is wrong, but  │
                            │  nothing will say so)│
                            └──────────────────────┘

Which means correctness in SQL is not something the tooling gives you. It's something you assert, deliberately, with checks you write yourself. That habit is the actual subject of this module.

What you'll be able to do

1. Predict what any expression involving NULL returns, including in IN, NOT IN, joins, and aggregates — and explain three-valued logic out loud.
2. Spot a fan-out join before you run it, and prove whether one happened.
3. Choose between COUNT(*), COUNT(col) and COUNT(DISTINCT col) and justify it.
4. Deduplicate correctly, and write top-N-per-group without a self-join.
5. Name the Redshift/PostgreSQL differences that change results rather than syntax.
6. Answer the standard interview questions on all of the above without hedging.

Lessons

Then: Cheat sheet · Lab · Quiz · Interview questions

Where the examples run

Examples are written in standard SQL and verified against the PostgreSQL documentation, because it is the most precisely-specified widely-available reference and Redshift derives from it.

Lesson 5 is entirely about where that assumption breaks. Amazon is explicit about not making it:

"Do not assume that the semantics of elements that Amazon Redshift and PostgreSQL have in common are identical." — Unsupported PostgreSQL features (verified 2026-08-12)

Where behaviour differs across Redshift, Athena/Trino, and Spark SQL, the lesson says so. Where I could not verify a dialect's behaviour from documentation, the lesson says that instead of guessing.

A dated change this module caught

"Amazon Redshift will no longer support the use of Python UDFs after June 30, 2026. We will start enforcing it in phases." — banner on Unsupported PostgreSQL features, read 2026-08-12

That date has passed. If you have Python UDFs in Redshift, enforcement is in progress now. See the AWS blog post for migration options. Lesson 5 covers what to do about it.

Facts verified 2026-08-12 against the pages cited in each lesson.