Building interactive dashboards directly from a single Parquet file eliminates need for separate database

The demo shows a drilldown dashboard that reads directly from a single Parquet file stored in object storage. No traditional database or query engine is involved; the browser uses Hyparquet to issue range requests. A Cloudflare Worker proxies those requests and caches byte ranges at the edge. This shifts the analytical workload from backend services to the client and the edge layer.

Creating the cube requires a preprocessing step that computes all needed grouping sets and writes them into one Parquet file. The file must be sorted so that min/max values in each row group allow efficient pruning. Storage cost is limited to the size of the cube, which in the example is about 40 MB for 34 million rows. The only additional runtime cost is the edge worker that handles range requests and caching.

Because the dashboard relies on pre-computed aggregations, it can answer only the questions covered by the grouping sets in the file. Any ad-hoc filter or measure not present in the cube would require scanning more row groups or falling back to a full query engine. The method assumes the data is immutable; updates would necessitate rewriting the whole cube. Thus the approach is less suited for rapidly changing datasets or exploratory analytics.

Performance depends on the layout of row groups and the effectiveness of the edge cache; if the sorting is poor, each request may need to fetch many row groups, increasing latency and bandwidth. Very large cubes that exceed typical edge cache sizes could cause repeated fetches of the same data, diminishing the speed advantage. In such cases, a traditional backend with indexing might regain parity.