Online transaction processing (OLTP)

The workload this spoke is built around: many small, concurrent reads and writes against current data, each wrapped in a transaction with correctness guarantees (atomicity, isolation). OLTP is the database sitting in an application’s request path — an order gets placed, a row is updated, a balance is read. It is row-oriented by default: a transaction usually touches whole records, so storing each row contiguously is the efficient layout.

The boundary that defines the spoke

OLTP is the counterpart to OLAP (online analytical processing), which the sibling analytical-databases owns. The split is real, not cosmetic:

• OLTP — row-oriented, write-heavy, low-latency point operations, transactional. Turso, MySQL, Postgres, and the sharded fleets of Vitess/PlanetScale.
• OLAP — columnar, read-heavy, scans and aggregates over huge datasets, vectorized execution. ClickHouse, DuckDB (both in ../analytical-databases-wiki).

That analytical spoke explicitly carves out “transactional/OLTP databases” — which is exactly the gap this spoke fills. The two are engineering-distinct: the columnar scan that makes OLAP fast is the wrong layout for the single-row update that OLTP does all day, and vice versa. A store that tries to do both well is called HTAP, and is the interesting seam between the siblings.

Why the founding sources are all OLTP

turso is “an in-process OLTP database”; planetscale-768-servers shards a transactional SQL database and opens with the transactional bottleneck (the single-writer WAL). Both are squarely on the OLTP side of the line, which is why neither fit the OLAP-only analytical spoke and why this spoke exists.

Related

operational-databases · database-sharding · turso · analytical-databases · synthesis