OLAP (Online Analytical Processing)
Also known as: analytical workload, online analytical processing
OLAP describes workloads made of a small number of large queries that scan and aggregate many rows over few columns — revenue by region by month. It is optimised for scan throughput rather than per-row latency, which is why OLAP stores use columnar layout, compression and vectorised execution.
Last reviewed · Part of the Architecture Glossary
In practice
Columnar storage is the whole trick, and one example makes it obvious. A 200-column fact table, a query touching 3 columns: row storage reads all 200 columns' worth of bytes to get them, columnar reads 1.5% of the data. Add per-column compression (values of one type compress far better than mixed rows) and run-length encoding on low-cardinality columns, and the effective scan is another 5-10x smaller.
| OLTP | OLAP | |
|---|---|---|
| Query shape | Few rows, all columns | Many rows, few columns |
| Storage | Row-oriented | Column-oriented |
| Latency target | 1-10 ms | 1-60 s |
| Concurrency | Thousands | Tens |
| Writes | Small, constant | Bulk, batched |
| Examples | Postgres, MySQL, DynamoDB | ClickHouse, BigQuery, Snowflake, DuckDB |
When it matters
Reporting, dashboards, product analytics, and any query with GROUP BY over more than a few million rows.
Common mistake
Building the analytics stack before the volume justifies it. Postgres handles analytical queries over tens of millions of rows perfectly well, especially with a read replica and a few materialised views. A warehouse plus ingestion pipeline plus orchestration is a large permanent cost — see the selection matrix for where the crossover actually is.
See also
- OLTP (Online Transaction Processing)OLTP describes workloads made of many small, short-lived transactions that read and write a few rows each — placing an order, updating a profile.
- Materialized ViewA materialized view stores the result of a query physically rather than recomputing it on each read.
- LSM Tree (Log-Structured Merge Tree)An LSM tree buffers writes in an in-memory table, flushes them to immutable sorted files, and merges those files in the background.