- SELECT
- FROM
- LIMIT
Your First SQL Query 🗄️
Scene: your first morning as a summer analyst. Your desk lead drops a database login on your screen and says: "Everything we trade is in here — two years of daily prices for Apple, Microsoft, JPMorgan, Goldman, and the S&P 500. Pull me a quick look at the price table so we know the data actually loaded." No Excel, no Python yet — just you and the database. To talk to it, you need exactly one sentence of SQL. By the end of this lesson you will have written it.
SQL (Structured Query Language) is how you talk to a database. Every data analyst, quant, and risk manager uses it daily — it is older than Excel, older than Python, and still irreplaceable.
🧠 The mental model: SQL is ordering at a restaurant
A database is a kitchen full of ingredients (tables full of rows). You do not walk into the kitchen and rummage — you hand the waiter an order, and the kitchen brings back exactly what you asked for. A SQL query is that order, and it has two essential parts:
| You say to the waiter… | In SQL | Meaning |
|---|---|---|
| "I'll have the everything platter" | SELECT * | which columns to bring (* = all of them) |
| "…from the prices menu" | FROM equity_prices | which table to read from |
| "just a small portion to start" | LIMIT 5 | cap how many rows come back |
Get the table wrong and the kitchen cheerfully brings you the wrong dish — no error, just the wrong data. Choosing the right table is the whole job of the FROM clause, and it is what you will fill in below.
📜 Why finance runs on SQL
1970 — Edgar F. Codd (IBM Research) published "A Relational Model of Data for Large Shared Data Banks", one of the most influential papers in computing. He proposed storing data in tables (relations) and querying it with a logic-based language. He won the Turing Award in 1981 for it.
1974 — IBM's Donald Chamberlin and Raymond Boyce built SEQUEL, the human-readable version of Codd's algebra, later renamed SQL. The first commercial engine was Oracle v2 in 1979 — the same era Merrill Lynch was already clearing hundreds of thousands of trades a day.
Financial data is perfectly relational: a trade is one row with keys (security, trader, desk, timestamp, price, quantity); price history is one row per (ticker, date); a risk report joins positions × prices × exposures. Today JPMorgan runs billions of SQL queries a day, and Goldman's quants write SQL before Python because the raw history lives in relational stores (Snowflake, Teradata) that only SQL can unlock.
The simplest possible query
SQLSELECT * FROM table_name;
- ›SELECT — choose which columns to show (
*means "all columns") - ›FROM — which table to read from
- ›; — marks the end of the query
Tables can hold millions of rows, so LIMIT grabs just a preview:
SQLSELECT * FROM equity_prices LIMIT 5;
Our database
You have three tables to work with:
| Table | What's inside |
|---|---|
| equity_prices | daily open/high/low/close/volume for AAPL, MSFT, JPM, GS, SPY |
| macro_indicators | CPI and Fed Funds rate releases |
| trade_ledger | 200 simulated trades |
Your Task
Your desk lead wants a preview of the price table. The query below is written for you — except for the one word that matters most: which table to read from. Fill in the FROM clause with the table that holds equity prices, then run it.
Predict before you run: the placeholder currently reads from macro_indicators. Glance at the table above — will the result show a column called ticker and rows for AAPL? Or something else entirely? Run it as-is first to see the "wrong dish", then fix the FROM clause and watch AAPL appear.