Glossary
OLTP
Meaning and details
OLTP, online transaction processing, is the working heartbeat of an application database: insert an order, update a balance, fetch a user, thousands of times per minute, each operation touching a handful of rows, all wra...
OLTP meaning
The transactional workload: many small concurrent reads and writes with strict consistency, the profile of an application's main database.
What is OLTP?
OLTP, online transaction processing, is the working heartbeat of an application database: insert an order, update a balance, fetch a user, thousands of times per minute, each operation touching a handful of rows, all wrapped in ACID transactions. Postgres, MySQL and SQLite are OLTP engines, optimized for exactly this shape of fast, concurrent, small operations.
Why it matters to an indie builder: knowing the label saves you from the best-known self-inflicted wound in backend engineering. OLTP systems are superb at transactions and poor at analytics, and the failure mode is quiet: heavy reporting queries run fine in development and take down checkout latency in production, because scans evict the buffer cache that hot paths depend on.
A concrete example: an e-commerce checkout. Begin a transaction, check stock, decrement it, insert the order, commit: twelve milliseconds with row locks held for milliseconds, and thousands of concurrent shoppers coexist happily. Now run sales by region by month over three years of orders: a sixty second scan that flushes the cache; checkout latency triples while it runs. The fix is not another index, it is separation: a read replica or a nightly export into a columnar engine like DuckDB, keeping each workload on hardware shaped for it.
Common mistakes: missing indexes on hot foreign keys (OLTP dies by sequential scan on joins), long-running transactions holding locks (charge the payment outside the transaction or reconcile afterward), unbounded loops of single-row writes where a batch fits, and treating every scaling problem as an indexing problem when the honest answer is a second datastore. The database blocks on IndieBoot, from Postgres to the serverless options, are all OLTP-first designs.
One pragmatic signal that you have outgrown a single OLTP instance: p99 latency on hot paths degrades at predictable hours, not randomly. Random spikes are missing indexes or long transactions; daily patterns that survive tuning are read volume, and that is the moment a read replica pays for itself in an afternoon instead of a migration.