Operational databases

The umbrella for this spoke: transactional / operational (OLTP) databases and the tooling around them. These are the row-oriented stores that sit in the request path of an application — handling many small reads and writes with transactional guarantees — as opposed to the analytical / OLAP columnar stores that answer big aggregate queries (owned by the sibling analytical-databases in ../analytical-databases-wiki). The OLTP vs OLAP split is the spoke's founding boundary.

The founding shape

The three founding sources trace a spectrum plus its tooling:

Embedded end — turso: an in-process, SQLite-compatible OLTP engine (a Rust rewrite of SQLite). The database is a library linked into the app; no server.
Distributed end — planetscale-768-servers: sharding a MySQL/Postgres database with Vitess/Neki so hundreds of servers present as one logical database.
The tooling around them — awesome-db-tools: a catalog of ~200+ tools for working with databases (clients, migration, backup, monitoring, security), spanning all engine types.

Past the embedded end (added 2026-07-29)

local-first-architecture extends the spectrum one hop further than turso: the OLTP store moves out of the server process entirely and into the client, with the server reduced to a sync log. livestore is the artifact (event-sourcing log → materialized client-side SQLite), and the sync engine — not the database — is where the design decisions now sit rethinking-data-client-event-sourcing.

The distributed end has two shapes (added 2026-08-20)

citus joins planetscale-768-servers at the distributed end and splits it in two. PlanetScale puts the routing in a proxy in front of the engine; Citus puts it in an extension inside the engine. Both present a fleet as one logical database, and the split decides what survives the trip — a proxy has to reimplement the engine's capabilities to route around them, an extension inherits them. shard-colocation is the mechanism both depend on and only Citus names in its API.

Citus is also the spoke's first store with a serious claim on both sides of the OLTP/OLAP line — a distributed row store with a columnar access method and an executor built for mixed workloads — which is the HTAP seam with analytical-databases the spoke had flagged and never sourced. It sits here because its centre of gravity is a transactional Postgres you scaled out, and because its columnar tables cannot take an UPDATE. matrixone (2026-09-23) is the second HTAP store and the opposite design: a MySQL-compatible engine built from immutable columnar objects on S3 that still takes row-level updates.

The tooling half stops being a catalog (added 2026-08-20)

The domain has always said "and the tooling around them," and until now that half was carried by two directories (awesome-db-tools, awesome-postgres) plus one deep tool (pev2). The awesome-postgres ingest turned it into a working account of what an OLTP database needs around it to be run, mined from that catalog's own sections and each read at its primary source:

Failover — patroni. A leader lock with a TTL in an external store, three integers deciding the availability/safety trade, and a hardware watchdog to stop a demoted primary that will not stop itself.
Durability — write-ahead-logging as the mechanism, pgbackrest as the operation: physical backups plus every WAL segment, which is what point-in-time recovery actually consists of.
Connection density — pgbouncer. Process-per-connection is the reason it exists, and giving up session state is the price.
Work that isn't a query — pgmq. SKIP LOCKED turns a table into a concurrent queue, and the queue can be written in the same transaction as the row that caused it.

Read together they describe a shape the individual pages don't: the engine ships the mechanism and declines the policy. Postgres has replication but no opinion about who should be primary; it has a WAL but no archiver; it forks a backend per connection and does not multiplex them. Each tool above is one of those declined decisions, made by somebody else. That is what "the tooling around them" turns out to mean, and it is why the tooling member of this spoke is not a loose annex to the engines.

The through-line

Both engine sources are the same job at opposite scales: serve transactional SQL. Turso shrinks the database to a single in-process library; PlanetScale grows it across a sharded fleet. The tension they bracket is how far a single logical database can stretch before it must either disappear into the process (turso) or fan out across machines (database-sharding) — with a whole tooling ecosystem (awesome-db-tools) filling the operational gap between "it runs" and "it runs in production."

online-transaction-processing · database-sharding · shard-colocation · turso · planetscale-768-servers · citus · matrixone · postgresql · postgresql-extensions · awesome-db-tools · awesome-postgres · patroni · pgbackrest · pgbouncer · pgmq · write-ahead-logging · analytical-databases · synthesis