Start from zero: what a database actually is
A database is durable, queryable, structured storage — the memory your app writes to that survives restarts. This is the from-zero map and the eight words every senior unit assumes you already know.
Your app writes a user to memory: const user = { id: 1, name: "Alice" }. Then you restart the server and Alice is gone. You add a file — now Alice survives restarts but you cannot search by name without reading every byte. You add a second file for orders and quickly lose track of which order belongs to which user. Every app that handles real data hits the same three walls: data disappears, searching is slow, and links between things break. A database exists to knock down all three walls at once — durably, fast, and correctly — so you can think about your product instead of your storage plumbing.
The one problem a database solves
When a program stores data only in memory, it vanishes the moment the process ends. When it stores data in flat files, searching means reading everything, and linking two files (users and orders) requires custom code that breaks whenever the format changes. A database solves both problems in one move: it writes data to disk in a structured way and keeps a description of that structure — so any program that speaks the same language (SQL — Structured Query Language) can find, combine, and change data without knowing how the bytes are physically arranged.
When you hit a slow page in production and wonder where to look first, you will almost always end up staring at a database — which means understanding its building blocks is not optional.
That single idea — structured, durable, queryable storage — is what all of the senior units build on. Everything else is optimisation or tradeoff on top.
The eight words the rest of the track assumes
When you hit a unit on MVCC, index internals, or transaction isolation, none of those lessons pause to define the basics — they assume you already carry them. Here they are, one sentence each — what it is and why it exists.
| Word | What it is | Why it exists |
|---|---|---|
| Table | A named grid of rows and columns, all with the same shape. | So data of the same kind lives together and can be searched as a unit. |
| Row & column | A row is one record (one user, one order); a column is one attribute of every record (name, created_at). | So each fact has a fixed home — you always know where to look. |
| Primary key | A column (or set of columns) whose value is unique for every row in the table. | So you can always name a specific row without ambiguity — the database’s version of a unique ID. |
| Foreign key | A column that holds the primary key of a row in a different table. | So two tables can be linked — and the database can refuse to create an order for a user that does not exist. |
| SQL / query | A language of sentences (SELECT, INSERT, UPDATE, DELETE) you send to the database to read or change data. | So any program can talk to the database without knowing how data is stored on disk. |
| Index | A separate data structure (usually a B-tree) the database maintains alongside a table. | So finding rows by a column value takes milliseconds instead of reading the entire table. |
| Transaction | A group of changes that either all succeed together or all fail together. | So a crash mid-operation cannot leave data half-updated — the money leaves one account only if it arrives in the other. |
| Schema | The blueprint that defines what tables exist, what columns they have, and what constraints apply. | So the database can reject bad data before it is stored, not after it has caused a bug. |
How they fit together
Read in order, the words tell one story: data lives in tables made of rows and columns; a primary key gives each row a unique name; a foreign key in one table points to the primary key of another, linking them; you ask for data with SQL (a query); an index makes that query fast by letting the database jump straight to the right rows instead of scanning all of them; a transaction wraps a multi-step change so it is all-or-nothing; and the schema declares the rules that hold the whole structure together. That single paragraph is the entire databases track in miniature — every later unit zooms into one of those ideas.
▸Why this works
Why not just use JSON files on disk, like the old days? Because files have no schema, no query language, no indexes, and no transactions. The moment two users write at the same time you get corruption; the moment the data grows past a few megabytes you scan every byte to find one record; the moment you link two files by hand you get orphaned references. Databases exist to solve all four problems — structure, speed, concurrency, and correctness — as a unit, rather than leaving each one for application code to patch.
You do not need to memorise this
Two honest notes before the climb. First: nobody internalises all eight words on day one — you will meet each one again in its own unit with real queries and real failure stories, and it will stick then. This page is a coat-hook for the details, not a test. Second: not every app needs all eight features equally. A tiny read-heavy service might run without a single transaction. The senior track teaches the full picture because production systems demand it — but “understand the tool, reach for it when the pain shows up” is the senior instinct.
What three problems does a database solve that flat files on disk cannot?
Order the journey from raw data to a correct, fast query result:
- 1 Schema defines the tables, columns, and constraints the database will enforce
- 2 Rows are inserted; primary and foreign keys link them across tables
- 3 An index is built so the database can jump to the right rows quickly
- 4 A SQL query arrives; the database returns the correct result in milliseconds
- 01In one breath, what problem does a database solve, and what is the core technique?
- 02Trace the path from a blank database to a correct query result, naming each piece.
A database is one idea with a lot of machinery hung off it: keep data alive in a structured form that any program can query and change safely, long after the process that wrote it has exited. The structure half is a schema — a blueprint of tables, rows, columns, and constraints — that lets the database reject bad data before it is stored. The query half is SQL, a language that works regardless of how bytes are arranged on disk. The link half is keys: a primary key gives each row a unique name; a foreign key in one table points to the primary key of another, and the database refuses to create dangling references. The speed half is an index — a B-tree shortcut that turns full-table scans into millisecond lookups. The correctness half is a transaction: a group of changes that is all-or-nothing, so crashes cannot leave data half-updated. You do not need to hold all eight words at once — each gets its own unit ahead. Next: Unit 01, the relational model — tables, keys, constraints, and when to bend the rules. Now when you encounter a term like “foreign key constraint” or “index scan” in an error log or a code review, you will know exactly which building block is speaking and where to look next.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.
Apply this
Put this lesson to work on a real build.