OLTP vs OLAP
Two workloads with opposite shapes — many small transactions against current state, versus large scans across history. The distinction that explains why analytics moved off the production database in the first place.
Many small transactions against current state: point lookups by key, a few rows written, low latency, high concurrency. The shape that explains every design choice an operational database makes.
Few queries, each reading a large range of history and collapsing it into a handful of numbers. Judged on throughput rather than latency, bound by bytes moved rather than by seeks, and unhelped by almost every index you could add.
The two workloads compared on every axis that actually differs — plus an honest account of where the line has blurred, where it has not, and why the distinction still decides your architecture.
What an analytical query actually takes from the operational system it runs on — and the specific, honest cases where running it there is still the right call.
Production database, extraction, transport, raw landing, transformation, analytical storage, BI query — what each hop buys, what it actually promises, and where the shape of the data changes underneath you.
The same four columns of the same table, written to disk two ways — and exactly which bytes each query is then obliged to move as a result.
What an engine actually does with `SELECT avg(spend) FROM users WHERE country = 'DE'` once the data is stored by column: chunks opened, blocks skipped, batches decoded, a predicate evaluated into a mask, and one running total.