← Back to overview Architecture

Two paths, opposite profiles.

DataHashi is a control plane that compiles a Semantic Query to SQL and pushes execution down. The hot path never waits on the warehouse — the background path is what keeps it that way.

Two paths, opposite profiles The hot path answers user-facing queries in milliseconds from pre-aggregated Parquet rollups via an embedded DuckDB engine, never touching the warehouse. The background path runs durable, queued jobs that compile and execute against the warehouse to build and refresh those same rollups, keeping the hot path's data current without making any user wait. HOT PATH · sub-second, embedded Gateway Preagg route Compile DuckDB · Parquet the rollup store Response p99 ≤ 14ms BACKGROUND PATH · durable, async River queue Compile Execute Scan → Parquet writes the rollup the hot path reads
The background path is what keeps the hot path fast: it builds the exact Parquet rollups the hot path reads, on a schedule no user ever waits on.
Hot path

Sub-second, embedded

User-facing queries are answered from pre-aggregated rollups by an embedded DuckDB engine over Parquet — no warehouse token, no round-trip.

gateway→ preagg route→ compile→ DuckDB · Parquet
≤ 14msp99, served from rollup
Background path

Durable, async builds

Rollups are built and refreshed by durable jobs that do hit the warehouse — poll + push webhook + backstop keep them fresh. No user is waiting.

river queue→ compile→ execute→ scan → Parquet
statelessscale-out nodes, durable queue
See it end to end

Read the platform, then see a query run.

Architecture is one angle — the governed model and the join graph are what make the compiled SQL correct in the first place.

See the platform Console