Synthesis — Operational Databases

The evolving thesis. Spun out of the hub _inbox databases-beyond-olap cluster on 2026-07-16, once a third source cohered: an embedded OLTP engine (turso, parked 2026-06-23), a general DB-tooling catalog (awesome-db-tools, parked 2026-06-24), and a distributed-SQL sharding explainer (planetscale-768-servers, the trigger). Both prior park notes had predicted that a third general-DB source would trip this spin-out; the human chose a new spoke over broadening the OLAP-only analytical-databases-wiki, keeping that spoke’s columnar identity sharp.

Current thesis

This spoke owns OLTP / operational databases — the row-oriented, transactional stores in an application’s request path — as the deliberate sibling to the OLAP columnar stores in ../analytical-databases-wiki. That spoke explicitly carves out “transactional/OLTP databases”; this is the spoke that fills the carve-out. The boundary is engineering-real: the columnar scan that makes OLAP fast is the wrong layout for the single-row update OLTP does all day.

The founding trio traces one axis — how far a single logical database stretches — plus the tooling that keeps it running:

1. Database-as-a-library — turso collapses the OLTP engine into the process: an in-process, SQLite-compatible store (a Rust rewrite of SQLite) that adds MVCC concurrent writes, async I/O, CDC, and vector/FTS. The embedded pole.
2. Database-as-a-fleet — planetscale-768-servers explodes the OLTP engine across machines: sharding 768 servers behind a Vitess/Neki proxy router so they present as one database. The distributed pole.
3. The tooling around them — awesome-db-tools catalogs ~200+ tools for working with databases (clients, migration, backup, monitoring, HA) — the operational layer between “it runs” and “it runs in production.”

So the two engines are the same job (serve transactional SQL) at opposite scales, and the axis between them — embedded ↔ distributed — is the spoke’s founding spine. It deliberately mirrors the sibling analytical spoke’s own embedded↔distributed axis (duckdb ↔ clickhouse), one line down in the OLTP register.

The shape of the field (early)

• Scaling an OLTP database goes two opposite ways. Shrink it until the server disappears (turso), or shard it until one server becomes hundreds (database-sharding). Both keep the one logical database interface; they differ in where the complexity goes (into the library vs. into a proxy router).
• Why replicas aren’t the answer. planetscale-768-servers‘s framing — single-writer WAL, replicas duplicate-not-distribute, multi-day backups — is the general case for why write-scaling forces sharding, not just more replicas. It’s the clearest “why distribute at all” argument in the founding corpus.
• OLTP is reaching toward agents. turso ships an MCP server in its CLI; the seam to ../agentic-tooling-wiki (cf. seekdb, an “AI-native state store for agents” coming from the other direction) is worth watching as agent memory and operational stores converge.

The axis has a third pole: the client

The founding spine was embedded ↔ distributed, bracketed by turso (database-as-a-library) and planetscale-768-servers (database-as-a-fleet). rethinking-data-client-event-sourcing extends the embedded end past the server: in a local-first app the OLTP store runs in the user’s process, serves every read and write locally, and the server becomes a sync log. So the axis now runs client → process → fleet, and the same question (“how far does one logical database stretch?”) gets a third answer.

Two consequences for how this spoke reads its own subject:

The interesting component stops being the database. Local-first stacks are built on plain SQLite; the engineering has moved to the sync engine, and the field has three competing answers about what should travel over the wire — an event log (livestore), a mutable auto-merging structure (CRDTs: Automerge, Yjs, Loro), or query-scoped rows (ElectricSQL, PowerSync, Zero). This is the corpus’s first real material on replication and merge semantics, which the open questions below had flagged as the top gap — arriving from the client end rather than the NewSQL end that was expected.

Consistency becomes an explicit product trade, not a default. planetscale-768-servers shards to preserve one consistent logical database; local-first gives up global consistency on purpose to buy responsiveness and offline capability. Schickling draws the line himself: financial systems and social graphs are the wrong fit. Both poles are OLTP, and they disagree about what OLTP is for — the first genuine tension in the corpus, and a useful one.

Adjacent claim worth keeping: data ownership falls out of the architecture, since the user can hold the event log or the materialized SQLite file. The spoke’s other engines treat export as a feature.

The limits the mechanisms were built against

