The two workloads want opposite physical layouts. An OLTP engine stores each row's values together, so one disk page holds a whole order and an update writes one place. An OLAP engine stores each column's values together, so a query that sums price reads only the price column, compressed tightly because neighboring values are similar, and processes it in vectorized batches.
| Property | OLTP | OLAP |
|---|---|---|
| Typical query | Read or change a few rows by key | Scan and aggregate millions of rows |
| Storage layout | Row-oriented | Column-oriented |
| Writes | Constant small inserts and updates | Bulk loads, append-mostly |
| Latency target | Milliseconds | Seconds |
| Examples | PostgreSQL 1,289 , MySQL 524 , Oracle | DuckDB 61,228 , ClickHouse 29,491 , BigQuery 1 , Snowflake |
Running heavy analytics on the production OLTP database also competes with customers for CPU, memory and locks, so a slow quarterly report can slow down checkout. That is why data engineers copy data out of OLTP systems into an analytical store, and why ingestion (Ingestion: Getting Data In) exists at all. Hybrid (HTAP) databases try to serve both workloads, and PostgreSQL can go a long way with indexes and partitioning (Views, Partitions, Parallelism), but at scale most platforms keep the two apart.