Database and DBMS

Chapter 1 — "The map of the archive"

The Kotomarket snapshot is no longer a signal from a dead sector — it sits in a quarantine bay aboard Vault-9, and beneath the last line of its dump there’s still that same signature: "K." This morning a fresh entry flashes across your holopanel: "Clearance granted: the archive index. Issued by: module S.Q.L." The vault door slides aside; behind it, server racks hum steadily in an amber glow.

QUERY: Before you read someone else’s memory, understand how it’s built. Let’s start with the basics: what here is the store, and who is the keeper.

Database and DBMS

A database is an organized store. The Kotomarket snapshot holds buyers, products, orders, and events — not scattered across files, but in a clear structure. That’s exactly why it can still be read a hundred and sixty years later.

But the store itself doesn’t answer questions. You need a program that can create tables, record new orders, read data, and make sure the links never break. That’s a DBMS (database management system). Examples: PostgreSQL, MySQL, ClickHouse. Our snapshot is a PostgreSQL database, and it still speaks the same SQL it did when the shop was alive.

You write a query in SQL → send it to the DBMS → the DBMS fetches the data you asked for and returns the result. Excel is fine for a personal spreadsheet, but not for a shop where thousands of users browse products, place orders, and leave events in the system all at once.

What a DBMS can do that "just files" can’t

It feels like the shop could get by without a DBMS: just write orders into a CSV or Excel. At the scale of a personal notebook, people do exactly that — until the kinds of problems show up that the DBMS was invented to solve in the first place.

• Concurrent access. In the living Kotomarket, buyers placed orders at the same time. Two processes writing to one file overwrite each other’s changes; a DBMS executes changes as transactions and untangles the parallel operations itself. PostgreSQL does this through MVCC: readers don’t block writers, and writers don’t block readers.
• Crash recovery. The power flickers mid-write — the file is corrupted, and there’s no telling which half of the order made it to disk. A DBMS first records the change in a log (in PostgreSQL, the WAL — write-ahead log) and replays it after a crash: the order is either written in full or not written at all.
• Access control. A file is open either entirely or not at all. In a DBMS, permissions are granular — down to a single table:

-- The analyst gets read-only access to orders, with no right to change them
GRANT SELECT ON orders TO analyst;

• Integrity. A DBMS won’t accept an order with a price that’s text, or a reference to a buyer who doesn’t exist: column types and constraints are checked on every write. A file couldn’t care less what’s inside it.
• Declarative questions. "Show me orders over 5000" is a single line of SQL. With a file, the same job falls to a program someone has to write — and get right.