WASM Compute Cells

WASMComputeIn-Database

Stable On by default · production-ready

What it is

A Compute Cell is a compiled WebAssembly module that AetheriusDB treats as a first-class database object — registered in the catalog right next to your tables and indexes. When you invoke a cell, it runs inside the database, directly against the table’s data, and returns a result. No SQL is re-parsed, no rows make a network round-trip out to your application and back.

You write a cell in any language that targets WebAssembly — Rust, AssemblyScript / TypeScript, Go, C / C++. A cell is fully sandboxed: it cannot open files, make network calls, or read data it wasn’t granted access to. Each call runs with a strict budget, so a runaway loop aborts cleanly instead of stalling the engine. Think of cells as a modern, polyglot, memory-safe replacement for stored procedures.

Compute cells are the primary execution path for lowerable queries (Scan → Filter → Project → Limit). Anything a cell can’t express falls back to the standard executor with identical results.

Why it matters

A typical “fetch and transform” round-trip in a modern stack crosses several serialization boundaries and a network hop or two before your logic ever sees the data. A cell collapses that: the logic runs where the data lives and returns only the final answer.

• No serialization tax — the cell reads the table’s values directly instead of receiving a materialized, boxed row per call.
• Language freedom — write business logic in the language your team already uses, compiled to one portable .wasm artifact.
• Hard isolation — a buggy cell cannot crash the engine or read another table’s data.
• Abort-safe — a cell’s writes are staged and only applied if it returns successfully; a failure discards them with no half-written state.

flowchart LR
  classDef a fill:#1f2640,stroke:#7c5cff,color:#e8eaf0
  classDef b fill:#1f2640,stroke:#00d4ff,color:#e8eaf0
  classDef g fill:#1f2640,stroke:#4ade80,color:#4ade80

  A[App]:::a --> B[CELL invoke]:::b --> C[Cell runs on<br/>the table's data]:::b --> D[Result]:::g

How you use it

Compile your code to .wasm, deploy it as a cell, then call it from SQL. Here’s a fraud-scoring cell deployed against a transactions table, and how you invoke it.

-- Deploy a cell. The engine validates that the cell's declared input
-- schema matches the columns of the target table.
DEPLOY CELL fraud_score
  VERSION 1
  FROM '/build/fraud_score.wasm'
  ON transactions
  RETURNS DOUBLE;

-- Invoke it per-row inside a normal SELECT.
SELECT
  txn_id,
  amount,
  CELL(fraud_score, ROW(txn_id, amount, merchant_id)) AS score
FROM transactions
WHERE ts >= NOW() - INTERVAL '1 hour'
  AND CELL(fraud_score, ROW(txn_id, amount, merchant_id)) > 0.85;

Because the cell sees the table’s values directly rather than a materialized row object, per-row cost is dominated by your code, not by executor overhead.

The cell contract

A cell is a small, stateless function with a clear contract:

• It sees the table’s data. The engine hands the cell a view over the rows it’s processing; the cell reads the columns it declared as inputs.
• It returns a result. A scalar for a per-row CELL(...) call, or a table shape when you declare RETURNS TABLE(...).
• Its writes are staged. Any changes a cell makes are held until it returns successfully; if it fails or exceeds its budget, the staged changes are thrown away — there is no partial write to clean up.
• Its access is explicit. A cell can only touch the tables it was granted at deploy time; reaching anywhere else traps immediately.
• It carries a signature. A cell records its input and output types, so client SDKs can call it without code generation.

Packs, versions, and lifecycle

A cell is more than a bare .wasm file. You can bundle the bytecode together with its manifest (input/output schema, target tables) into a single pack artifact and deploy that instead — the same artifact works whether you deploy from the SQL REPL or push it from CI/CD. Every deploy is content-addressed, so re-uploading identical bytes is free.

Once deployed, a cell is versioned and managed entirely in SQL — DEPLOY, ROUTE, PROMOTE, ROLLBACK, and DROP CELL — with no containers or rolling restarts. See Logic Registry & Deploy for the full lifecycle.

DROP CELL is final

DROP CELL removes every version from the registry, including retired versions you’d otherwise keep for rollback. To take a cell out of service without losing its history, route traffic away from it instead of dropping it.

Notes & caveats

Pre-warm on hot paths

The engine caches an instantiated cell after its first call. For latency-sensitive paths, fire one synthetic invocation at startup so the cell is hot before the first real request arrives.

No external calls from a cell

A cell has no filesystem, no sockets, and no clocks. If your logic needs to call an external API (a payment gateway, say), that belongs in an orchestration flow around the cell — see Logic Loom — not inside the cell itself.

Logic Registry & Deploy →

Deploy, version, canary, and roll back cells with SQL verbs.

Cellular Compute Substrate →

The transparent execution path ordinary queries route through.

Functions & Procedures →

The relational logic layer cells extend and replace.

Quickstart →

Deploy your first cell end-to-end in 15 minutes.