← lore

Mostly Postgres

one database, on purpose

⚠ warning: slop currently. Work in progress — not final.
Start here
The architecture diagram has six boxes. A cache. A search cluster. A queue. A document store. A graph thing nobody remembers adding. A vector DB from last quarter. Six things to back up, six ways to page you at 3am, and a swamp of glue holding them roughly in sync. Now watch a man who spent fifty years building specialized databases tell you to throw most of them out.

Why this is the same lesson as Go

That swamp gets built one reasonable decision at a time. The graph store arrived for the one feature with nodes. The document DB arrived because JSON felt awkward in columns. Each box solved a real problem the day it landed. Nobody ever schedules the day you take one back out.

Code Like Go strips language features until there's less to argue about. Same move, one layer down. Instead of reaching for a new box, you ask can Postgres do this? — and keep finding that it can. JSON, full-text, geospatial, vectors, queues, time-series, key-value. One engine, one connection string, one transaction that spans the lot. Delete the datastore. Buy back the glue. rm/acc, aimed at where your state lives.

Mike Stonebraker — the man who built it
"If you want to get going, you have a database problem, the answer is choose Postgres… at the low end it's absolutely the right one-size-fits-all."

Stonebraker built Ingres, then Postgres, at Berkeley. Won the Turing Award. Spent fifty years hammering one line: one size fits none. A column store beats a row store on warehouses by 10×. A stream engine looks nothing like either. This is the last man alive who should tell you to default to a single database — and he does, because his own rule has two ends. At the high end — a petabyte warehouse, a million writes a second — specialize or eat an order of magnitude. Everywhere else, which is nearly everywhere, reach for Postgres and start building. The rest of this is the long version of that sentence.

The series

1 · The Default
Choose Postgres, then keep going. Why it's the right one-size-fits-all at the low end, and the two walls — warehouse scale, write scale — that are the only honest reasons to leave.
2 · The Extensible Core
The founding idea: add your own types. Why Ingres died on geospatial and "bond time," and how an extensible engine became PostGIS, pgvector, and JSONB — the reason you rarely need a second database.
3 · Correctness Is Not a Knob
Transactions, referential integrity, and the eventual-consistency mistake. Why "stock > -1" breaks under it, why even Google retreated to Spanner, and when you're actually allowed to oversell.
4 · The Sprawl Tax
Amazon ran fifteen databases — twelve too many. Why graph stores rarely win, why Hadoop lost to relational, and how the OS itself wants to be a database. Retire what isn't pulling its weight.

Read it like this

Start at The Default for the case from the ground up: what to reach for, when you're allowed to leave. Jump to The Extensible Core for the mechanism — why one engine swallows so many jobs. One throughline runs the whole way: every extra datastore is a cost you should be made to justify, never a box you reach for on reflex. Fewer moving parts. Correct while you sleep. Mostly Postgres.

Source
Built on Mike Stonebraker's 2026 interview on databases, LLMs, and DBOS — youtube.com/watch?v=YPObBOwIrHk. Quotes are his; the rm/acc framing is ours.