Why it needs a database and not just a file

Your first program that had to remember something probably wrote to a file. Open the file, read what is in it, change it, write it back. It works, it is obvious, and you can look at the result in a text editor.

So the honest question, before accepting the box on the whiteboard: what exactly goes wrong with the file?

The answer is not "files are for beginners". It is one specific thing, it happens the moment two people use your program at the same time, and once you have seen it you will recognise it for the rest of your career.

Predict

Your program keeps a counter in a file: read the number, add one, write it back. Two requests arrive at the same instant and both run that code. What is in the file afterwards?

Choose one answer

The counter has gone up by two, because both requests ranThe counter has gone up by one — both read the same starting valueThe file is corrupted and the program crashesThe operating system prevents the second write

Lock in answer

The three things a database does that a file does not

All three are about the same underlying problem from different angles: more than one thing is happening at once, and some of those things are allowed to fail. A file assumes a tidy world with one writer who never gets interrupted. A database assumes the world you actually have.

Rows, tables, and the one query worth knowing today

A database holds tables. A table has columns — the fields, fixed for every entry — and rows, one per thing. A users table has a column for the email and a row per person.

You ask it questions in a language called SQL, and the shape of the question is always the same: which columns, from which table, matching what.

SELECT email, created_at
FROM users
WHERE created_at > '2026-01-01';

Which columns, from which table, matching what. That is most of SQL, and the rest of it is variations on the same three slots. You do not need to be fluent to read a system; you need to recognise that a query is a question with those parts, because the next few chapters are about why a particular question is slow.

The word for the thing that makes that question fast is an index: a separate structure the database maintains so it can find matching rows without reading every one. The cost is that it has to be kept up to date on every write. That trade — faster reads paid for with slower writes and more storage — is the whole of chapter four.

Check

You move the counter from a file into a database table and change nothing else about the code: read the row, add one, write it back. Is the lost update fixed?

Choose one answer

Yes — a database handles concurrency, that is the pointNo — two connections can still read the same value and both write back the same resultOnly if the table has an index on the rowYes, because each statement is a transaction

Check answer

What I would actually do

Reach for a database as soon as two things can write. Not because files are bad, but because the day you add a second user is the day a file stops being correct, and that day arrives without an announcement.

Start with the boring one. For almost anything that is not already decided for you, a single Postgres or MySQL instance is the right first answer, and it stays the right answer for far longer than people expect. Chapter ten compares products properly, on a criterion written down first.

Do not design the tables around the screens. The screens change every few months and the data outlives them. Write down the things that exist — users, orders, messages — and what each one needs to be true about it.

Learn to read a query before learning to write one. Most of what you will do early in a career is work out why somebody else's query is behaving strangely, and that reading is a skill you can start building today.

When a file is still the right answer

The condition under which this whole lesson inverts: when only one process ever writes, and losing the most recent write is acceptable.

That is not a rare situation. A build artefact, a generated report, a cache on disk, a log that a single process appends to, configuration that a human edits and a program only reads — all of these are files, correctly, and putting them in a database buys nothing and costs a dependency.

The test is the one from the predict at the top. Ask: can two things write this at the same time? If the honest answer is no, and will stay no, the file is not a shortcut. It is the simpler correct answer, and simpler correct answers are the ones this subject is trying to teach you to keep.

Worth remembering

• Read-modify-write from two places at once loses an update silently, with no error and nothing in the logs — the oldest bug in this subject.
• A database does three things a file does not: it keeps concurrent writes from destroying each other, answers questions without reading everything, and survives being interrupted mid-write.
• A transaction is a group of changes that either all happen or none do.
• A SQL query is always 'which columns, from which table, matching what'.
• An index makes reads fast and is paid for with slower writes and more storage.
• Moving the same read-then-write code into a database does not fix the lost update — the database supplies tools you still have to use.
• A file is the correct answer when only one process writes and losing the last write is acceptable, which is more situations than beginners assume.