Theory
Two workloads, two physics
| OLTP (Transactional) | OLAP (Analytical) | |
|---|---|---|
| Unit of work | One row at a time (e.g., lookup user #42) | Millions of rows scanned (e.g., sum all sales) |
| Latency target | < 10 ms | Seconds to minutes |
| Storage | Row-oriented (Postgres, MySQL) | Column-oriented (Parquet, Snowflake, BigQuery) |
| Schema | Highly normalised (3NF) to avoid duplication | Denormalised (star schema, OBT) for fast reads |
| Concurrency | Many small concurrent writers | Few heavy parallel readers |
Why the split? Running a massive analytics query (GROUP BY country, SUM(revenue)) against your production OLTP database is like asking a Formula 1 car to deliver groceries. It forces the database to scan the whole disk, locking up memory. Suddenly, real users can't log in to your app because the database CPU is locked at 100% processing your CEO's report.
The Solution: We replicate the app database (OLTP) into a separate warehouse (OLAP). The app stays fast for customers, and analysts can run giant queries independently.