Everything this spoke held past the embedded pole described mechanism — hash routing, proxy aggregation, scatter-gather, failover — and nothing described the results that say which mechanisms are possible. podc-lecture-notes (Wattenhofer, ETH Zürich, T1) supplies them, and closes the spoke’s #1 growth edge from the theory side rather than the engine side the edge asked for.

Three results reframe what the corpus already had.

Consensus is impossible in the general case, and every system is a way of dodging that. FLP, stated exactly: “There is no deterministic algorithm which always achieves consensus in the asynchronous model, with f > 0.” One crash-faulty node and no timing assumptions is enough. So a store that commits across shards is not solving consensus — it is buying an assumption, either partial synchrony (which is what a timeout is) or randomisation. When a distributed database claims consensus, the question the corpus can now ask is which premise did you weaken, and what happens when it does not hold (consensus).

Arbitrary failure has a price in nodes. Byzantine agreement needs f < n/3 — the origin of the 3f+1 replica counts — and authentication moves the bound, which is why signatures get their own chapter rather than being an implementation detail.

The primary source landed 2026-08-10 (byzantine-generals-problem, Lamport, Shostak and Pease, ACM TOPLAS 1982), and it corrects the summary in one place and deepens it in two. Authentication does not move the bound, it removes it: with unforgeable signatures the paper’s SM(m) works for any number of nodes and any number of faults, at the weakest connectivity that keeps the correct nodes connected. The 3f+1 count buys exactly one thing — protection against a node telling different lies to different peers — and a signature buys it outright. Both claims are the paper’s own theorems.

The paper is also honest about what its assumptions cost, in a way secondary accounts drop. Detecting an absent message needs synchronized clocks, and synchronizing clocks under faults is “as difficult a problem as the Byzantine Generals Problem itself” — the assumption is the problem again. And an unforgeable signature is only probabilistically unforgeable; against a malicious operator rather than a random malfunction it becomes a cryptography problem, cited to Diffie–Hellman. Byzantine fault tolerance and adversarial security separate at that line, which is the distinction most modern uses of the word “byzantine” blur.

And the closing sentence generalises past its own subject: “The only way to reduce the cost is to make assumptions about the type of failure that may occur.” Every engine in this spoke takes that discount by assuming crash-stop. Raft and Paxos are affordable because a node is assumed to die rather than lie. That is a purchase, and it is the wrong one when a node is corrupted rather than dead.

CAP is a theorem with a model, not a slogan. Introduced by Fox and Brewer (1999), proven by Gilbert and Lynch (2002) for the asynchronous model, and relaxable under partial synchrony to keep availability and partition tolerance. That kills the pick-two framing and replaces it with the real engineering move: weaken consistency by a named amount (consistency-models). Causal consistency is the name the spoke was missing when rethinking-data-client-event-sourcing arrived arguing merge semantics from an event-sourcing maintainer’s position with no neutral treatment behind it.

Lamport, twice, an hour apart

part-time-parliament arrived directly after byzantine-generals-problem, and the pair is worth more than either alone because they are the two sides of one trade, made by the same author sixteen years apart.

1982 prices the general case: tolerating components that fail arbitrarily costs 3f+1 nodes, message paths of length f+1, and factorial message counts — and its closing sentence says the only way to reduce that is to assume something about how things fail. 1998 takes that discount explicitly. Paxos “does not tolerate arbitrary, malicious failures, nor does it guarantee bounded-time response. However, consistency is maintained despite the (benign) failure of any number of processes and communication paths.”

That is the whole reason production databases can afford consensus at all. Crash-stop is not a simplification, it is the purchase, and it is why Raft-backed and Paxos-backed engines carry no 3f+1 replica count — they are defending against absence, not against lies. The corresponding exposure is now nameable: a node that is corrupted rather than dead is outside the model every store in this spoke runs on.

Paxos also answers a question the spoke had been using without asking. Why majorities? Because quorum intersection is the mechanism (condition B2), and any two majorities of a set share a member; that member is what carries a decided value into every later ballot (B3). Majority is the cheapest quorum system, not the principle.

And the FLP framing above is confirmed from the primary source rather than inferred: the paper states that any protocol meeting its progress condition “must involve measuring the passage of time,” footnoted to Fischer, Lynch and Paterson. Safety needs no clock; only termination does. The paper is candid that leader selection — the part production systems find hardest — is the part it declines to specify, ending that section with the note that no record of the presidential selection protocol survives.

And then the implementation showed up

