The cash register and the accountant
A restaurant has two data jobs that look unrelated. The cash register processes individual orders all day — quick, small, frequent. That is OLTP (Online Transaction Processing). The accountant sits in the back office and analyses last month's receipts to find trends — slow, big, infrequent. That is OLAP (Online Analytical Processing).
Different shapes, different optimisations
| OLTP | OLAP |
|---|---|
| Many concurrent users | Few analysts |
| Short queries (ms) | Long queries (seconds–minutes) |
| Read + write mix | Mostly read |
| Current data | Historical data |
| Row-oriented storage | Column-oriented storage |
| Example: place an order | Example: revenue by region by quarter |
Where Postgres lives
Postgres is OLTP-first and excellent at it. It also handles moderate OLAP — millions to low-billions of rows — with window functions, materialised views, parallel queries, and JIT. For genuine warehouse-scale analytics (multi-billion-row scans), you replicate Postgres data to a columnar engine (ClickHouse, Snowflake, BigQuery) or use the Citus extension for column store + sharding inside Postgres itself.