Let's say you've just typed psql and you're in. Worth knowing what actually happened.

There was already a server process running, called postgres. It manages the database files. Your psql is a client: it connects, and the server forks a whole new process just for your connection. Clients come and go, even from another machine. The server stays.

psql is just a client. postgres is the house.

Let's say you came from MySQL and your database.table habit just broke. It breaks one level deeper here.

A database contains schemas, and schemas hold tables, types and functions. Every database starts with a public schema, where your tables land by default, and a pg_catalog schema for the system tables and built-ins. Schemas aren't walls: you can reach any one you have privileges on.

Database, then schema, then table. Three levels.

Let's say you've been pasting SQL into a GUI and someone hands you a server with only a terminal.

psql is the terminal front-end: you type queries, the server runs them, you see results. But psql speaks two languages. SQL goes to the server. Backslash meta-commands, psql keeps for itself, for navigating and scripting. -c runs one command string and exits. -f reads commands from a file. One rule from the docs: you can't mix SQL and meta-commands in a single -c, because -c must be completely parsable by the server.

SQL to the server. Backslash to psql.

Let's say the migration takes money from one row and adds it to another, and only one of those may ever happen.

Wrap the steps in BEGIN and COMMIT and they become one transaction: atomic. Other sessions can't see the middle, and if anything fails partway, none of it lands. Without a BEGIN, every statement is its own tiny transaction; the docs say each gets an implicit BEGIN and COMMIT. The trap is quiet: open a transaction, forget the COMMIT, close the window. The work vanishes with it.

Either all of it lands, or none of it does.

Let's say the nightly report runs for an hour and you've been told never to write during it. In Postgres, write anyway.

Consistency comes from MVCC: each statement sees a snapshot of the data as it was some time ago, not a lock on the present. Readers read their snapshot; writers add new versions; neither waits. Reading never blocks writing, and writing never blocks reading.

Reading never blocks writing. That's the model.

Let's say you added an index and the query still reads a lot. This is the picture that explains it.

Every index in Postgres is secondary: stored separately from the table's data area, which the docs call the heap. An index entry doesn't hold your row; it points at it. So an ordinary index scan fetches from both worlds, a walk down the index, then a lookup in the heap for each match. The docs call that heap portion a lot of random access, and it can be slow. That's also why the planner sometimes ignores your index: for enough matches, walking the heap directly is cheaper.

The index is a signpost. The heap is the city.

Let's say someone asks what Postgres is, and you get one sentence.

One server, postgres, holding databases; each database holds schemas, and schemas hold tables, with indexes standing beside the heap like signposts beside a city. Every connection gets its own process. Every statement reads a snapshot, so readers never block writers, and VACUUM sweeps what updates leave behind. Roles own the objects, GRANT opens the doors, pg_dump keeps the copy that outlives the machine.

One server, many databases, one tree.