chubby-lock-service (Burrows, OSDI 2006) arrived third, an hour after the two Lamport papers, and it changes the shape of the theory block rather than adding to it. This is a system, not a result — Paxos running at Google with an outage budget attached — and it is the production witness consensus had been asking for since 2026-08-08.

Three things it contributes that no theory paper can.

The master lease, which is how consensus becomes affordable to read from. A master wins a majority plus promises that nobody will elect a rival for a few seconds, and can then serve reads alone, because the promise proves no other master exists. Writes still cost a majority. That asymmetry — cheap reads bought with a time-bounded promise rather than a quorum — is the single most reusable idea in the paper, and it is invisible from the algorithm.

Consensus as a rented service rather than a library. Google had the Paxos library and shipped a central lock service anyway. The stated reason is organisational — applications acquire high availability after they have users, and a lock is a two-statement change where a replicated state machine is a rewrite — but the load-bearing reason is structural: a consensus library needs a quorum of the application’s own servers to make progress, while a lock service lets a single client proceed safely. The quorum is relocated, not removed. Read beside part-time-parliament, that is the same trade one level up: 1998 makes agreement affordable by assuming benign failure; 2006 makes it affordable by making it somebody else’s service.

What actually breaks. 61 outages over 700 cell-days, most under 15s. Six data losses in a few dozen cell-years: four database software bugs, two operator errors, none from hardware — and the operator errors happened during upgrades intended to fix the software bugs. In a system built for reliability, redundancy handled the failure mode it was designed for and every loss came from the code or the people. This spoke should hold that against any future engine that sells replication as a data-safety story.

One correction to its own premise, worth keeping. Chubby was designed as a lock service and its most popular use is naming — 60% of open files — because consistent caching with explicit invalidation beats DNS’s time-based TTL when polling is expensive. Locks are 31 ppm of its RPC traffic; KeepAlives are 93%. A system’s dominant use was not the one it was built for, and the paper says so plainly.

This also weakens the split case below. Chubby is an operational system, not theory — it belongs to a spoke about running databases more comfortably than to a hypothetical theory spoke.

The same algorithm, told twice, and the second telling is what worked

paxos-made-simple arrived fourth. It is not new territory — it is part-time-parliament again, with the island removed — and that is what makes it useful.

It derives rather than asserts. The 1998 paper states conditions B1–B3 and proves them; the 2001 paper builds them, P1 → P2 → P2a → P2b → P2c, each strengthening forced by a counterexample against the last. Reading them in order shows a result and then the reasoning that makes it inevitable, and the spoke now has both.

It is the source of the working vocabulary. Proposers, acceptors, learners; prepare/promise and accept/accepted. Every implementation in the field speaks this paper’s language, not the 1998 one’s. The algorithm now has its own page, paxos, because three sources cover it from three angles.

Two ideas worth keeping loose from Paxos. First: when you cannot observe the future, forbid it — a proposer cannot know what acceptors will accept, so phase 1 extracts a promise that they will not. Chubby’s master lease is the same trick with a clock on it. Second, stated flatly where the 1998 paper only implies it: a failed or contested leader election costs availability and never correctness. That is the licence every leader-based system in this spoke operates under, and it is why a brief two-leader window is survivable.

And a fact about how ideas travel, not about consensus. Lamport published a rewrite of his own paper with the content unchanged and only the exposition fixed, and the rewrite is the one the field learned from. The idea was complete in 1998 and did not spread until 2001. That belongs to ../research-wiki’s diffusion-and-adoption cluster more than here; noted, not argued.

The routing caveat got a second data point. The byzantine paper routed here on 2026-08-10 over ../research-wiki (which owns Lamport’s tla-plus and the formal-methods lineage) because this spoke holds consensus. Three theory sources now — Wattenhofer’s notes, the 1982 byzantine paper and the 1998 Paxos paper — all in a spoke defined by operational databases. The trigger the earlier note set has been reached and is recorded as a live question for the hub rather than settled here.

The fourth source argued against the split. chubby-lock-service is a production system with an outage budget, not a theorem, and it makes the block look less like stray theory and more like a consensus stratum this spoke was always going to need: the mechanism, its limits, and one system that runs it. The case for a distributed-systems-theory spoke is weaker at four sources than it was at three. Left open, and paxos-made-simple does not move it: a second telling of an algorithm the spoke already holds deepens one page rather than widening the footprint. The trigger stays what it was — a source opening new distributed-systems territory with no system attached.

