Loading...
The query for every step and why it works. Most walkthroughs hand you the killer's name, which wastes the puzzle; this one gets you unstuck and leaves the finding to you.
Conor Robertson
August 7, 2026 · 11 min read
The questions that come up most when people get stuck on this one.
QueryCase teaches SQL through mystery cases on real datasets. Music, sports, film, and more. Your first cases are completely free.
Start your first caseFree to start. No credit card required.
There has been a murder in SQL City. You know the date, you know the city, and you have a database of nine tables that nobody has explained to you. That is the whole brief.
The SQL Murder Mystery by Northwestern University's Knight Lab is the best free hour in SQL learning, and it is beloved for a good reason: it drops you into the exact situation every analyst faces on their first day in a new job. An unfamiliar schema, a vague question, and no map.
Most walkthroughs you will find for it do you a disservice. They paste the final query, name the killer, and you close the tab having learned nothing except that somebody on the internet finished a puzzle. Knight Lab's own walkthrough deliberately refuses to name the murderer, and they are right.
So this one is built differently. Every query below has the crucial value left blank. You get the move, the reasoning and the SQL shape. You run it yourself to find out who it points at. Nothing is spoiled unless you choose to open a hint, and if you never open one, the first half of this post is still the most useful thing you can read before you start.
The skill this puzzle actually teaches is not writing SELECT statements. It is walking into a database you have never seen and working out where the bodies are buried.
The instinct when you open an unfamiliar database is to start querying immediately. Resist it for two minutes. The people who solve this quickly are not faster typists, they are the ones who spent the first two minutes working out the shape of the thing.
Three questions are worth answering before you write a single filter, and they apply to every database you will ever be handed.
Here is the whole thing. Click any table to see how you get out of it.
Three details in that map cause almost every stall in the first ten minutes.
crime_scene_report has no keys at all, so you cannot join out of it. The bridge to the rest of the database is a street name buried in the description. Getting from prose to a row is not a trick here, it is the job.
person points out to drivers_license, not the other way round. Written backwards, the join is valid SQL that returns absolutely nothing.
Every date is an integer. 20180115, not '2018-01-15'. Quote it and you are comparing a number to a string, which matches nothing and raises no error.
Seven stages, each with three levels of help. Open only what you need, and stop at the first level that unsticks you. The queries show you the shape and leave the finding to you.
The most demoralising thing in SQL is a query that runs perfectly and returns an empty table. No error, no clue, just nothing. Here are the five ways that happens in this puzzle, and what each one is really telling you.
The habit worth stealing
When a query returns nothing, delete your filters one at a time and rerun. The filter that brings rows back is the one that was wrong. It sounds obvious and almost nobody does it, reaching instead for a rewrite of the whole query. Bisecting a failed filter takes thirty seconds and works every time.
Strip away the murder and look at what you actually did.
That is not puzzle SQL. That is Tuesday afternoon in a data job. The murder is a delivery mechanism for a realistic sequence of analytical moves, which is why the thing has outlasted every "learn SQL in 10 minutes" tutorial published the same year.
It is also why the format works. Nobody abandons a query halfway through when they actually want to know the answer.
The mystery is one puzzle. It ends the moment you solve it, and it was never trying to be a course.
What you will not meet along the way: GROUP BY in anger beyond the final stage, HAVING as a habit rather than a one-off, subqueries and CTEs for structuring anything complicated, window functions for ranking and running totals, or any sense of the order a database actually executes your clauses in. Those are the things that separate someone who can follow a trail from someone who can answer a question nobody has asked yet.
If you enjoyed the format and want the next thing, we wrote an honest comparison of the free SQL games and learning resources worth your time, including several we did not make and one we did. If you want to go straight at the gaps above, JOINs and window functions are the two that unlock the most, in that order.
And if what appealed here was specifically the shape of it, a case, a database, a question worth answering, that is the thing QueryCase is built around. Same instinct, 54 cases deep instead of one.
Credit where it is due
The SQL Murder Mystery was made by Northwestern University Knight Lab, with components from Zi Chong Kao's Select Star SQL and a detective illustration by rambleron. The code is MIT licensed and the content is CC BY-SA 4.0. It is free, it needs no signup, and it is genuinely excellent. Go and play it properly before you read anyone's walkthrough, including this one.