What a database actually is

A database is a program that stores data and answers questions about it. That is the whole definition, and almost everything else in this course follows from taking it seriously.

Not a file with structure

The usual first mental model is "a database is a very organised file". It is not, and the difference is what you are paying for.

A database is a running program — a server, usually on its own machine — that owns the data. You do not open the file. You connect to the program and ask it things:

SELECT title FROM books WHERE author = 'R K Narayan';

You did not say how to find those rows. You did not say which order to read the file in, whether to use an index, or how to hold the result in memory. You said what you wanted, and something else worked out how.

That gap — between what you asked for and how it was found — is the single most important idea in this course. It is why a query can be a hundred times faster after adding one index without a word of your code changing. It is also why a query can be a hundred times slower for reasons that are invisible until you learn to look.

What you are actually buying

Five things, and each one is a thing you would otherwise have to build.

1. Concurrency. Fifty people can read and write at the same moment without corrupting each other's work. Two customers buying the last copy of a book cannot both succeed. This is the hardest of the five to build yourself and the one people underestimate most — a whole module of this course is about it.

2. Durability. When the database says a write succeeded, it survives the power being cut a millisecond later. Not "probably". The write is on disk, in a log, before you are told it worked.

3. Integrity. The database refuses to store data that breaks your rules. A loan with no borrower, a negative quantity, two members with the same email — refused at the door, not patched up afterwards by whichever piece of code remembered.

4. Querying. Ask questions you did not anticipate when you stored the data. "Which books have been borrowed more than five times but never by anyone under 25?" is one statement, and you did not design for it.

5. Speed at size. Finding one row among fifty million, in milliseconds, because the data is organised for finding rather than for storing.

You could write all five. People have. It takes years, and the result is worse than PostgreSQL, which is free.

Client and server

your program  ──connect──▶  the database server  ──▶  files on disk
   (client)                    (owns the data)

Your application is a client. The database is a server — a separate process, frequently on a separate machine, listening on a port (5432 for PostgreSQL).

Three consequences that matter from your first week:

Every query is a round trip. Milliseconds on the same machine, tens of milliseconds across a network. A loop that runs one query per item pays that cost per item, which is how the most common performance bug in this field works.

Connections are expensive. Opening one involves a handshake and authentication and costs the server memory. You do not open one per query — you keep a pool of them, which is its own lesson later.

The database is shared. Other programs, other people, and a colleague with psql open are all talking to the same data at the same time as you. That is the point, and it is why concurrency is not optional.

SQL, and what "declarative" means

SELECT b.title, COUNT(l.id) AS times_borrowed
FROM books b
LEFT JOIN loans l ON l.book_id = b.id
GROUP BY b.title
ORDER BY times_borrowed DESC
LIMIT 10;

There is no loop there. No opening a file, no counter, no sorting algorithm. You described the result you want and the database worked out how to produce it.

That is a declarative language, and it is genuinely different from the Python or JavaScript you may know, which are imperative — you write the steps.

The consequence people find hardest: you are not in control of how it runs. The database has a query planner that chooses a strategy based on how much data there is and what indexes exist, and that choice can change as the data grows. A query that was instant with a thousand rows can become slow at a million, with no code change at all. Module 7 is about reading those decisions.

SQL is also about fifty years old, standardised, and largely the same across PostgreSQL, MySQL, SQLite, SQL Server and Oracle. It will outlast every framework you learn. That is the strongest practical argument for spending time on it.

Tables, rows and columns

The vocabulary, once:

                 ┌──────────────────────────────────────┐
  table          │  books                               │
                 ├────┬───────────────────┬─────────────┤
  columns  ────▶ │ id │ title             │ published   │
                 ├────┼───────────────────┼─────────────┤
  row      ────▶ │  1 │ Malgudi Days      │ 1943        │
                 │  2 │ Train to Pakistan │ 1956        │
                 └────┴───────────────────┴─────────────┘

A table holds one kind of thing. A row is one of them. A column is one fact about each, with a fixed type. A schema is all your tables and the rules connecting them.

You will also meet relation (a table), tuple (a row) and attribute (a column). They are the mathematical terms and they mean the same things. Use the plain words.

Which database

There are hundreds. They fall into about seven families, and the next lessons are about which is which and why you would pick one.

The short version, said now so nothing later surprises you: most applications should start with PostgreSQL, this course teaches PostgreSQL for most of its length, and it also teaches MongoDB and Redis properly because a real web application usually has more than one.

What a database is not

Not a filesystem. Storing images, videos and PDFs in the database is almost always wrong. Put the file in object storage and the path in the database.

Not a message queue. People build queues on tables and it works badly. Use a queue.

Not a cache. Related, and the reverse mistake — using a cache as your source of truth — is worse and gets its own warning in module 11.

Not a replacement for thinking about your data. The most expensive mistakes in this course are modelling mistakes, and no database prevents them. A query you got wrong costs an afternoon; a schema you got wrong costs a year.

Check your work

The definition. A program that stores data and answers questions about it.

The most important idea in the course. The gap between what you ask for and how it is found.

The five things you are buying. Concurrency, durability, integrity, querying, speed at size.

Which of the five is hardest to build yourself. Concurrency.

What "client and server" means for your code. Every query is a round trip, connections are expensive, and the data is shared.

What declarative means. You describe the result, not the steps — so you do not control how it runs.

Why a query can get slow with no code change. The planner's choice depends on how much data there is.

Why SQL is worth the time. Fifty years old, standardised, and it outlasts frameworks.

Four things a database is not. A filesystem, a queue, a cache, or a substitute for thinking about your data.

The relative cost of mistakes. A wrong query costs an afternoon; a wrong schema costs a year.

Practice

1. Write down, in one sentence each, the five things a database gives you.
2. Pick one and sketch how you would build it yourself in files. Stop when it stops being fun.
3. Find a program on your machine that stores data in a file — a browser, a notes app — and work out what happens if you kill it mid-write.
4. Write a question about a set of data you know well that you could not answer without reading everything.
5. Explain "declarative" to somebody, using a SQL query and a Python loop that do the same job.
6. List three applications you use daily and guess what each stores in a database.
7. Find out what port PostgreSQL, MySQL and MongoDB listen on by default.
8. Look up how many rows the largest table you have ever heard of has. The number is larger than you expect.

Official documentation

• PostgreSQL — What is PostgreSQL? — The project's own one-page answer, including its history.
• PostgreSQL — A brief history of PostgreSQL — Why it exists and where the relational model came from.
• Wikipedia — Edgar F. Codd — The author of the 1970 paper that started all of this. Worth ten minutes.

Next: why not just use files.