Portmint Lighthouse

A Spreadsheet Is Already a Database

You already know more about databases than you think. If you have ever kept a list in a spreadsheet — customers, recipes, the books on your shelf — you have already built a small database. The word just sounds fancier than the thing.

So let me take the mystery out of it. A database is an organized place to keep information so you can find it again. That is the whole idea. Spreadsheets and databases are cousins. They were raised in the same house, and they keep their information the same patient way: one thing per row, one fact per column.

The shape you already use

Picture a guest list. Each guest gets their own line — that is a row. Across the top you have headings: name, email, table number. Each heading is a column, and each column holds one kind of fact.

That tidy grid is the shared family trait. A row is a single thing you care about (one guest). A column is a single fact about it (their email). Where the row and column cross, you get one clean value. Databases keep this exact discipline, just with far more rows than a spreadsheet likes to carry and stricter rules about what is allowed in each box.

Think of it like a lighthouse logbook. Every entry is one night (a row). Every column is one detail of that night — the weather, the ships sighted, the hours the lamp burned. You would never cram three nights onto one line, and you would never mix the weather into the ship-count column. That steadiness is what makes a logbook trustworthy years later. It is what makes a database trustworthy too.

Where the spreadsheet starts to strain

Spreadsheets are wonderful, right up until they are not. As your list grows, three particular aches show up — and naming them now matters, because every later lesson in this course is really an answer to one of them.

Size. A spreadsheet stays cheerful with a few hundred rows. Ask it to hold a few million, with people scrolling at once, and it gets slow and heavy — like a logbook grown so thick you cannot lift it to find last March.

Sharing. When two people open the same sheet and both start typing, whose version wins? Spreadsheets get nervous about a crowd. Real businesses have a crowd all day long, all reaching for the same information.

Copied facts. This is the quiet one. Say every order row also writes out the customer's full address. The same address, typed again and again. When that customer moves, you must hunt down every copy and fix each one — and the ones you miss are now simply wrong. A fact stored in many places is a fact that can disagree with itself.

A database is the tool built to carry that same simple idea — one thing per row, one fact per column — without buckling under size, without panicking at a crowd, and without forcing you to copy the same fact a hundred times. 🔦

Your turn

Open any spreadsheet you keep, or just picture one. Answer three quick questions:

  1. What is one row — the single kind of thing each line stands for?
  2. What is one column — a single fact you record about that thing?
  3. Find one fact that gets repeated down the sheet (a name, an address, a category typed over and over). That repetition is the strain a later lesson is named after.

If you can point at all three, you are already reading the grid the way a database reads it.

Next, we slow down and look closely at those three pieces — tables, rows, and columns — and the rules that keep each box honest.

Stuck or curious?

Ask Pip about this lesson — tap the porthole bottom-right.