# Databases

Almost every serious application is, underneath, a database with a user
interface bolted on. Get the data layer right and everything above it gets
simpler.


_Figure 001 — A vector database: text becomes points in space, and search finds the
nearest neighbors.
_

_Figure 002 — Relations, joined by keys.
_

A table is just a set of rows, but the relational model's power is that
you say _what_ you want, not how to get it — and a query optimizer,
every time, works out the how.


Master that and you stop writing loops to do what one statement can.
Describe the result, and the engine chooses the joins, the order, and the
indexes for you.


_Figure 003 — Indexes make lookups fast.
_

Indexes are the reason it works at scale. A B-tree turns a full scan of a
billion rows into a handful of pointer-follows — the same idea that makes
a lookup in a dictionary instant.


Underneath, indexes, query planners, and storage engines work together
to answer those queries quickly — the difference between a query that
returns instantly and one that times out.


_Figure 004 — Transactions keep data correct.
_

Joins are where the model earns its name: keys stitch separate relations
back together, so the same fact lives in one place and every query that
needs it finds it there.


_Figure 005 — Sharding: one big table split across nodes by key.
_

And when many users hit the same data at once,
**transactions** keep it correct. Concurrency and recovery
are what let you trust the number in the account is right.


It all has to survive failure. Write-ahead logs, isolation levels, and
two-phase commit are what let a bank trust its own numbers when the
power dies mid-transaction.


---

_Coming soon — notes for this subject are in progress._