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, and the database accepts the compiled bytes via a single deploy statement — either built by the engine straight from a pinned Git commit, or handed over as bytes your CI already produced.

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 at all. A cell reaches tables only through the __cell__ role you grant 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, version, roll back — 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 SQL: deploy it, pinned to an exact commit. No source ever crosses
--     this line — the engine builds the module and records the origin.
--     The commit must be a full 40-character hex SHA; a branch or tag is
--     rejected, because a moving reference cannot pin a build.
DEPLOY CELL risk_score
  FROM GIT 'https://github.com/acme/cells.git'
  AT COMMIT 'a1b2c3d4e5f60718293a4b5c6d7e8f9012345678'
  INPUTS (account_id, txn_count, txn_total)
  ACCESS accounts
  FUEL_BUDGET 10000000
  MEMORY_LIMIT 4194304;

-- (3) If CI already built the artefact, hand the engine the bytes directly.
DEPLOY CELL risk_score FROM BYTES '0061736d0100000001...';

-- (4) Grant the cell its data. It reaches tables through the __cell__ role,
--     not through the privileges of whoever called it, and starts with none.
GRANT SELECT ON accounts TO __cell__;

-- (5) Every DEPLOY allocates the next version, staged and taking no traffic.
--     Canary it, promote it, and revert with a pointer swap.
ROUTE CELL risk_score VERSION 2 WEIGHT 10;
PROMOTE CELL risk_score VERSION 2;
ROLLBACK CELL risk_score VERSION 1;

Each version records the tables it may touch and the input columns it was declared against, so logic and schema cannot silently drift apart.

Planned surface

The intended ergonomics are that a deployed cell reads like a normal scalar (or aggregate, or table-valued) function in SQL, inlined by the planner and invoked per batch of rows. That syntax is not accepted by the engine today:

-- Planned — not accepted by the parser today.
SELECT account_id, CELL(risk_score, txn_history) AS score
FROM   accounts
WHERE  active = TRUE;

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

In the meantime, eligible queries are compiled into cells transparently by the cellular compute substrate — that path is on by default and needs no syntax at all.

Key concepts

Concept	What it means
Compute cell	A pre-compiled WebAssembly module deployed into the database, addressable by name.
Commit ID	The 40-character Git commit hash a cell was built from, recorded with the deployed version — the identity of the artefact.
DEPLOY CELL	The single statement that registers compiled WASM bytes, from a path, from Git at a commit, or from inline bytes.
Fuel budget	A bounded execution allowance (FUEL_BUDGET) — a runaway loop is trapped when its fuel runs out.
Memory limit	The cap on a cell’s linear memory in bytes (MEMORY_LIMIT).

Tip

Treat cell deployments as first-class CI artefacts: resolve the commit SHA in CI and let your deploy pipeline issue the DEPLOY CELL … FROM GIT … AT COMMIT statement. You get audit, rollback, and provenance for free.

No SQL introspection yet

There is no system table or SHOW CELLS statement for listing what is deployed. Track cell names and versions in your own deployment tooling; if you deploy from Git, the recorded repository and commit keep your release history authoritative.

Heads up

There is no CREATE FUNCTION ... AS $$ ... $$. If you try to submit procedural source text, the parser rejects it. This is intentional — the database is a bytes-execution surface, not a code-execution surface, and that distinction is what keeps the security model tractable.

Compute & WASM Cells →

A deeper look at the sandbox runtime and execution model.

Logic Registry & Deploy →

The deploy lifecycle: version, canary, promote, and roll back.

Security →

Grants, the __cell__ role, and the sandbox security model.