SQL Practice Problems

SQL Practice Problems

SQL practice problems with 10-seed replay and a live database editor for data engineer interview prep.

929 SQL practice problems that push back the way an interviewer does. Every query you write runs against a real database and replays across 10 randomized seeds, so the shortcut that only worked on the sample data comes apart here instead of on the call. Schema panel pinned to the editor. EXPLAIN on every problem. Per-problem scratchpad. No signup to start.

The SQL practice surface here is one browser tab, one editor, one live database behind a submit button. The catalog is 929 problems pulled from data engineer interview write-ups. Every submitted query is replayed against 10 different seeded versions of the schema. A query that hard-codes IDs, relies on insert order, or omits an ORDER BY tiebreaker fails the same way a senior data engineer would catch it in code review. A typical broken query clears 6 or 7 of 10 seeds and comes back with specific diffs naming the bug.

4 editor interactions dominate submission analytics. The schema panel pins next to the editor with table names, column types, primary keys, and three sample rows per table. Autocomplete pulls from the same source so orders.cust_id completes before the data engineer has scrolled the schema. The EXPLAIN button on every problem shows the query plan with row counts, cost estimates, and the chosen join algorithm after a passing submission. Plans for your query and the reference solution sit side by side for the optimization-round comparison. 2 output modes toggle with Command-D: row-by-row diff against expected, or full sortable table for inspecting intermediate state. Per-problem scratchpads stay separate from the submission so a data engineer can stage exploratory SELECTs against the seed data before writing the final answer.

The 10-seed engine engineers three failure modes per seed: ties at the top of a ranking, NULL distributions across nullable columns, and cardinality skew on join keys. A common wrong answer to "return the customer with the highest lifetime order total" uses ORDER BY SUM(amount) DESC LIMIT 1. The query passes one fixture and fails every seed where two customers tie at the top, returning "Alice" on seed_3 and "Aliyah" on seed_7. The submission log returns "expected [Alice, Aliyah], got [Aliyah]" with the seed number. The replay-safe version uses a top_total CTE plus an INNER JOIN on ties, takes 3 more lines, and survives every seed.

Catalog topic distribution. JOINs are 168 problems (20%). Aggregation 142 (17%). Window functions 124 (15%). CTEs 96 (11%, with overlap into other topics). Subqueries 88 (10%). String and NULL handling 94 (11%). Date and time 78 (9%). Gap-and-island 64 (8%). Each topic has Easy, Medium, and Hard tiers with explicit difficulty calibration. The data engineer who finishes the Easy and Medium tiers in each topic typically reaches phone-screen fluency at around 60 to 80 total problems solved.

5 bugs the 10-seed replay catches that single-fixture SQL trainers let through. A hard-coded value: the query references a specific customer_id or order_id observed in the sample data, passes one seed, and fails the other nine. LIMIT without ORDER BY: SQL does not guarantee row order without an ORDER BY, so LIMIT 1 picks a different row on each seed. An INNER JOIN that should be LEFT: it drops rows where the right side has no match, works on the seed where every customer has an order, and fails the seed where some do not. COUNT(col) versus COUNT(*): different answers when col is nullable, easy to write, hard to spot, and an interviewer's favorite trap. A window function without a tiebreaker: ROW_NUMBER OVER (ORDER BY ts DESC) is non-deterministic when two rows share the same ts, fixed by adding an event_id DESC tiebreaker. What the replay costs you in practice: a query has to clear all 10 randomized seeds before it counts, the first run comes back in under 800ms and reruns land under 200ms, and roughly 85% of the catalog ports unchanged into Snowflake, BigQuery, Redshift, and MySQL.

Do I need to install Postgres to use these SQL practice problems?
No. The editor runs in the browser and your query executes server-side against a real database. Nothing to install, no local setup, and any recent browser works.
Why does every SQL submission replay across 10 seeds instead of 1?
Against a single fixture, a query can return the expected rows by coincidence. Hard-coded identifiers survive. So does LIMIT 1 with no ORDER BY tiebreaker, a LEFT JOIN that should have been INNER, and a Cartesian blowup from a many-to-many bridge. Replaying the same query across 10 seeds with engineered ties, NULL distributions, and cardinality skew strips out the coincidence and leaves the logic. It is the habit a senior data engineer already has: asking what happens to NULLs, and what happens when two rows tie.
Can I run ad-hoc SELECTs against the seed data before submitting?
Yes. Every problem has a scratchpad that hits the same seed data your submission will. Query the tables, check how NULLs are distributed, and confirm the join cardinality before you commit to an approach. Scratch queries are unlimited and separate from your submission, and submissions are unlimited too.
How do I see the query plan after a SQL submission passes?
Every problem has an EXPLAIN button that returns the plan with row counts, cost estimates, and the join algorithm the optimizer picked. You can put your plan next to the reference solution's and compare the two strategies directly, which is the exact move the 'why is this slow' question calls for in L5-and-above optimization rounds.
Are these SQL practice problems free?
Yes. 929 problems. No daily cap. No signup gate to read or submit. Account is optional and only saves progress across devices.
What is the topic distribution of the SQL practice catalog?
JOINs are 20% (168 problems), aggregation 17% (142), window functions 15% (124), CTEs 11% (96), string and NULL 11% (94), subqueries 10% (88), date and time 9% (78), gap-and-island 8% (64). Each topic has Easy, Medium, and Hard tiers.
How is this different from sql-practice.com or SQLZoo?
Those run SQLite or MySQL in 5.7 mode and check your query against a single fixture, so a coincidence passes. Here the same query replays across 10 seeds, which is what separates working logic from a lucky result. sql-practice.com gives you no EXPLAIN view and SQLZoo gives you no pinned schema panel. Hard-tier problems and most company tags are free here; LeetCode and HackerRank put both behind Premium.
Can I practice SQL online without installing anything?
Yes. No IDE, no Docker, no database to seed, nothing local at all. You practice SQL online in a browser tab, your query runs against a managed database, and results come back in under a second. An account is optional and only carries your progress between devices.

929 practice problems matching this filter. Difficulty: medium (434), hard (147), easy (348).

SQL (929)