PostgreSQL

The default choice at the middle of this spoke's embedded↔distributed axis, and until now a page the wiki did not have. Written from the project's own documentation (T1, first-party): the architectural fundamentals and the MVCC introduction.

Process model

Client/server, with a supervisor process and one backend process per connection:

"The PostgreSQL server can handle multiple concurrent connections from clients. To achieve this it starts ("forks") a new process for each connection. From that point on, the client and the new server process communicate without intervention by the original postgres process."

The supervisor stays up waiting for connections; "client and associated server processes come and go." This is the fact behind every piece of Postgres operational advice this spoke will meet later — a connection is an OS process, not a thread, which is why connection pooling is mandatory at scale and why the per-connection memory cost is a real capacity limit. Compare turso at the embedded end, where there is no server process at all, and vitess at the distributed end, where the process you connect to is a proxy.

MVCC

MVCC is the concurrency design, stated in the docs as a snapshot rule:

"Each SQL statement sees a snapshot of data (a database version) as it was some time ago, regardless of the current state of the underlying data."

And the consequence readers actually care about:

"In MVCC locks acquired for querying (reading) data do not conflict with locks acquired for writing data, and so reading never blocks writing and writing never blocks reading."

The strictest isolation level is delivered through Serializable Snapshot Isolation (SSI), which the docs describe as an innovation of the project's — serializability without the lock contention of two-phase locking. Table- and row-level locks remain available for applications that would rather manage conflict explicitly. The stated rationale: MVCC "minimizes lock contention in order to allow for reasonable performance in multiuser environments," and "proper use of MVCC will generally provide better performance than locks."

Position in the spoke

OLTP on a single node is the case every other page here is defined against — database-sharding is what you do when one Postgres or MySQL stops being enough, local-first-architecture is what you do when the round trip to it is the problem, and planetscale sells the escape from it. Recording the base case makes those readable as departures.

Reading what it decided

The planner's output is observable, and the spoke now pages the artifact and a tool for it: EXPLAIN ANALYZE produces a query execution plan, and pev2 renders one as a diagram that ranks nodes by how badly the planner misjudged their row counts. That covers the plan a query got, not how the planner picked it.

Scaling it out without leaving it (added 2026-08-20)

The extension API is the part of Postgres this spoke now has a reason to care about. citus is a distributed database implemented as an extension — shared_preload_libraries = 'citus', CREATE EXTENSION citus, and the single-node engine described above becomes the coordinator of a cluster whose shards are themselves ordinary Postgres tables. Nothing in the process model or MVCC account changes; a worker is a normal Postgres server, and a shard is a normal table with a number suffixed to its name.

That is a different escape from the single-node limits than the ones this page already names. turso shrinks the database into the process, local-first-architecture moves it into the client, planetscale and vitess front it with a proxy — and Citus keeps every Postgres feature by refusing to leave Postgres at all. Which of those you can use is mostly a question of whether the extension seam is wide enough for what you need; Citus is the strongest evidence available that it is.

The operational layer, filled in (added 2026-08-20)

Three of this page's own claims were assertions with nothing behind them until the awesome-postgres ingest pulled their primary sources.

The process model has a bill, and it is pgbouncer. One forked backend per connection is why pooling is not a tuning option but a deployment requirement — and the pooler's documentation is blunt about the price. Transaction pooling, the mode that produces the large ratios, "breaks a few session-based features of PostgreSQL": SET, LISTEN, PREPARE, session advisory locks, WITH HOLD cursors. Density is bought with session state.

Durability is WAL, and the docs state it as a rule about ordering: changes to data files must be written only after the records describing them have been flushed. The consequence this page needed is that commit costs one sequential append rather than a scatter of random flushes, and that "one fsync of the WAL file may suffice to commit many transactions" — which is the arithmetic under this engine's OLTP throughput. The same log is what pgbackrest archives for point-in-time recovery and what patroni streams to a standby, measuring replica lag in bytes of it.

Failover is not in here at all. Postgres ships replication and leaves the decision-making out; patroni supplies it from outside, as a leader lock in an external consensus store. The engine described on this page has no opinion about whether it is the primary.

And the extension API turns out to be the ecosystem's main road, not a side door — postgresql-extensions counts the catalog's five alternative servers against many hundreds of things that run inside a stock one, citus and pgmq among them.

Still not covered by these pages, and open: how the planner estimates (statistics, histograms, correlation, and how they go stale), what SSI costs under contention, checkpoints and full-page writes, and how streaming replication itself works — patroni configures it and assumes it.