Ghost in the SQL Data: How to Find Clues and Crack Every Case

Why Finding Clues Is the Whole Game

In Ghost in the SQL Data, you don't chase suspects down alleys or dust for fingerprints. You sit at a terminal, type queries, and let a year of Paris emergency call records reveal the truth. If you're wondering how to find clues in Ghost in the SQL Data, the short answer is this: every clue lives in a table, and your job is to ask the right question. Learning how to find clues in Ghost in the SQL Data efficiently is the difference between staring at a blank query window and pinning a suspect to your board within minutes.

This guide breaks down the actual workflow — reading the case brief, exploring the schema, filtering rows, joining tables, and connecting evidence on the investigator's board. It's built for players who know a little SQL, and for total beginners who just want to solve a mystery.

Understanding the Core Loop: Question, Query, Clue

The game's structure is refreshingly simple. Each case gives you a question, a database, and a board. The first cases hand you step-by-step instructions. Later cases give you only the question and let you figure out the rest.

According to the official Ghost in the SQL Data Steam store page, the opening case asks you to find who called the Paris Emergency Switchboard 14 minutes before the first witness saw a school on fire. That single question contains everything you need: a time window, a location, and a target event.

The trap most new players fall into is jumping straight to a query before they understand what tables exist. Spend two minutes exploring the schema first. It saves twenty minutes of guessing.

Step 1: Read the Case Brief Like a Detective

Before you type a single keyword, extract the hard facts from the case text. Every brief hides at least one anchor value — a timestamp, a street name, a ticket number, or an object description.

Take the school fire example. The anchor is "14 minutes before the first witness saw it." That means you need to find the witness report, get its timestamp, subtract 14 minutes, and search the call log around that window.

Actionable tips for this stage:

• Highlight numbers. Times, dates, and counts are almost always filter values.
• Note proper nouns. Paris districts, museum names, and metro lines become WHERE conditions.
• Write the question in plain English first. "Who called about a fire near this school between 14:00 and 15:00?" Then translate it into SQL.
• Check for red herrings. Later cases include details that look important but never appear in the database.

Community reports suggest the later cases deliberately omit the "how" and only give the "what." That's intentional design, not a bug — the game wants you to build the query yourself.

Step 2: Explore the Tables Before You Filter

You cannot find clues in data you haven't looked at. The explore phase is where most successful players spend their first few minutes.

Start with a broad look at each table. Preview a handful of rows to see what a record actually looks like — column names in a schema view rarely tell the full story. A column called code might hold a dispatch category, while type might hold a caller relationship.

One practical habit: keep a scratch note of every column name that looks like a join key. Columns ending in _id or sharing a name across two tables are your bridges. In Ghost in the SQL Data, joining tables is not optional — the store description explicitly says you'll "filter it and join the tables."

Handling Messy Values

Real emergency data is messy, and the game leans into that. Location names may be abbreviated, caller names may be missing, and timestamps may sit in different formats across tables.

• Use pattern matching for partial names instead of exact equality.
• Normalize dates mentally before comparing across tables.
• When a join returns nothing, check value formats before assuming the data is absent.

Step 3: Filter Smart, Not Wide

Broad queries return hundreds of rows and teach you nothing. Narrow queries return five rows and hand you the clue.

The school fire case is a perfect illustration. If you search the entire year of calls for "fire," you'll drown in results. If you search for fire calls within a tight time window near the right district, you'll get a handful of records — and one of them will be your 14-minutes-early caller.

A useful technique is progressive narrowing. Run a query with one condition, note how many rows come back, then add a second condition and compare. If the count barely drops, that condition isn't doing useful work. If it collapses to a few rows, you've found a discriminating filter.

Players who ask how to find clues in Ghost in the SQL Data often overlook this: the goal isn't the most clever query, it's the smallest useful result set.

Step 4: Join Tables to Connect the Dots

Single-table queries give you facts. Joins give you stories. The moment you connect a call record to a caller record to a location record, a narrative appears.

Think of it as three layers:

1. Event layer — the call itself: time, category, location reference.
2. Person layer — who reported it, contact details, prior history.
3. Place layer — the address, district, and any linked incidents.

Watch for duplicate rows after a join. If one caller has multiple records in a second table, your result set multiplies. Aggregating or filtering after the join keeps the output readable.

The game's later cases — a nameless metro ticket, a crown stolen from the Musée d'Orsay — are built entirely around these connections. The clue isn't in any single table. It's in the relationship between two.

Step 5: Use the Investigator's Board to Lock In Clues

The investigator's board is where raw query results become a case. You pin results, charts, and notes, then draw connections between them.

This is the step players skip, and it's the step that matters most for complex cases. The board is essentially your external memory. When a case spans multiple tables and a dozen candidate records, the board shows you which threads you've pulled and which remain loose.

Practical board habits:

• Pin early. The moment a query returns something interesting, pin it. You can always unpin later.
• Label your notes. A pinned chart without a note is just decoration.
• Draw connections only when you can justify them. A line between two pins should represent a real data link, not a hunch.
• Revisit the board before submitting. Loose pins often reveal the missing piece.

If you're stuck on a case, the board usually tells you why. Nine times out of ten, an unconnected pin is the clue you haven't followed up on.

Common Mistakes That Hide Clues

Even experienced SQL users stumble in this game. Here are the recurring pitfalls, drawn from community reports and general query habits.

One more: don't be afraid to run a deliberately wrong query. Seeing what the data isn't often tells you what it is. Exploration is cheap; assumptions are expensive.

A Quick Reference for Query Building

If you're new to SQL, keep this mental checklist beside you. It maps each investigative intent to a query concept.

The game's early cases teach these one at a time. By the later cases, you're expected to chain them without prompting. That progression is why the tutorial cases feel slow — they're building a toolkit you'll use constantly.

FAQ

How do I find clues in Ghost in the SQL Data if I don't know SQL? Start with the tutorial cases, which walk you through each query concept step by step. Read the brief, explore the tables, and filter one condition at a time. The game is designed to teach as you play, so you don't need prior database experience.

What's the fastest way to find clues in Ghost in the SQL Data? Extract the anchor fact from the brief — usually a time, place, or object — then filter the most relevant table down to a small result set before joining anything. Narrow first, connect second.

Why does my query return no results? Usually it's a value format mismatch. Check how the data actually stores dates, names, and codes by previewing rows, then adjust your filter to match. Loosen one condition at a time until results appear.

Do I need the investigator's board to solve cases? For early cases, no. For later ones, effectively yes. The board tracks which clues you've pinned and connected, and it's the clearest signal of what you've missed when a case stalls.

Final Thoughts

Finding clues in Ghost in the SQL Data isn't about memorizing syntax — it's about disciplined investigation. Read the brief for anchors, explore the schema before filtering, narrow aggressively, join to build a story, and use the board to hold it all together. Do those five things in order and no case in Paris will stay unsolved for long.