Real-time petabyte analytics without DB impact

A production Public Cloud database instance is built for transactions, not analytics. When business teams start asking for real-time dashboards, fraud detection, or customer segmentation queries against terabytes of historical data… well, performance collapses.
That happens not so much because infrastructure is weak, but because the app is using the wrong tool for the job.

OLTP vs OLAP

OLTP (online transaction processing) and OLAP (online analytical processing) sit at opposite ends of the data architecture spectrum.

OLTP systems prioritize correctness and transaction-level precision, handling thousands of small, fast writes and reads per second.They store data row by row, optimized for looking up a single customer record or updating an order status in milliseconds.

OLAP systems, by contrast, are designed to scan trillions of rows for complex aggregations. They use columnar storage, where each column is stored independently. This means when you query SUM(revenue) WHERE date > '2025-01-01', the database reads only the revenue and date columns, skipping everything else. So, for example in ClickHouse, operations run in vectorized execution. ClickHouse processes entire arrays of values at once rather than individual rows, which dramatically reduces CPU overhead and maximizes cache utilization.

No amount of data indexing, query optimization, or hardware upgrades will make a row-oriented database efficient at columnar scans. The architectures are fundamentally different.

Why read replicas won't solve the problem

Read replicas in Public Cloud Databases are the most common first response to analytics pressure on production databases. They offload read traffic from the primary node, but they don't fix the architectural mismatch.

A read replica might reduce contention on your primary database, but when you run SELECT SUM(revenue), COUNT(*) FROM events WHERE date >= '2024-01-01' across 500M rows, the replica still reads and discards almost every row.

These analytics queries compete with production transactions for CPU, memory, and I/O. App latency rises, SLAs are at risk, and real-time use cases like fraud detection or anomaly monitoring become impossible.

The 40-second query that should take 200 ms

Here's the typical scenario for a SaaS scale-up or FinTech platform company hitting the data inflection point. A query runs, intended to aggregate daily revenue by customer segment over 18 months (500M rows),

The expected time for execution under the OLAP domain model is 200 ms, but the actual time under the OLTP platform ends up being 40 seconds. Why? Well this is what happens in the background:

• Full table scan : The PostgreSQL/MySQL platform must read all 500M rows because the index doesn't help with wide aggregations.

• Row-by-row processing : Each row is decompressed, parsed, and evaluated individually.

• I/O bottleneck: Disk reads dominate—most of the data read is discarded.

• CPU waste : CPU cycles spent on row parsing instead of aggregation quality.

• Memory pressure : Large sorts and hash joins spill to disk.

The business impact is immediate and compounding, because what should be an hourly data dashboard can, in practice, only be generated once a day, delaying business decisions.
Business decisions are delayed because minute-by-minute analytics becomes too expensive, and real-time features become impossible at scale.And that matters – real-time responsiveness is essential for use cases such as fraud detection, personalization, and anomaly monitoring. These use cases are not viable with 40-second query latency.