An OLAP cube is a multidimensional data structure that pre-aggregates measures across hierarchical dimensions, designed to answer analytical questions in milliseconds without scanning the raw fact table. Cubes were the standard OLAP architecture from the 1990s through the early 2010s, exemplified by Arbor Software's Essbase (1992) and Microsoft Analysis Services (1998). Columnar OLAP engines run the same workloads on columnar storage without the pre-aggregation step, computing aggregates on demand from a flat fact table.
How OLAP cubes work #
An OLAP cube stores measures (revenue, units, count) pre-aggregated across the intersections of multiple dimensions (time, geography, product). At build time, the cube engine reads the underlying fact table and computes every combination of dimension values that the analyst might query. At query time, those answers are looked up rather than computed. The result is millisecond response on questions the cube anticipated, at the cost of a build step that can run for hours and a storage footprint that grows exponentially with dimension count.
Cubes are queried in MDX (Multi-Dimensional eXpressions), the multidimensional analogue to SQL, standardised by Microsoft in 1997. MDX expresses queries like SELECT [Measures].[Revenue] ON COLUMNS, [Geography].[Country].Members ON ROWS FROM [Sales], with axes for the cube faces rather than rows and tables. Most analysts encountered MDX through Excel PowerPivot or Cognos rather than writing it directly.
Components of an OLAP cube #
The cube model has four canonical components, each named in E.F. Codd's 1993 paper Providing OLAP to User-Analysts and stable across vendor implementations since.
- Dimensions. The axes along which data is sliced: time, geography, product, customer, channel. Each dimension carries a hierarchy.
- Measures. The numeric values aggregated inside the cube, such as revenue, units sold, click count, and order value. Measures are usually summed or averaged across dimension intersections.
- Hierarchies. Ordered levels within a dimension (year → quarter → month → day, or country → region → city). Hierarchies define drill-down and roll-up paths.
- Aggregates. Pre-computed cells at every combination of dimension levels. Aggregates are the storage the cube buys speed with.
Aggregates explode geometrically with dimension count. A cube with five dimensions of average cardinality 100 and one measure stores roughly 100⁵ = 10 billion pre-aggregated cells before any sparsity optimisation. Real-world cubes apply sparse encoding and aggregation-skip heuristics, but the underlying combinatorics is why cube builds run for hours and why adding a new dimension is a multi-day exercise.
Are OLAP cubes still used? #
Yes, but only in narrow scenarios. OLAP cubes still ship inside large enterprises with legacy Essbase or Microsoft Analysis Services deployments, in MDX-driven Excel PowerPivot workflows, and in specific regulatory or financial-close workloads where the determinism and auditability of pre-aggregated numbers matters. They are not the default choice for new analytical systems in 2026.
The shift accelerated as columnar engines (ClickHouse, DuckDB, Snowflake, BigQuery) made on-demand aggregation fast enough that pre-aggregation became friction more often than benefit. Materialised views, available in every major columnar engine, fill the narrow niche where pre-aggregation is still preferred.
The cube market as of 2026:
| System | Status (2026) | Primary use today |
|---|---|---|
| Oracle Essbase | Active, legacy customer base | Financial close, regulatory reporting |
| Microsoft Analysis Services (SSAS) | Active, on-prem and Azure | Enterprise BI, Excel PowerPivot integration |
| Pentaho Mondrian | Maintenance | Open-source MDX-over-relational layer |
| Apache Kylin / Kyligence | Active, niche | Cube-on-Hadoop pre-aggregation |
| Atoti | Active, niche | In-memory cubes for financial services |
How OLAP cubes differ from columnar OLAP #
OLAP cubes and columnar OLAP take opposite approaches to the same problem. Cubes pre-aggregate at build time and look up answers; columnar engines store raw fact data and aggregate on demand through vectorised execution. The original argument for cubes was that lookup beat scan-and-aggregate on pre-anticipated queries. That gap has closed. Columnar engines compute aggregations on demand fast enough for most workloads, and the cases that still benefit from pre-aggregation are covered by materialised views inside the columnar engine. Columnar OLAP matches cube latency on the queries cubes were optimised for and handles any other query the fact table can answer.
| Dimension | OLAP cube | Columnar OLAP |
|---|---|---|
| Aggregation timing | Build time (hours) | Query time (sub-second) |
| Storage | Pre-aggregated cells (C^N) | Compressed columns of raw fact table |
| Schema change cost | Full rebuild | Add a column, no rebuild |
| Question flexibility | Pre-defined dimensions only | Any column the fact table contains |
| Query language | MDX | SQL |
| Canonical engines | Essbase, Microsoft SSAS, Mondrian | ClickHouse, Snowflake, BigQuery |
The cube model still describes the analytical vocabulary: drill-down, roll-up, slice, dice, pivot. Those terms originated with cubes and persist in columnar OLAP, where each one maps to a SQL pattern. The dedicated OLAP operations breakdown covers each one with SQL examples on a star schema. For why columnar storage is fast enough to make the cube layer redundant, see why columnar databases are fast.
Common misconceptions about OLAP cubes #
- OLAP cubes are three-dimensional. They are n-dimensional. The "cube" name is a metaphor; production cubes routinely carry 8 to 20 dimensions, which a 3D visualisation cannot represent.
- Cubes and OLAP databases are the same thing. They are not. An OLAP database is the broader category; an OLAP cube is one historical implementation of OLAP. The cube was the standard implementation in the 1990s–2000s; columnar databases are the standard implementation today.
- Columnar databases pre-aggregate everything. They do not. Columnar engines aggregate on demand by default. Materialised views in ClickHouse, Snowflake, and BigQuery handle the cases where pre-aggregation is still preferred; those are the cube-shaped optimisation inside an otherwise on-demand engine.
