Ghost in the SQL Data SQL Query Examples: Practical Detective Queries to Crack Every Case
Learn practical Ghost in the SQL Data SQL query examples for filtering, joining, and aggregating Paris emergency call data to solve every investigation.
Why SQL Query Examples Matter in Ghost in the SQL Data
Ghost in the SQL Data is a detective game where the murder weapon is a SELECT statement. Released on October 29, 2026, by solo developer Isaac Menard, the game drops you into a year of Paris emergency switchboard calls and asks you to find the truth with nothing but SQL. If you have ever stared at a blinking cursor while a school burns down in the case file, you already know why solid Ghost in the SQL Data SQL query examples matter: the game hands you a question, not a tutorial, and expects you to build the answer yourself.
According to the game's official Steam store page, early cases teach the basics while later ones "only give you the question." That design means your query vocabulary becomes your detective toolkit. This guide breaks down the patterns that carry you from the first filtered call log to multi-table joins that expose a caller fourteen minutes before the first witness saw smoke.
The Core Tables You Will Query
Before writing a single line, understand what you are querying. The game centers on Paris emergency call records, and community reports suggest cases revolve around a small set of related tables: call logs, witness statements, location records, and incident reports. Exact table names vary by case, so always inspect the schema first.
| Table Type | What It Typically Holds | Why It Matters |
|---|---|---|
| Call log | Timestamps, caller ID, call reason | Establishes the timeline |
| Witness statements | Observed time, location, description | Cross-checks the call log |
| Location records | Addresses, arrondissements, landmarks | Places events in Paris |
| Incident reports | Official time, category, outcome | Confirms or contradicts calls |
A quick discovery query is your first move in almost every case. Run something like SELECT * FROM call_log LIMIT 10; to see column names, then SELECT COUNT(*) FROM call_log; to gauge scale. Player experience consistently shows that spending two minutes mapping the schema saves twenty minutes of guesswork later.
Filtering and Sorting: Your First Detective Moves
Most cases begin with a time window. The flagship scenario — a call reporting a school fire fourteen minutes before the first witness saw it — is a pure WHERE and ORDER BY problem. You need rows that fall before a known timestamp, sorted so the earliest appears first.
SELECT call_time, caller_id, reason
FROM call_log
WHERE call_time < '2026-03-14 08:42:00'
ORDER BY call_time ASC;
This is the backbone of Ghost in the SQL Data SQL query examples you will reuse constantly. Swap the literal timestamp for a subquery that pulls the witness's observation time, and the query becomes self-adjusting across cases.
| Filter Pattern | Example Use | Keyword |
|---|---|---|
| Date range | Calls on a specific day | BETWEEN |
| Text match | Reason contains "fire" | LIKE '%fire%' |
| Exclusion | Ignore test or duplicate calls | NOT IN |
| Null check | Unnamed caller or missing address | IS NULL |
The unnamed metro ticket case is a classic IS NULL puzzle. When a field is blank, = NULL returns nothing — you must use IS NULL. That single distinction trips up many new investigators, according to community reports.
Joining Tables to Connect Clues
Single-table queries solve warm-ups. Real cases demand joins. When a call log references a location_id and the address lives in another table, you link them with JOIN. This is where Ghost in the SQL Data SQL query examples graduate from filtering to actual deduction.
SELECT c.call_time, c.reason, l.address, l.arrondissement
FROM call_log c
JOIN locations l ON c.location_id = l.location_id
WHERE l.arrondissement = '5e'
ORDER BY c.call_time;
A LEFT JOIN is your safety net when you suspect missing data — for instance, calls with no matching location record may themselves be suspicious. The Musée d'Orsay crown theft case rewards investigators who notice records that fail to join cleanly.
| Join Type | Returns | Detective Use |
|---|---|---|
INNER JOIN | Only matched rows | Confirming known links |
LEFT JOIN | All left rows plus matches | Finding orphaned or missing data |
SELF JOIN | Table joined to itself | Spotting repeat callers |
Aggregation and Grouping for Pattern Hunting
Sometimes the answer is not a single row but a pattern. GROUP BY with aggregate functions turns a year of calls into a suspect profile. Counting calls per caller, averaging response gaps, or tallying incidents by arrondissement all rely on the same structure.
SELECT caller_id, COUNT(*) AS call_count
FROM call_log
GROUP BY caller_id
HAVING COUNT(*) > 3
ORDER BY call_count DESC;
The HAVING clause filters groups after aggregation — think of it as WHERE for summaries. In the school fire case, grouping by caller and filtering for high counts can surface a serial prankster or a coordinated set of calls. Community players report that HAVING is the most underused clause among beginners, and mastering it unlocks several mid-game cases.
| Aggregate | Question It Answers | Case Fit |
|---|---|---|
COUNT | How many calls? | Repeat callers |
AVG | Average gap between events? | Timeline anomalies |
MIN / MAX | Earliest and latest activity? | First-mover suspects |
SUM | Total duration or quantity? | Call length patterns |
Subqueries and CTEs for Multi-Step Reasoning
Late-game cases chain logic: find the witness time, then find calls before it, then match those callers to a location. Nested subqueries handle this, but common table expressions (CTEs) keep it readable. Ghost in the SQL Data SQL query examples that use WITH clauses read like an investigation outline.
WITH witness_time AS (
SELECT observed_time FROM witness_statements WHERE case_id = 1
)
SELECT call_time, caller_id
FROM call_log
WHERE call_time < (SELECT observed_time FROM witness_time)
ORDER BY call_time DESC
LIMIT 5;
This structure mirrors how detectives think: establish a fact, then query against it. The investigator's board — where you pin results, charts, and notes — pairs naturally with CTEs, because each step becomes a discrete, pinnable result.
Practical Tips for Cleaner Queries
Beyond syntax, habits separate smooth investigations from frustrating ones. These tips reflect both the game's structure and general SQL best practice.
- Always inspect the schema first. Column names differ between cases; guessing wastes time.
- Start broad, then narrow. A
SELECT *with aLIMITreveals data shape before you filter. - Comment your queries. Later cases revisit earlier logic, and notes on the investigator's board help.
- Test timestamps carefully. Off-by-one-minute errors can hide the crucial call.
- Use the level editor. The game includes a level editor and Steam Workshop support, so you can build your own SQL puzzles and practice patterns.
The game also ships with 38 Steam achievements, several of which reward efficient or clever querying rather than brute force, according to the store listing. That incentivizes learning the elegant patterns above instead of scrolling through raw tables.
Frequently Asked Questions
Do I need prior SQL experience to use these Ghost in the SQL Data SQL query examples? No. The game's first cases teach the basics, and the patterns here — filtering, joining, grouping — are exactly what those tutorials introduce. Beginners can follow along case by case.
What is the most important query pattern to learn first?
Filtering with WHERE and sorting with ORDER BY. Nearly every case starts with a time window, and the flagship school fire scenario is built entirely on that foundation.
Why does my = NULL check return nothing?
SQL treats NULL as unknown, so equality never matches. Use IS NULL or IS NOT NULL instead. This trips up many players on the unnamed metro ticket case.
Can I practice outside the main cases? Yes. Ghost in the SQL Data includes a level editor and Steam Workshop integration, letting you create custom SQL puzzles or download community-made ones to sharpen your skills.
For the latest updates, patch notes, and community levels, check the official Ghost in the SQL Data Steam page. Whether you are chasing a phantom caller or a stolen crown, the query patterns above turn raw Paris call data into a confession — one SELECT at a time.
Related Guides
Ghost in the SQL Data SQL Commands: A Practical Guide to Solving Cases
Master Ghost in the SQL Data SQL commands with this practical guide to SELECT, WHERE, JOIN, and GROUP BY for cracking every Paris case.
Ghost in the SQL Data SQL JOIN Guide: Connect Evidence Across Tables
Master JOIN queries in Ghost in the SQL Data with a practical SQL JOIN guide covering keys, aliases, join types, and real case examples.
Ghost in the SQL Data SQL ORDER BY Solution: Sort Query Results Like a Real Detective
Master the Ghost in the SQL Data SQL ORDER BY solution to sort call logs, rank suspects, and crack every Paris case faster with clean, reliable queries.
Ghost in the SQL Data SQL Query Errors: Fix Common Mistakes Fast
Stuck on Ghost in the SQL Data SQL query errors? Learn why quotes, dates, operators, and JOINs break your investigation and how to fix each one.