OLTP

New
adopt
First Added:July 23, 2026

OLTP (Online Transaction Processing) is the approach of processing many short, concurrent read/write transactions against current operational data. We adopt it as the default vocabulary for systems of record versus OLAP.

Blurb

Online transaction processing (OLTP) is a type of database system used in transaction-oriented applications, such as many operational systems.

Summary

What it is: Write-heavy (and mixed) workloads that keep the live business state correct: orders, payments, inventory, sessions, tickets. Queries are usually simple, selective, and latency-sensitive. Integrity, concurrency control, and durability matter more than multi-dimensional roll-ups.

When to use:

SituationNotes
System of recordApp databases, ledgers, booking, auth stores
High concurrency writesMany users mutating small rows at once
Strong consistency needsACID transactions on current state (Postgres, Neon)
Operational APIsCRUD backends behind product features

When to skip:

  • Historical analytics, BI, and large scans (OLAP, warehouses, lakes)
  • Calling a warehouse an OLTP store when writes are rare batch loads
  • Using an analytic engine as the primary mutable app database

Trade-offs: Excellent for correct, concurrent updates; poor fit for heavy aggregations over years of history without a separate analytic path.

Details

OLTP Vs OLAP

TopicOLTPOLAP
WorkloadMany small transactionsComplex reads, aggregates
Data shapeCurrent, often normalizedHistorical, denormalized or columnar
OptimizationIndexes, write path, integrityScan, compress, columnar
Garden examplesPostgres, NeonDuckDB, Snowflake, BigQuery

Design Notes

TopicNotes
TransactionsPrefer clear ACID boundaries over ad-hoc multi-statement hope
ScalingVertical + careful sharding; or serverless Postgres (Neon) for bursty apps
ConsistencyPair with CAP Theorem when the store is multi-region
Escape hatchesNoSQL when the access pattern is not relational CRUD

Related Garden Items

References