In-Database Compute
In-Database Compute moves your logic to your data. Instead of pulling rows out to an application server, transforming them, and sending results back, you deploy a WASM compute cell that runs inside the database, directly against the table’s data, and returns only the final answer.
Cells are sandboxed WebAssembly modules you write in any language that compiles to WASM. They’re first-class catalog objects — versioned, schema-checked, and managed entirely in SQL. This is not an experimental path: compute cells are the primary execution path for lowerable queries (Scan → Filter → Project → Limit), with automatic fallback to the standard executor for anything they can’t express.
Why it matters
Section titled “Why it matters”The expensive part of most data work isn’t the computation — it’s shipping rows back and forth between the database and an app server to do it. Running your logic inside the database, next to the data, deletes that round trip entirely, and deploys it as a versioned catalog object instead of a service you operate.
- Move the code, not the data — a cell runs against the table’s data and returns only the answer; no bulk extract-transform-load back and forth.
- Deploy in SQL, roll back instantly — cells are versioned catalog objects with canary rollout and pointer-swap rollback; no containers or rolling restarts.
- Any language that compiles to WASM — write logic in the language you like; it runs sandboxed and schema-checked.
How fast it is
Section titled “How fast it is”- Seconds → milliseconds for network-bound work. For logic that would otherwise pull rows out to an app server, keeping it in-process removes the transport latency that dominated the wall-clock.
- Warm after first call. The engine caches an instantiated cell, so repeated invocations skip start-up cost.
The pages in this section
Section titled “The pages in this section”- WASM Compute Cells — the programming model: how to
write a cell, deploy it, and invoke it with
CELL(...)from SQL. Start here. - Cellular Compute Substrate — the transparent, on-by-default path that runs your ordinary queries as cells, with per-connection compute and automatic fallback.
- Logic Registry & Deploy — the deploy lifecycle:
DEPLOY,ROUTE,PROMOTE, andROLLBACK CELL, with versioning and canary rollouts — no containers or rolling restarts. - Logic Loom — stitch several cells across several tables into one atomic, deadlock-free flow with saga-style compensation.
- Compute Push — ship cell bytecode to where the data lives across a cluster instead of pulling rows back to a coordinator.
Each feature page carries an availability badge (Stable / Opt-in / Beta / Roadmap) so you always know what’s production-ready and what’s still evolving.