A Database Is A Spreadsheet (Mostly)

The most underrated mental model

Almost every introduction to databases starts with vocabulary first. Rows, columns, primary keys, normalization, schemas. By the time the vocabulary is finished, the actual shape of the thing has gotten lost.

The shortest, most accurate way to start: a database looks like a stack of spreadsheets. Not a metaphor for a spreadsheet. Genuinely the same shape, just used differently.

Rows, columns, tables

Inside a spreadsheet, every row is one record and every column is one piece of information about that record. A contacts spreadsheet might have one row per person, with columns for name, email, and phone number.

| id | name        | email                 | phone        |
| -- | ----------- | --------------------- | ------------ |
|  1 | Alex Rivera | alex@example.com      | 555-0100     |
|  2 | Jamie Liu   | jamie@example.com     | 555-0188     |
|  3 | Sam Patel   | sam@example.com       | 555-0142     |

That structure carries directly into a database. The whole thing above is what a database calls a table. Each horizontal line is a row. Each vertical lane (id, name, email, phone) is a column. The vocabulary changes slightly, the picture doesn't.

One table for one kind of thing

A spreadsheet for contacts holds contacts. A spreadsheet for invoices holds invoices. You wouldn't mix the two in a single sheet because it would make the columns meaningless. A row for a contact doesn't have an invoice total. A row for an invoice doesn't have an email.

Databases follow the same rule, more strictly. Each table is for one kind of thing. An app like Opsette will have a table for users, a separate table for organizations, a separate one for appointments, a separate one for messages, and so on. Each table has its own columns describing that one kind of thing.

| id | client_name  | service     | starts_at           |
| -- | ------------ | ----------- | ------------------- |
|  1 | Alex Rivera  | Consultation| 2026-04-22 10:00:00 |
|  2 | Jamie Liu    | Haircut     | 2026-04-22 11:30:00 |
|  3 | Sam Patel    | Consultation| 2026-04-23 09:00:00 |

A database backing a real app is almost never a single table. It's a collection of them. Picturing the whole database means picturing a tab bar across the top of a spreadsheet with twenty tabs on it, each one its own sheet, each one focused on one kind of thing.

Every row needs a way to be pointed at

The id column in those tables isn't decorative. It's the address. Every row in a database table has a unique id (sometimes a number, sometimes a long random string called a UUID), and that id is how code points at that specific row.

When an app says "load the appointment the user just clicked on," what it's really doing is sending the database a request that says give me the row in the appointments table where the id equals 2. The id is the handle. Without it, there'd be no way to refer to one specific row out of millions.

Why the spreadsheet model is the right starting point

There are databases that don't look like spreadsheets at all. Some store data as nested documents. Some store it as plain key-value pairs. Those exist and they have their own uses, which is the last module of this unit.

But the most common kind of database, the one Supabase uses, the one almost every web app uses, the one SQL was built for, is the spreadsheet-shaped kind. It's called a relational database, and that name is going to make a lot more sense in Module 3 when relationships between tables become the focus.

For now, the picture is enough: tables that look like sheets, rows that are records, columns that are fields, and an id on every row so code can find it again. That's the whole shape. The next page is about where this shape stops being just-a-spreadsheet and starts being something a spreadsheet could never do.