A routing caveat worth keeping visible. Fifteen of the book’s twenty-two chapters — graph colouring, distributed sorting, wireless protocols, self-stabilisation, game theory — are outside this spoke and are recorded rather than paged. The source’s centre of gravity sits outside the spoke that holds it. If more distributed-systems theory arrives, a distributed-systems-theory spoke is the natural home and this routing should be revisited rather than defended.

The base case, written down at last

The spoke spent a month describing departures from a thing it had never described. postgresql and mysql are now here from their own documentation, and two details do work immediately.

Postgres forks a process per connection. Not a thread — an OS process, with the supervisor staying up to accept the next one. That single fact is behind connection pooling being mandatory rather than an optimisation, and it marks how far turso moves at the embedded end (no server process exists) and vitess at the distributed end (the process you connect to is a proxy that speaks the MySQL wire protocol).

InnoDB’s clustered index makes the shard key and the primary key one decision. Table data lives inside the primary key index, and secondary index entries carry the primary key rather than a row pointer, so a non-primary-key lookup is two traversals. cross-shard-queries describes the same choice one level up, where the wrong key turns a query into a scatter. The cost structure that decides a query’s fate on one node is the cost structure that decides whether a fleet can route it — vitess‘s vindexes are that decision made twice.

And both engines run MVCC, reached independently, with different bills: Postgres writes new heap versions and pays in bloat and vacuum, InnoDB keeps an undo log and pays under long transactions. The shared guarantee — reading never blocks writing, writing never blocks reading — is the single-node version of the question consistency-models asks of distributed systems. On one node a snapshot is exact and cheap. The moment there is more than one node, “as it was some time ago” needs a clock nobody gets for free, and you are back in consensus.

Open questions

• Does the tooling member cohere with the engines? awesome-db-tools spans OLTP+OLAP+NoSQL, so it is broader than this spoke’s OLTP-engine core. It sits here because its center of gravity (clients, migration, backup, HA) is operational and the analytical spoke is OLAP-only — but if a second tooling source lands, “database tooling” may deserve its own corner rather than being the odd member out.
• Where’s the distributed-consistency substance? The founding corpus names sharding mechanics (hash routing, proxy aggregation) but not the hard part — cross-shard transactions, consistency models, replication/consensus. A NewSQL / distributed-SQL source (CockroachDB, Spanner, Vitess internals, Citus) is the top gap. Partly opened 2026-07-29 from the other direction: rethinking-data-client-event-sourcing supplies merge semantics (event-sourcing vs CRDTs vs query sync) for the client case. The server-side consensus story is still missing.
• Which sync mechanism actually holds up? The event-sourcing-beats-CRDTs claim arrives from a person who maintains an event-sourcing framework, with no benchmark or comparative study. A CRDT-side source (Automerge, Yjs, Loro) or a neutral evaluation would make this a real comparison rather than one advocate’s position. Same shape as the vendor-blog caution below.
• What does a query cost when the shard key can’t route it? (added 2026-08-03) The corpus described routing by hash of a shard key and then hand-waved the rest: cross-shard ORDER BY, COUNT(*), and deep pagination all force a scatter-gather where every shard answers and the proxy merges. sharded-pagination-interview-post posed the sharpest version (page 100,000 across 256 shards) and is paywalled, so it arrived as a question with no answer attached. Mechanism answered the same day by the substitute route the human called for: vitess-query-serving-docs states the planning rule — push work down to MySQL where the vindex routes it, “collect input from multiple sources and merge the results” where it doesn’t — and defines scatter precisely as a sharded keyspace addressed without a vindex (cross-shard-queries). It also supplies the instrument the corpus lacked: VEXPLAIN TRACE reports ShardsQueried per operator, and VEXPLAIN KEYS names the columns that would have to become the vindex for a query to stop scattering. Still open, and narrower than before: no source here gives a cost model for deep offsets, and none states the keyset/cursor remedy — the wiki holds the mechanism and deliberately declines to write the fix it cannot cite. This remains the read-path twin of the distributed-consistency gap above.
• HTAP — the seam with the sibling. A store that does OLTP and OLAP well is the interesting boundary case between this spoke and analytical-databases-wiki. None sourced yet; when one lands, decide its home by center of gravity and cross-link.

Growth edges

Ranked; each names the kind of source that would close it (see ../QUALITY.md → Growth edges).

