Learning Objectives
- Distinguish data warehouses, data lakes/lakehouses, and real-time OLAP engines by what each is optimized for
- Place a described analytics need into the right category of system
- Explain what makes a system "real-time" OLAP as opposed to a traditional data warehouse
Why This Matters
Pick a data warehouse for a workload that needs sub-second freshness — a live fraud-monitoring dashboard, say — and you'll be explaining to your team why the fraud already happened by the time the report caught up. Pick a system built for that kind of freshness for a workload that's really petabyte-scale, ad-hoc business reporting across a sprawling set of tables, and you'll hit walls a warehouse would have sailed through. The "analytics database" category isn't one thing. Knowing which of its three major shapes you're actually looking at is what separates picking a tool by name recognition from picking it by fit.
Analogy
Think about three different ways a city might store and give people access to physical books and documents.
A public research library catalogs everything carefully — Dewey decimal numbers, shelf locations, a search index. New arrivals get processed, bound, and shelved before they show up on the catalog, which might take a few days. But once something's in, it's beautifully organized and you can cross-reference it six ways.
A self-storage facility lets anyone drop off boxes of anything, immediately, in whatever container they arrived in — no cataloging required. It's cheap and it never turns anything away. The tradeoff: finding a specific document later means digging through boxes yourself.
A newsstand restocks constantly, all day, with whatever's fresh right now. It's not trying to hold a hundred years of archives — it's built so you can walk up and get today's paper the moment it's printed, and it can serve a long line of people doing exactly that, all day long.
All three are "places that store documents for later retrieval." They are not the same kind of place.
Three shapes of analytics database
The library is a data warehouse: Snowflake, BigQuery, Redshift. Data arrives through a scheduled pipeline — extracted from operational systems, transformed into a clean structure, loaded on a batch cadence (hourly, nightly). Once it's in, it's well-structured and built for complex, exploratory SQL across huge historical datasets: "revenue by region by quarter, sliced eleven different ways." The tradeoff for that structure is time: there's usually a real gap, often hours, between something happening and it showing up queryable in the warehouse.
The self-storage facility is a data lake, and increasingly, a lakehouse. A data lake stores raw data cheaply, in open file formats, on object storage — no schema required up front, "figure out the structure later, when someone actually needs it." That flexibility used to come at a cost: data lakes traditionally lacked the transactional guarantees and query performance of a warehouse. A lakehouse adds those back — schema enforcement, transactions, fast queries — on top of the lake's cheap, open storage, aiming to get warehouse-like reliability without giving up the lake's flexibility and cost.
The newsstand is real-time OLAP: ClickHouse, Apache Druid, Apache Pinot. These are built for continuous ingestion — data becomes queryable within seconds of arriving, not hours — and for serving that data to dashboards and applications that need sub-second answers, often to many people or systems at once. They're not usually where a finance team goes to do freeform, ad-hoc exploration across a decade of history. They're where you put the metric that has to be live right now.
A worked example
A finance team needs to close the books every month and slice two years of historical revenue by region, product, and channel, every which way, in ad-hoc SQL. That's a data warehouse — structured, batch-loaded, built for deep exploratory queries over a large historical set.
A data science team is capturing raw clickstream events as JSON and doesn't yet know which fields will matter for the model they're building next quarter. That's a data lake — dump it now, cheaply, in its raw shape, decide the structure later.
A trust-and-safety team needs a dashboard showing fraud signals updating within seconds of each transaction, viewed continuously by a dozen analysts at once. That's real-time OLAP — continuous ingestion, sub-second queries, built to serve live traffic, not archival depth.
Three real needs. Three different shapes of database. None of them is a worse version of the others — they're not competing on the same axis.
Common Misconception
"Real-time OLAP is just a faster, more expensive data warehouse — throw enough money at a warehouse and you'd get the same thing."
Raw speed isn't the only thing separating these categories. A data warehouse is architected around a batch pipeline: data lands, then gets transformed and loaded on a schedule. Making that pipeline run more often doesn't turn it into a system built for continuous, row-by-row ingestion serving dashboards to many concurrent users at sub-second latency — that's a different shape of workload from ad-hoc BI exploration, and it calls for a different architecture, not just a bigger budget on the same one.
Predict, Then Verify
For each of these, predict: data warehouse, data lake/lakehouse, or real-time OLAP?
- A marketing team wants to explore five years of campaign performance data with complex, unpredictable ad-hoc queries.
- An IoT company is capturing raw sensor readings in whatever format each device happens to send, without yet knowing which fields they'll need.
- An ad exchange needs a bidding dashboard that reflects auction results within a second or two of each auction closing.
Reveal the answer →
- Data warehouse — deep, unpredictable, ad-hoc exploration over a large historical set is exactly what warehouses are built for.
- Data lake — raw, varied, schema-not-yet-decided data, captured cheaply now.
- Real-time OLAP — continuous ingestion, sub-second freshness, serving a live dashboard.
Summary
The analytics database world splits into three major shapes: data warehouses, built for deep, structured, batch-loaded exploration; data lakes and lakehouses, built for cheap, flexible, schema-later storage of raw data; and real-time OLAP engines, built for continuous ingestion and sub-second queries served to live dashboards and applications. They differ in how fast data becomes queryable, how much structure they demand up front, and what kind of query they're built to answer well. You can now place a described analytics need into the right one of these three categories — and explain why "just make it faster" doesn't turn one into another.
Quiz
1. A team wants to run unpredictable, complex ad-hoc SQL queries across five years of well-structured historical sales data. Which category of system is this, and why?
2. Why does a data lake typically require little to no upfront schema, while a data warehouse does?
3. What specifically makes a system 'real-time OLAP' rather than just 'a fast data warehouse'?
4. A lakehouse adds which capabilities on top of a traditional data lake's cheap, open storage?
5. A team's data warehouse is technically capable of running the query behind their live fraud-monitoring dashboard, but the dashboard consistently shows fraud patterns that are hours old by the time analysts see them. What's the most likely explanation?