What is a database, really?
A database is a program whose entire job is to store records safely and find them again fast — even when there are billions of them, even when the power fails mid-write, even when a thousand requests arrive in the same second. Files on disk can hold data; a database holds data and keeps its promises.
The most common shape is the relational database (Postgres, MySQL): data lives in tables, one row per thing — a row per customer, a row per order — with fixed, named columns. The other big family is the document database (MongoDB, DynamoDB): each record is a free-form document, like a JSON file per order, nested and flexible.
Everything in this lesson hangs on one idea: a database is fast when it can jump straight to the rows you asked for, and slow when it has to read everything to find them. The tool that makes jumping possible is the index.
- row / record
- — one stored thing — one order, one customer
- query
- — a question you ask the database ("orders for customer 88")
- index
- — a sorted lookup structure that jumps to matching rows
- full scan
- — reading every row because nothing else can find them
Words to know
The 12-second order history page
SliceNow has grown to 20 million orders. A customer opens "My orders" and the app asks the database: "all orders where customer_id = 88, newest first." The page takes 12 seconds to load. The database is not broken — it is doing exactly what it was asked: reading all 20 million rows, checking each one's customer_id, keeping the 47 that match.
Why? Rows are stored in the order they arrived. Order #17,882,113 from customer 88 sits right next to orders from three strangers. To find every row for one customer, the database has no choice but to look at all of them — a full scan.
Now add an index on customer_id: a sorted side-structure, like a book index, mapping each customer to exactly where their rows live. The same query becomes: jump to "88" in the sorted index (a handful of hops, even among millions), follow the pointers, read 47 rows. 12 seconds becomes 5 milliseconds. Nothing about the data changed — only the way in.
Total orders
20 million
Full scan
~12 sec
Indexed lookup
~5 ms
Quick check
SliceNow's hottest query by far is the driver app asking "all orders where status = 'ready_for_pickup' in zone 4". Which index serves the hot path?
The price of an index
If indexes make reads thousands of times faster, why not index every column? Because every index must be updated on every write. When one new order is inserted, the database writes the row — and then updates the customer_id index, the (status, zone) index, the created_at index… each one a little extra work, on every single insert, forever.
Trace it: with 6 indexes on the orders table, one insert becomes 1 row write + 6 index updates. Your write throughput just dropped several-fold to speed up queries — some of which may never run.
So the craft is: find the 2-3 queries that dominate real traffic (the hot path), index exactly for those, and let rare queries be slow. A slow monthly report is fine. A slow redirect on every click is not.
Tables or documents — when each shines
Both are great databases. The data’s SHAPE and your QUERIES pick the winner.
| Situation | Better fit | Why |
|---|---|---|
| Money, inventory, anything that must balance | Relational (tables) | Transactions: several changes succeed or fail as one |
| Many things referencing each other (orders ↔ customers ↔ drivers) | Relational (tables) | Joins answer cross-questions without duplicating data |
| Self-contained records read whole (a user profile, a game save) | Document | One fetch returns the whole nested thing — no assembly |
| Shape varies per record / changes weekly | Document | No fixed columns to migrate every time fields change |
| Simple key → value at huge scale (code → URL) | Either, keyed right | One indexed lookup — the key design matters more than the family |
Quick check
A teammate adds indexes on ALL 14 columns of the orders table "to make everything fast". What actually happens?
Good to know — Why not just keep it all in memory?
The cache lesson showed memory answering in 1ms — so why bother with disks? Because memory forgets on restart. A database's core promise is durability: once it says "saved", the data survives crashes and power cuts. That is also why the cache and the database are partners, not rivals: the cache serves repeats fast and may forget freely; the database remembers everything and is allowed to be slower.
Match them up
Match each term to its plain meaning.
0/5 matched — tap a term on the left.
Apply it in an interview
The URL shortener lives or dies on ONE query: "what URL does this code point to?" — design the table so that lookup is a single indexed jump, then defend it in the interview.