1. The distributed-consistency substance. Partly CLOSED 2026-08-08 by podc-lecture-notes — consensus, FLP, byzantine bounds, quorum systems, CAP and the weak-consistency vocabulary (consensus, consistency-models). The engine half stands: no production system’s own account is here — Spanner’s TrueTime, CockroachDB on Raft, Vitess’s failover path — and Raft itself, the algorithm most of them run, appears in neither the book nor this wiki. — needs: an engine-internals doc or the Raft paper.
2. A CRDT-side source. The event-sourcing-beats-CRDTs claim comes from someone who maintains an event-sourcing framework, with no benchmark. — needs: T1/T2 from Automerge/Yjs/Loro, or a neutral comparison.
3. What a non-routable query costs. Opened 2026-08-03 and unanswered: scatter-gather cost when the shard key cannot route. — needs: a measurement or an engine doc that states the penalty.
4. Raft, and an engine’s own account. (new 2026-08-08) podc-lecture-notes gives Paxos and the impossibility result; the algorithm most production stores actually run is in neither the book nor this wiki. — needs: the Raft paper, or an engine-internals doc describing a real failover path.

Coverage edges (added 2026-08-08, at the curator’s request for a wider backlog). These widen what the spoke covers instead of answering an open question above; one ordinary solid source closes any.

5. The two engines everyone actually runs. CLOSED 2026-08-09 (research pass) — postgresql and mysql written from the projects’ own documentation (both T1), plus multiversion-concurrency-control as the mechanism they share. Successor: the write path. Both pages stop where the interesting operational failures start — WAL/redo, checkpointing, crash recovery, and replication, which is exactly what planetscale-768-servers describes hitting. — needs: the engines’ internals docs on WAL and replication, or a chapter on write-ahead logging.
6. Storage-engine mechanics — a quarter closed 2026-08-09. MVCC is now defined from two engines’ docs (multiversion-concurrency-control). B-trees, LSM trees and the write-ahead log are still undefined, and the LSM half matters most — it is the design the spoke’s OLAP siblings and every embedded key-value store use, and nothing here states the read/write-amplification trade against the B-tree. — needs: a textbook chapter or an engine’s internals docs.
7. Isolation levels, stated properly. consistency-models covers the distributed side; the single-node side (read committed, repeatable read, snapshot isolation, the anomalies each allows) is unwritten. — needs: the ANSI definitions plus a critique such as the Berenson et al. paper.
8. The document and key-value neighbours. MongoDB and Redis are operational stores by any reading of the domain and appear nowhere. — needs: first-party documentation, one page each.

Contradictions / tensions

One live tension since 2026-07-29: planetscale-768-servers shards precisely to keep one globally consistent logical database, while local-first-architecture gives up global consistency on purpose to put the store in the client. Not a factual contradiction — both are right about their own workloads — but the two ends of this spoke now hold opposite views on whether consistency or responsiveness is the property an OLTP store exists to protect. Recorded, not resolved.

The founding trio remain complementary (embedded engine / distributed engine / tooling) rather than competing. The standing external caution: planetscale-768-servers is a vendor blog (T2, product to sell) and turso is pre-1.0 with self-described incomplete SQLite compatibility — neither performance nor maturity claims are independently verified here.

Cross-spoke adjacency

• ../analytical-databases-wiki — the defining sibling. It owns OLAP/columnar engines (analytical-databases, clickhouse, duckdb, tinybird); this owns OLTP/row stores. The OLTP vs OLAP line is the boundary; HTAP is the seam. Cross-link, never duplicate.
• ../agentic-tooling-wiki — the agent-memory seam: turso‘s MCP server and seekdb (an agent state store) are the two sides of operational-store ↔ agent convergence.
• ../platform-ops-wiki — owns the SRE/ops practice of running prod systems; a database’s architecture (sharding, replication) is here, the operating of it cross-links there.
• ../cloud-wiki — managed-DB pricing/hosting cross-links there; the engine as subject is here.

Index — Operational Databases Wiki

Catalog of every page, grouped by schema.org @type. Spine: synthesis (thesis), log.md (history), this file (catalog). Spun out of the hub _inbox databases-beyond-olap cluster on 2026-07-16 (3 sources). Some wiki-links resolve to sibling analytical-databases-wiki nodes (intentional cross-wiki links).

DefinedTerm (concepts)

• paxos — the algorithm itself, split out 2026-08-10 once three sources covered it: safety unconditionally, liveness only with an elected leader; quorum intersection and the phase-1 promise that forbids the future it cannot observe. Plus what production adds — the master lease and one-leader-across-all-slots amortisation · algorithm

