OLAP Cubes in the Modern Era

OLAP cubes — the MOLAP/ROLAP world of SSAS, Essbase, and Cognos TM1 — were built to solve a problem that no longer exists in quite the same shape: aggregating billions of rows fast enough for interactive slicing was hard on 2000s-era disk-based databases, so you pre-computed every rollup combination overnight into a cube and queried the cube instead of the raw fact table. Modern columnar warehouses changed the economics of that trade-off, but they didn't eliminate the underlying need — they just moved where the aggregation happens.

What a traditional cube actually is

A MOLAP cube pre-materializes aggregations across every combination of dimensions you define — region × product × time × customer segment, and so on — into a multidimensional structure optimized for fast slice-and-dice queries. ROLAP does the same conceptually but keeps the data in relational tables and computes aggregates via SQL rather than a proprietary storage engine. Both trade a slow, resource-heavy build process (the nightly cube processing job that data teams structured entire schedules around) for near-instant query response once built. The cost was rigidity: adding a new dimension or attribute meant reprocessing the cube, sometimes for hours, and cube-modeling tools like MDX were a specialized skill most analysts never learned.

What columnar, elastic-compute warehouses changed

BigQuery, Snowflake, and DuckDB store data in a columnar format and can scan and aggregate billions of rows in seconds by throwing parallel compute at the problem on demand, rather than requiring the aggregation to be pre-computed. A GROUP BY across region, product, and month that would have needed a pre-built cube in 2010 now just runs as a query, computed fresh, against the raw (or lightly modeled) fact table.

SELECT
  region,
  product_category,
  DATE_TRUNC('month', order_date) AS month,
  SUM(revenue) AS total_revenue,
  COUNT(DISTINCT customer_id) AS active_customers
FROM fact_orders
GROUP BY ROLLUP(region, product_category, month)
ORDER BY region, product_category, month;

ROLLUP and CUBE as SQL grouping operators give you the same multi-level subtotal behavior a MOLAP cube provided, computed on the fly against current data, with no separate processing job and no risk of the cube being stale relative to the source tables.

When pre-aggregation still earns its complexity

The on-demand approach isn't free — it costs compute every single query, and at genuinely large scale (tens of billions of rows, dashboards refreshed by hundreds of concurrent users) re-scanning and re-aggregating on every page load gets slow and expensive fast. This is where materialized views, dbt incremental models, or purpose-built pre-aggregation tools still make sense: compute the rollup once on a schedule, store the result, and serve dashboard queries against the small pre-aggregated table instead of the billion-row fact table.

Semantic layers: dbt metrics and Cube.js

What survived from the cube era isn't the storage engine — it's the idea of a single, governed definition of what "revenue" or "active customer" means, so five different analysts querying five different tools get the same number. dbt's metrics/semantic layer and tools like Cube.js fill that role now: you define a metric once, with its dimensions and aggregation logic, and BI tools query the semantic layer rather than reimplementing the SQL themselves. It's the cube's real contribution — a shared, versioned definition of business logic — decoupled from the rigid, slow-to-rebuild multidimensional storage that used to be required to get it.

Wrapping up

The OLAP cube as a physical, pre-processed structure is mostly gone from new architectures — columnar warehouses made on-demand aggregation fast enough that most teams don't need it. What replaced it is a split: raw compute-on-demand for the common case, targeted pre-aggregation for genuinely high-concurrency or high-volume dashboards, and a semantic layer to keep the business logic consistent across both. If you're evaluating whether you need a "cube" in 2026, the honest answer is usually that you need a semantic layer, and only sometimes that you need pre-aggregated tables underneath it.