Logic Registry & Deploy
What it is
Section titled “What it is”Every compute cell you deploy lives in a system-managed registry inside the catalog, alongside your tables. You don’t build a container image, push to a registry, update a manifest, or wait for a rolling update — you run a single SQL statement and the new logic is live or staged atomically, with versioning baked in.
The registry tracks the compiled WebAssembly bytes, a content hash, the input
and output schemas, the list of tables the cell may access, who deployed it, and
how traffic should split across versions. Because the registry is a catalog
object, every change is transactional and historically queryable — you can ask
what version 3 of calculate_tax looked like last Tuesday the same way you’d ask
a historical question of any table.
Why it matters
Section titled “Why it matters”The traditional path from “I edited a function” to “it’s running in production” is several tools and minutes of partial unavailability. The cell registry makes it one statement and a few milliseconds.
- Zero-downtime promotion — staged versions go live atomically; in-flight requests on the old version finish cleanly.
- Instant rollback — reverting to a prior version is a pointer swap, not a redeploy.
- Schema-safe by construction — a deploy is rejected if the cell’s declared types don’t match the table’s actual columns.
- Canary traffic splitting — route 5%, 25%, or 100% to a new version with one statement.
- Auditable — every deploy, promote, and rollback is recorded in catalog history.
flowchart LR classDef s fill:#1f2640,stroke:#9ca3af,color:#e8eaf0 classDef a fill:#1f2640,stroke:#7c5cff,color:#e8eaf0 classDef g fill:#1f2640,stroke:#4ade80,color:#4ade80 DEPLOY[DEPLOY CELL] --> STAGED[staged]:::s STAGED -->|PROMOTE| ACTIVE[active]:::g STAGED -->|ROUTE WEIGHT n| CANARY[canary<br/>n% traffic]:::a ACTIVE -->|PROMOTE newer| RETIRED[retired]:::s CANARY -->|ROUTE WEIGHT 100| ACTIVE ACTIVE -->|ROLLBACK| RETIRED RETIRED -->|ROLLBACK TO| ACTIVE
How you use it
Section titled “How you use it”A typical workflow: deploy a new version as staged, send a slice of traffic to it as a canary, then promote it when confident — or roll back instantly if something looks wrong.
-- 1. Push a new version. Status begins as 'staged'.DEPLOY CELL calculate_tax VERSION 2 FROM '/build/calculate_tax_v2.wasm' ON orders;
-- 2. Send 10% of invocations to v2, keep 90% on v1.ROUTE CELL calculate_tax VERSION 2 WEIGHT 10;
-- 3. Watch dashboards. Looks healthy? Cut all traffic over.PROMOTE CELL calculate_tax VERSION 2;
-- 4. Something wrong? Instant revert.ROLLBACK CELL calculate_tax TO VERSION 1;
-- Inspect what's deployed:SELECT name, version, status, traffic_weight, deployed_at, deployed_byFROM _sys_logic_registryWHERE name = 'calculate_tax'ORDER BY version DESC;Note the schema-coupling guarantee: if v2 of calculate_tax expects a
tax_rate FLOAT64 input but the orders table has tax_rate DECIMAL128, the
DEPLOY is rejected with a clear error pointing at the column and the mismatch.
Logic and schema can never silently drift apart.
Lifecycle states
Section titled “Lifecycle states”| State | Meaning |
|---|---|
| Staged | Deployed but not yet receiving traffic — useful for warm-up or pre-promotion checks. |
| Active | Receiving all (or the bulk of) production traffic for that cell name. |
| Canary | A staged version receiving a fractional share of traffic via ROUTE … WEIGHT. |
| Retired | A prior version, no longer active but still in the registry — available for instant rollback. |
Each version also records a table grant (the explicit list of tables it may read or write, enforced at call time) and a signature (its input/output types so SDKs can call it without code generation).