Ghost in the SQL Data Paris Metro Case Walkthrough: Solve the Commuter Mystery
Stuck on the Paris metro case in Ghost in the SQL Data? This walkthrough breaks down the query logic, table joins, and clue-chaining you need to close the file.
Why the Paris Metro Case Trips Up New Investigators
The Paris metro case in Ghost in the SQL Data is where a lot of players first hit a wall. The premise is simple — a suspicious incident on the Paris transit network, a pile of call logs, and a database that holds the answer — but the query path is anything but obvious. If you've been staring at the same table for twenty minutes wondering which column actually matters, you're not alone. Community reports on the Steam forums show this case is one of the most frequently discussed sticking points, right alongside the Hospital Stalker and Paris Bank Robbery scenarios.
This Ghost in the SQL Data Paris metro case walkthrough is built to fix that. We'll walk through the investigative mindset the game expects, the SQL patterns that actually work in its limited query engine, and the specific traps that send players down dead ends. By the end, you'll have a repeatable process you can apply to every case in the game — not just this one.
One quick note before we start: the game uses a stripped-down SQL dialect. Player experience confirms functions like DATEPART, DATEDIFF, and EXTRACT are unavailable, so date and time filtering has to be handled with string functions like SUBSTR or SUBSTRING instead. Keep that in mind for everything below.
Understanding the Case Structure Before You Query
Every case in Ghost in the SQL Data follows the same skeleton: a briefing gives you a narrative hook, the database gives you raw evidence, and the game checks whether your final answer matches the truth. The Paris metro case is no different, but it layers in transit-specific data — station names, line numbers, timestamps, and passenger or call records — which makes the table relationships more important than the individual rows.
What the Briefing Actually Tells You
Read the briefing twice. The narrative text is not flavor — it's a specification. It tells you:
- The incident window — the rough time range you need to filter on
- The location constraint — which station or line is relevant
- The suspect or witness profile — the attributes you'll need to match
Players who skip straight to the query editor and start guessing tend to waste the most time. The game rarely requires more than a handful of WHERE clauses to reach the solution, according to community reviews, so precision beats volume every time.
Mapping Tables to Clues
Before writing a single line, list out every table the case exposes and what each one is for. A rough mapping looks like this:
| Table Type | What It Holds | How You'll Use It |
|---|---|---|
| Incident / call log | Timestamps, reported events, locations | Narrow the time window first |
| Transit records | Station names, line IDs, entries/exits | Filter to the relevant station or line |
| Person records | Names, roles, identifying attributes | Match the suspect or witness profile |
| Cross-reference table | Links between the above | Join to connect evidence |
If you can't explain in one sentence why a table exists, you probably don't need it yet. The Paris metro case rewards narrowing, not joining everything at once.
The Walkthrough: Step-by-Step Query Logic
Here's the sequence that works for this case in Ghost in the SQL Data. Treat it as a framework rather than a copy-paste script — the game checks your reasoning, and understanding each step matters more than memorizing syntax.
Step 1: Isolate the Time Window
Start by pulling every record that falls inside the incident window from the briefing. Because date functions are limited, you'll likely filter using string comparison on a formatted timestamp column, or SUBSTR to extract the hour portion.
| Approach | Works in Game? | Notes |
|---|---|---|
WHERE time_column BETWEEN 'A' AND 'B' | Usually yes | Best if timestamps are stored in a sortable format |
WHERE SUBSTR(time_column, 1, 5) = 'HH:MM' | Yes | Player-tested workaround for missing date functions |
WHERE EXTRACT(HOUR FROM ...) | No | Not supported in the game's engine |
WHERE DATEPART(...) | No | Not supported |
The key insight: filter first, join later. A common complaint from players is that the game implicitly orders JOIN before WHERE, which can produce confusing intermediate results if you build a massive join on unfiltered data.
Step 2: Filter to the Station or Line
Once you have the time-narrowed set, add the location constraint. This is where the metro-specific tables earn their place. Match the station name exactly as it appears in the database — typos and partial matches are the number one cause of empty result sets in this case.
- Check spelling against the table, not the briefing
- Use
LIKE '%station%'if you're unsure of the exact stored format - Confirm the line number if the case mentions one
Step 3: Join the Person Records
Now bring in the people. This is the step where the Paris metro case walkthrough diverges from other cases — you're not looking for a single obvious name, you're looking for a profile match. Expect multiple candidates and expect to eliminate them one at a time.
| Filter Stage | Typical Result Count | Purpose |
|---|---|---|
| Time window only | Dozens of rows | Establish the incident scope |
| + Station/line | A handful of rows | Narrow to the location |
| + Person profile | 1–3 candidates | Identify the suspect |
| + Final cross-check | 1 row | Confirm the answer |
Community reports note that some cases (like the Hospital Stalker) produce multiple plausible matches, and players have questioned whether the intended answer is always the most logical one. The Paris metro case is generally cleaner, but you should still verify your final row against the briefing details before submitting.
Step 4: Cross-Check and Submit
Before you lock in your answer, run one final query that confirms your suspect appears in every relevant table. If your candidate is missing from the transit records but present in the call log, you've probably matched the wrong row.
Common Mistakes That Stall the Investigation
Most players who get stuck on this case in Ghost in the SQL Data make one of a few predictable errors. Here's the shortlist, based on player experience and forum discussion:
| Mistake | Symptom | Fix |
|---|---|---|
| Joining before filtering | Huge result sets, slow reasoning | Apply WHERE conditions to each table first |
| Using unsupported date functions | Query errors, no results | Switch to SUBSTR/SUBSTRING |
Over-filtering with AND | Zero rows returned | Remove one condition at a time to find the culprit |
| Ignoring the briefing's time range | Wrong suspect identified | Re-read the case text for the exact window |
| Assuming the first match is correct | Game rejects the answer | Verify the candidate across all tables |
The "over-filtering" trap deserves special attention. New players often stack five WHERE conditions at once, get zero rows, and assume the data is broken. In reality, one condition is usually slightly wrong — a different station spelling, a time off by an hour, or a name format mismatch. Build your query incrementally and check row counts at each stage.
How This Case Fits the Wider Game
The Paris metro case is a mid-game scenario, and it assumes you've internalized the basics from the tutorial and the first few cases. Reviews of Ghost in the SQL Data consistently describe the SQL difficulty as "extremely basic" — one reviewer noted they finished half the game in under an hour using little more than WHERE clauses. That's useful context: if you're struggling here, the problem is almost certainly query structure, not advanced syntax.
| Case | Core Skill Tested | Difficulty (Player Consensus) |
|---|---|---|
| Tutorial cases | Basic SELECT and filtering | Very easy |
| Hospital Stalker | Multi-step elimination, SUBSTRING | Moderate |
| Paris Bank Robbery | Pattern recognition across records | Moderate, with ambiguity complaints |
| Paris Metro | Time/location filtering plus joins | Moderate |
| Later cases | Combined logic, longer chains | Harder for beginners |
The game is also Workshop-supported, and community scenarios are already appearing. That means the skills you build in the Paris metro case — incremental filtering, careful joins, cross-table verification — will carry directly into player-made content. If you want to see what the community is building, the official Ghost in the SQL Data Steam page is the best place to start.
Tips for Faster Solving Across All Cases
A few habits will cut your solve time on every case, not just this one:
- Write your hypothesis down before querying. "The suspect entered the station between 07:00 and 08:00" is a testable claim; "let me look around" is not.
- Check row counts obsessively. A jump from 3 rows to 300 means your join is multiplying records.
- Use the game's error hints. The game provides syntax feedback, and beginners report it's genuinely helpful for learning.
- Don't fear empty results. Zero rows is information — it tells you one of your assumptions is wrong.
- Re-read the briefing after every failed answer. The clue you missed is usually in plain sight.
If you're brand new to SQL, the W3Schools SQL tutorial is a solid free reference for the syntax patterns the game uses, and it covers the string functions that substitute for the missing date functions here.
FAQ: Ghost in the SQL Data Paris Metro Case
Why can't I use EXTRACT or DATEDIFF in the Paris metro case?
The game's SQL engine doesn't support those functions. Community reports confirm that DATEPART, DATEDIFF, and EXTRACT all fail, and players work around it with SUBSTR or SUBSTRING on formatted timestamp strings. Build your time filters around string comparison instead.
How many queries should the Paris metro case take? Most players solve it in three to five queries if they filter incrementally. If you're past ten queries, you're probably joining too early or missing a briefing constraint. Step back, re-read the case text, and rebuild from the time filter.
I found multiple matching people — which one is correct? Cross-check each candidate against every relevant table. The correct answer appears in all of them, while decoys typically appear in only one. This Ghost in the SQL Data Paris metro case walkthrough recommends verifying the final row before submitting, since the game will reject a plausible-but-wrong suspect.
Is the Paris metro case harder than the Hospital Stalker? Player consensus puts them at similar difficulty, but for different reasons. The Hospital Stalker requires multi-step elimination and has drawn complaints about ambiguous clues, while the Paris metro case is more about clean filtering and joins. If you've solved one, the other should feel familiar.
Do I need advanced SQL knowledge for this case?
No. Reviews consistently describe the required SQL as basic — mostly SELECT, WHERE, JOIN, and simple string functions. The challenge is investigative logic, not syntax. Focus on narrowing your data step by step and the queries will stay short.
Final Thoughts
The Paris metro case is a filtering puzzle dressed up as a crime scene. Once you stop trying to query everything at once and start narrowing — time window first, location second, person profile third — the solution falls out quickly. This Ghost in the SQL Data Paris metro case walkthrough gives you the framework; the practice is yours.
Keep your queries small, verify every join, and remember that the game's limited SQL dialect is a feature, not a bug. The constraints force you to think like an investigator rather than a database administrator — and that's exactly what Ghost in the SQL Data is designed to teach.