Databases — where the data lives

When you close Instagram and reopen it tomorrow, your posts are still there. Your followers are still there. Every comment anyone has ever left is still there. The app didn’t keep them — the app on your phone could be reinstalled when you switched devices, and they’d still be there.

So something else is keeping them. That something is a database.

A database is a program whose only job is to store data in an organized way and answer questions about it.

It’s not a magic vault. It’s not a giant spreadsheet. It’s a program — running on a server somewhere — that two things keep happening to: stuff gets put in, and stuff gets pulled out.

The thing that trips people up

People picture a database as a passive storage box, like a filing cabinet. It’s the opposite.

A database is a question-answer machine. You don’t browse it; you ask it.

When the backend wants to know “what posts did user 42 publish in March?” — it doesn’t go scrolling through files. It sends a query (a specific question), and the database scans through millions of rows and hands back the answer in milliseconds.

That’s the whole value. Storage is easy. Fast, organized question-answering is the hard part, and it’s what databases do.

What’s actually in there

The most common kind of database — a relational database — stores data in tables. Like spreadsheets, with rows and columns, but a lot bigger and a lot faster.

A tiny example, for a fictional app:

users table:
| id | name        | email             |
| 1  | Sam Carter  | sam@example.com   |
| 2  | Lin Park    | lin@example.com   |

posts table:
| id | user_id | text              | created_at  |
| 1  | 1       | Hello world       | 2026-01-01  |
| 2  | 2       | My first post     | 2026-01-02  |
| 3  | 1       | Second one        | 2026-01-03  |

When the backend wants Sam’s posts, it queries: “give me every row in posts where user_id is 1.” The database scans the posts table, returns rows 1 and 3, hands them back to the backend, which hands them to the frontend, which shows them on your screen.

Multiply by a billion users and you have the basic shape of Instagram.

The names you’ll see

You don’t need to choose a database, but you’ll hear the names. The common ones:

Postgres (also written PostgreSQL) — open source, popular, the default for many new projects.
MySQL — the other big open-source relational database, slightly older.
SQLite — a tiny database that lives in a single file, often used in apps that don’t need a server.
MongoDB — a different style (“NoSQL”), stores data more like JSON than spreadsheets.
Redis — a fast in-memory database, often used for caching.

When Claude tells you “this project uses Postgres,” you now know: there’s a database server somewhere, storing data in tables, and the backend is asking it questions.

What’s next

We’ve covered what software is, how it’s split, how the halves talk, and where the data lives. Now: where does the code itself live, while it’s being written? That’s a codebase — also called a repo.