• operational-databases — umbrella: transactional/OLTP databases + their tooling, across the embedded↔distributed spectrum; the operational sibling to OLAP · domain

• online-transaction-processing — OLTP: many small transactional reads/writes on current data, row-oriented; the OLTP-vs-OLAP boundary that defines the spoke · concept

• database-sharding — distributing data + writes across many primaries so a fleet looks like one DB (proxy router + hash shard key + cross-shard aggregation); the distributed end · concept

• cross-shard-queries — what happens to a query the shard key can’t route: push down to MySQL where a vindex routes it, fan out and merge at the proxy where it doesn’t; scatter defined as sharded keyspace without a vindex, and why a deep OFFSET makes every shard return offset+limit rows · mechanism

• local-first-architecture — the OLTP store moves into the client (local SQLite serves every read/write; server becomes a sync log); the third pole past embedded, trading global consistency for responsiveness · concept

• event-sourcing — state as an append-only immutable event log, current state materialized by replay; doubles as the local-first sync protocol, and the live argument against CRDTs · concept

• multiversion-concurrency-control — MVCC: keep several row versions so a statement reads a snapshot — “reading never blocks writing and writing never blocks reading.” Postgres (new heap versions + vacuum) vs InnoDB (undo log) reach the same guarantee at different costs; the single-node answer to what consistency-models asks of distributed ones · mechanism

• consensus — agreeing on one value when nodes fail. FLP (Thm 16.14): no deterministic algorithm always achieves consensus in the asynchronous model with f > 0 — so every working system buys out via partial synchrony (timeouts) or randomness. Byzantine agreement needs f < n/3; authentication changes the bound · concept

• consistency-models — when a write becomes visible and in what order. CAP with its model attached (Fox & Brewer 1999, proven by Gilbert & Lynch 2002 for the asynchronous model; relaxable under partial synchrony), plus eventual and causal consistency, and quorum systems as the way a promise becomes a per-operation cost · concept

SoftwareApplication (engines / sources)

• postgresql — the single-node OLTP base case: client/server with one forked backend process per connection, MVCC snapshots so reads and writes never block each other, serializability via SSI. First-party docs · source · T1 · postgresql.org

• mysql — the engine vitess shards, finally described in its own terms: InnoDB as default storage engine — ACID + crash recovery, row-level locking with Oracle-style consistent reads, clustered index on the primary key (which is why shard key and primary key are one decision), foreign keys, 64TB limit · source · T1 · dev.mysql.com

• vitess — planetscale‘s MySQL sharding system: VTGate proxy speaking the MySQL wire protocol, VTTablet per instance, VSchema + vindexes as the routing metadata, VEXPLAIN as the plan/trace tool; the distributed end’s actual machinery · engine

• turso — in-process, SQLite-compatible OLTP engine; a Rust rewrite of SQLite (MVCC concurrent writes, io_uring, CDC, vector/FTS, MCP server); the embedded end · source · T1 · github.com/tursodatabase

• livestore — reactive client-side SQLite with an event-sourcing sync engine (Schickling / Schiefer / Litt); the local-first artifact — log travels, database is the materialized view · entity

TechArticle (sources)

• sharded-pagination-interview-post — stub, paywalled: Medium interview-prep post asking how to serve page 100,000 from an order table across many shards. Establishes the question and the LIMIT 1000000, 10 anti-pattern; the body (keyset vs offset, scatter-gather merge, cursor encoding) was unreadable via WebFetch and Firecrawl · source · T4 · medium.com
• vitess-query-serving-docs — Vitess 23.0 reference (Execution Plans, VTGate, VEXPLAIN, Sharding): the planner pushes work down to MySQL and merges only what it must; scatter = sharded keyspace with no vindex; VEXPLAIN TRACE reports ShardsQueried, KEYS proposes sharding-key candidates. Pulled as the readable substitute for the paywalled pagination article; still silent on deep-OFFSET cost · source · T1 · vitess.io
• planetscale-768-servers — PlanetScale: sharding a transactional SQL DB so 768 servers (256 shards × 3) look like one; WAL/replica/backup bottlenecks + Vitess/Neki proxy routing; the distributed end · source · T2 · planetscale.com

ScholarlyArticle (sources)

