OLTP vs OLAP
Two workload shapes with opposite requirements — many small indexed transactions versus few large scans and aggregations — which is why they belong in different stores.
OLTP: high volume of short transactions, each touching a handful of rows by key, with strict latency and correctness requirements. Row-oriented storage, heavily indexed, normalised.
OLAP: a smaller number of queries, each scanning millions of rows and aggregating a few columns. Column-oriented storage, compressed, denormalised, no need for row-level locking.
The reason the split is physical rather than merely organisational is column versus row storage. An analytical query summing one column over a hundred million rows reads only that column in a columnar store — often a hundredth of the I/O — and compresses it far better because adjacent values are similar. A row store must read every row in full.
Which is why running analytics against the production OLTP database causes trouble in both directions: the analytical query is slow because the storage is wrong for it, and it interferes with transactional work through I/O contention, cache eviction and long-running read locks.
The modern nuance worth stating: HTAP systems and columnar replicas of transactional databases narrow the gap, and for moderate volumes a read replica with columnar indexes removes the need for a separate warehouse. The split is a workload property, not a law.