Pre-aggregated rollups

The views here are tables, not files, but the idea is the same: compute the answer before anyone asks. A materialized view in PostgreSQL stores a query’s result and is recomputed in full by REFRESH MATERIALIZED VIEW; its docs note the data is “not always current”, and the CONCURRENTLY option lets readers keep querying during a refresh. Cube calls its version pre-aggregations: rollups declared in the data model, built by a background refresh worker into Cube Store (which keeps them as Parquet files in object storage) and matched to incoming queries automatically, so a query for revenue by month never reaches the warehouse.

Freshness is a refresh key. In Cube a rollup is rebuilt every hour by default, or when a cheap check such as SELECT MAX(created_at) FROM orders returns a new value, and partitioned rollups can refresh only the last few months. In rollup-only mode Cube answers only from rollups, so the warehouse can stay suspended between refreshes.

Pick it for analytics with a known set of measures and dimensions over large data. Avoid it for one-off exploration, where every query has a new shape and no rollup matches.