• paxos-made-simple — Lamport, 2001 (14pp): the author rewriting himself because “the original presentation was Greek to many readers.” Derives P1→P2→P2a→P2b→P2c instead of asserting them, names proposers/acceptors/learners and the prepare/accept phases everyone now uses, and spells out the dueling-proposer livelock. Its principle: a bad leader election costs availability, never correctness · source · T1 · microsoft.com
• chubby-lock-service — Mike Burrows, Google, OSDI 2006 (16pp): Paxos in production. Five replicas, a master lease that lets reads be served by the master alone, and the argument for a lock service over a Paxos library — a library needs a quorum of your servers, a lock service lets one client proceed. Designed as a lock service, 60% of its open files are naming; DNS at 3k processes and a 60s TTL would need 150k lookups/s. Six data losses in dozens of cell-years, none from hardware · source · T1 · research.google
• part-time-parliament — Lamport, ACM TOCS May 1998 (33pp): Paxos, told as archaeology on a Greek island. Safety is three conditions and no clock — unique ballot numbers, any two quorums intersect, and a new ballot adopts the latest earlier vote; that intersection is why consensus counts majorities. Progress needs timers, footnoted to FLP. Its §4 states the trade the 1982 paper predicted: no malicious-failure tolerance, no bounded time, but consistency under benign failure of any number of nodes and links · source · T1 · microsoft.com
• byzantine-generals-problem — Lamport, Shostak & Pease, ACM TOPLAS July 1982 (20pp): the primary source for consensus‘s f < n/3. The bound belongs to the problem, not to any algorithm — and signatures delete it, SM(m) solving for any n and any number of faults at the weakest connectivity. Its two admissions are the valuable part: detecting an absent message needs clock sync, itself “as difficult a problem as the Byzantine Generals Problem”, and unforgeable signatures are only probabilistic. The generals are avionics and missile-defence voting hardware, and “traitor” never meant malice · source · T1 · lamport.azurewebsites.net

Book (sources)

• podc-lecture-notes — Wattenhofer, Principles of Distributed Computing (ETH Zürich, 2016, 321pp, free): the spoke’s first T1 theory text. Seven chapters are its subject — Paxos, consensus and the impossibility proof, byzantine and authenticated agreement, quorum systems, eventual consistency and CAP, distributed storage. Fifteen chapters are out of scope (graph algorithms, wireless, game theory, self-stabilisation) and recorded as such; the book’s centre of gravity sits outside the spoke holding it · source · T1 · disco.ethz.ch

Collection (sources)

• awesome-db-tools — mgramin’s curated catalog of ~200+ tools for working with databases (OLTP+OLAP+NoSQL); the tooling member, not engines · source · T3 · github.com/mgramin

PodcastEpisode (sources)

• rethinking-data-client-event-sourcing — InfoQ (2026-07-27), Olimpiu Pop × johannes-schickling: drop the three-tier stack for client-side SQLite synced by an event log; “data is the bottleneck,” event sourcing vs CRDTs vs query-sync engines, and where local-first is the wrong call · source · T2 · infoq.com

Organization (entities)

• eth-zurich — CollegeOrUniversity: publishes the DISCO course notes openly, which is why a 321-page graduate text is readable here · institution
• planetscale — the DB company maintaining Vitess (MySQL sharding) + Neki (Postgres); the distributed-SQL/sharding vendor stratum · entity

Person (entities)

• leslie-lamport — author of both byzantine-generals-problem (SRI, 1982) and part-time-parliament (DEC, 1998), and later of tla-plus in ../research-wiki. Canonical node for all three, and the seam between this spoke’s consensus theory and that spoke’s formal methods · author
• roger-wattenhofer — ETH Zürich; leads the DISCO group, author of the course text · author
• johannes-schickling — Prisma founder; livestore + Overtone; the corpus’s advocate for event sourcing over CRDTs (and maintainer of the framework that implements it) · entity

Synthesis

• synthesis — the thesis: OLTP databases across the embedded↔distributed spectrum, bracketed by Turso (database-as-a-library) and PlanetScale (database-as-a-fleet)

Notes

• Founding entities: planetscale paged as the article’s owner. The Turso maker-org and awesome-db-tools’ author (@mgramin) are deferred — thin at founding; page them when one recurs.

Bridge nodes (live in sibling wikis, linked cross-wiki)

analytical-databases · clickhouse · duckdb (analytical-databases-wiki — the OLAP siblings) · seekdb (agentic-tooling-wiki — agent state-store, the OLTP-reaches-for-agents seam)