Functions & Procedures

WASM CellsGit-NativeSandboxed

Stable On by default · production-ready

What it is

AetheriusDB does not accept stored-procedure source code. There is no CREATE FUNCTION my_logic(...) AS $$ ... $$, no procedural language inside the database, and no in-process source compiler. Instead, you author your logic as ordinary code in a Git repository, your CI pipeline compiles it to a WebAssembly module, and the database accepts the compiled bytes via a single deploy statement keyed to the Git commit ID.

Once deployed, that module — a compute cell — runs inside a sandboxed runtime with strict CPU and memory quotas. It reads column data, executes against it, and writes results back without any data leaving the engine.

Why it matters

This is a deliberate inversion of how traditional databases handle procedures, and the benefits are concrete: business logic gets normal code review, lives in source control, runs through your test pipeline, and rolls back like any other commit. The database itself stays secure and simple — no parser for a procedural language, no runtime for arbitrary source.

Source-of-truth is Git — the deployed artefact is identified by its commit ID, so any production cell traces back to its exact source.
Multi-language — anything that compiles to WebAssembly works: Rust, AssemblyScript, C, TinyGo, Zig.
Sandboxed by construction — cells run with bounded memory, a CPU “fuel” budget that traps runaway loops, and no filesystem or network access unless policy explicitly grants it.
Runs in parallel — a cell mapped over a large table is run across all available cores.

How you use it

The lifecycle has two halves. The first — write code, run tests, compile — happens in your repo and CI pipeline like any other software project. The second — register, invoke — happens in SQL.

-- (1) In your repo: write the logic in any language that targets WASM,
--     e.g. a Rust function `score(row) -> f64`.
-- (2) In CI: build the .wasm module, sign it, and tag it with the Git commit ID.

-- (3) In SQL: deploy the compiled bytes. No source ever crosses this line.
DEPLOY CELL risk_score
  COMMIT '9f3c8a1e'
  FROM BYTES :wasm_bytes
  SIGNATURE :ed25519_sig;

-- (4) Use the cell in queries like any built-in scalar function.
SELECT account_id, CELL(risk_score, txn_history) AS score
FROM   accounts
WHERE  active = TRUE;

-- (5) Pin policy: how much fuel, how much memory, how much isolation.
ALTER CELL risk_score
  SET fuel_budget = 10_000_000,
      memory_pages = 64,
      isolation = 'process';   -- 'thread' is the default

-- (6) Roll back by deploying the previous commit's artefact.
DEPLOY CELL risk_score
  COMMIT 'b1d2e7f0'            -- the previous good version
  FROM BYTES :prior_wasm_bytes
  SIGNATURE :prior_sig;

The cell becomes a normal scalar (or aggregate, or table-valued) function in SQL. The planner inlines it into the query and invokes it per batch of rows.

Key concepts

Concept	What it means
Compute cell	A pre-compiled WebAssembly module deployed into the database, addressable by name.
Commit ID	The Git commit hash that produced the deployed bytes — the identity of the artefact.
`DEPLOY CELL`	The single statement that registers compiled WASM bytes.
Fuel budget	A bounded execution allowance — a runaway loop is trapped when its fuel runs out.
Isolation level	Thread-level (default) or process-level for high-risk logic that touches external systems.

Compute & WASM Cells →

A deeper look at the sandbox runtime and execution model.

Catalog & Metadata →

The system tables where deployed cells are recorded.

Security →

Signatures, isolation, and the sandbox security model.