Where The Spreadsheet Analogy Breaks

Same shape, very different job

The spreadsheet model is the right starting point, but it stops describing the whole truth pretty quickly. A spreadsheet is built for one person (or a small team) to open, look at, and edit by hand. A database is built for code to read and write to thousands of times a second, on behalf of every user of the app at once.

Same picture, completely different demands. The places the spreadsheet model breaks down are the places the actual character of a database starts to show.

It's not meant to be looked at

A spreadsheet is a visual tool. The whole point is that you can open it and see the rows. The grid layout matters because a human is reading it.

A database isn't visual on its own. The data lives in files on a server in a format optimized for code to read fast, not for a human to scan. When you open the table view in Supabase's dashboard and see a grid of rows and columns, that grid is a real view of the data, but Supabase is the one building it for you. The dashboard asked the database for the rows and laid them out in a grid because that's the easiest shape for a human to look at. Code asking the database for those same rows gets them back as a list of values, not a grid. The shape depends on who's asking.

It's built for scale a sheet would collapse under

A Google Sheet starts feeling slow around tens of thousands of rows. It chokes well before a million. A real database table is comfortable with hundreds of millions of rows, and the speed of finding one specific row barely changes whether the table has a thousand rows or fifty million.

That speed comes from a behind-the-scenes feature called indexes. An index is an internal lookup map the database builds for certain columns, so when code asks for "the user with id 14,283," the database doesn't scan every row. It jumps directly to the right one. A spreadsheet has nothing like that. Search a sheet for a name and it really is reading every cell.

Many people writing to it at the same time

Open a Google Sheet with three people editing the same cell at the same time and the experience is awkward at best. Most desktop spreadsheets don't even allow it.

A database is built for the opposite. Every user of an app might be reading and writing rows in the same tables simultaneously. The database has rules (transactions, locks, constraints) that make sure two people booking the same appointment slot don't both succeed, that a half-finished write never leaves the data in a broken state, and that one user's edit doesn't quietly overwrite another's.

That kind of coordination is invisible when it works, which is most of the time. It only shows up as a feature when you picture a spreadsheet being asked to do the same job and failing at it.

It enforces what the data can look like

A spreadsheet lets anyone type anything anywhere. A column meant for phone numbers will happily accept the word "purple" if someone types it in. Spreadsheets don't push back.

A database does. When a table is created, each column is given a type (text, number, date, boolean, and so on) and the database refuses values that don't match. A column declared as a number can't be assigned the word "purple." This isn't decorative. It's what stops bad data from quietly entering the system and causing bugs months later that nobody can trace.

This is the same instinct as TypeScript from Unit 1, just applied to the data layer instead of the code layer. Types defined on the database are the data layer's safety net, the way TypeScript is the code layer's safety net.

Try it: pick a table name, add a few columns with their types, and watch the CREATE TABLE statement assemble itself. This is the SQL the database would actually run to bring a typed table into existence.

What the spreadsheet model is still good for

The spreadsheet model never stops being useful for picturing the shape of data: tables, rows, columns, ids. When opening a new app's database for the first time and trying to understand what it stores, treating each table like a sheet is genuinely the right move.

What changes is the awareness that underneath the sheet-shaped picture is a machine built to handle scale, concurrency, and integrity in ways no spreadsheet ever was. The shape is familiar. The job is not.