WASM Compute Cells

WASMComputeIn-Database

Stable On by default · production-ready · Deploy, versioning and transparent query execution are on by default — see Status below for the parts still landing

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. A cell runs inside the database, directly against the table’s data. 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.

Status: what runs today

Cells span a management plane (deploy, version, govern) and an execution plane. Those landed at different times, so this page marks each capability explicitly rather than implying the whole surface is finished.

Capability	Status
Transparent query-path execution — computed projections, filters and aggregates compiled into a cell	Stable, on by default
DEPLOY CELL — from a path, from inline bytes, or from Git at a pinned commit	Stable
Versioning: PROMOTE / ROUTE … WEIGHT / ROLLBACK / DROP CELL	Stable
Cell sandbox — GRANT … TO __cell__ gates which tables a cell may touch	Stable
Write-transform on INSERT — a cell computes values, the engine still enforces every constraint	Implemented, bound internally; no SQL binding syntax yet
Explicit invocation returning your cell’s computed result	Not yet executable — the call dispatches, but the deployed-cell runtime is still a stub

Explicit invocation is not live yet

Deploying, versioning and governing cells works today, and the engine really does compile eligible queries into cells. What is not wired yet is calling a deployed cell and getting its logic back — that path currently returns a placeholder value regardless of the module you deployed. Build against it in development, but don’t put it on a production path until this page says otherwise.

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.
• Versioned like code — deploy straight from a Git commit, and the exact repository and commit stay recorded with the deployed cell.

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 invoked]:::b --> C[Cell runs on<br/>the table's data]:::b --> D[Result]:::g

How you use it

Compile your code to .wasm, then deploy it as a cell. These are the statements the engine accepts today.

Deploy from a build artifact

-- Deploy a cell from a local .wasm file.
--   INPUTS       names the columns passed to the cell, in order.
--   ACCESS       the only tables this cell may touch (see the sandbox below).
--   FUEL_BUDGET  aborts a runaway cell.
--   MEMORY_LIMIT caps the cell's linear memory, in bytes.
DEPLOY CELL fraud_score
  FROM '/build/fraud_score.wasm'
  INPUTS (txn_id, amount, merchant_id)
  ACCESS transactions
  FUEL_BUDGET 1000000
  MEMORY_LIMIT 65536;

Deploy from Git — versioned, pinned, reproducible

This is the recommended path for anything you intend to keep. You give the engine a repository and an exact commit; it clones that commit, builds the WebAssembly artifact, and records the origin alongside the deployed cell — so every cell in the catalog traces back to an immutable point in your history.

-- Clone, check out that exact commit, build, and deploy.
-- The repository URL and the 40-character commit SHA are stored with the cell.
DEPLOY CELL fraud_score
  FROM GIT 'https://github.com/acme/cells.git'
  AT COMMIT 'a1b2c3d4e5f60718293a4b5c6d7e8f9012345678'
  INPUTS (txn_id, amount, merchant_id)
  ACCESS transactions;

The commit must be a full 40-character hex SHA — a branch or tag name is rejected, because a moving reference cannot pin a build. The build host needs git and a Rust toolchain with the wasm32-wasip1 target installed.

You can also hand the engine bytes directly, which is convenient for CI systems that already built the artifact:

DEPLOY CELL fraud_score FROM BYTES '0061736d0100000001...';

Version, canary, and roll back

Every deploy creates a new version, staged and receiving no traffic until you say so.

-- Send 10% of invocations to v2, keep the rest on the current version.
ROUTE CELL fraud_score VERSION 2 WEIGHT 10;

-- Healthy? Cut everything over.
PROMOTE CELL fraud_score VERSION 2;

-- Something wrong? Go back.
ROLLBACK CELL fraud_score VERSION 1;

-- Remove every version of the cell.
DROP CELL fraud_score;

Grant the cell its data

A deployed cell reaches tables through a dedicated __cell__ role, not through the privileges of whoever called it. It starts with nothing, so a cell can touch no data until you grant it:

GRANT SELECT ON transactions TO __cell__;

Planned surface

The statements below are the target ergonomics for calling a cell inline. They are not implemented yet — the engine does not accept them today. They’re recorded here so you can see where the surface is heading.

-- Planned — not accepted by the parser today.
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;

Roadmap Planned · not yet usable · Inline CELL(...) invocation syntax

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.
• 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.
• It cannot skip your constraints. When a cell computes values on the write path, the engine still applies primary-key, unique, foreign-key and index maintenance to whatever the cell produced. A cell supplies values; it does not get to bypass the rules.
• Its access is explicit. A cell can only touch the tables it was granted at deploy time; reaching anywhere else traps immediately.
• It carries its origin. A cell deployed from Git records the repository and commit it was built from.

Notes & caveats

Pin to a commit, not a branch

FROM GIT … AT COMMIT deliberately refuses branch and tag names. A branch moves; a deployed cell must not. If you want “latest”, resolve the SHA in CI and pass that.

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.

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.