What is OLTP?
Also known as
Online Transaction Processing
OLTP stands for online transaction processing: processing that involves a large number of small operations, such as logging user activity on a website. Placing an order, updating a profile, adding an item to a cart — each one touches a few rows and has to finish in milliseconds, thousands of times a second.
OLTP is the counterpart to OLAP, which handles a small number of large operations. Same data, opposite access patterns.
What OLTP workloads look like
Transactional queries share a shape:
- They read or write a handful of rows, usually looked up by primary key.
- They’re a mix of reads and writes, and the writes matter — correctness is not negotiable.
- They’re predictable. The application issues the same few dozen query patterns forever.
- They run constantly and must stay fast under concurrency.
SELECT * FROM orders WHERE id = 48291;
UPDATE orders SET status = 'shipped' WHERE id = 48291;
The “T” is doing real work here. A transaction groups several statements so they either all succeed or all roll back — you never want an order marked paid without the payment row landing too.
How OLTP systems are built for it
Transactional databases like PostgreSQL, MySQL, and SQL Server optimize for this pattern:
- Row-oriented storage. An entire record sits together on disk, so fetching one row is one read.
- Indexes. B-tree indexes turn lookups into near-constant-time operations instead of table scans.
- Normalization. Data is split across many narrow tables so each fact is stored exactly once and updates stay cheap and consistent.
- Locking and isolation. Concurrent transactions are kept from stepping on each other.
Why you shouldn’t run analytics on your OLTP database
The application database behind your product is an OLTP system, and it’s tempting to query it directly. Two things go wrong. First, a single analytical query can scan enough rows to slow down the database your customers are actively using. Second, normalized schemas make analysis painful: a question about revenue by plan may need five joins before you can start.
The usual fix is to copy data out on a schedule with an ETL or ELT pipeline into an analytical database, or at minimum to point reporting at a read replica so heavy queries can’t hurt production. From there you can join product data with the SaaS tools your team runs on and analyze all of it together.
Related terms
Further reading
Put it to work
- Build a data pipeline — Integration
- Ecommerce analytics — Overview
- Ecommerce sales — Dashboard
