Core concepts

These are the nouns the rest of the documentation uses. Read this once and the other pages will make sense in any order.

Indexer#

The top-level object you create and own. An indexer holds the connection settings — which validator to stream from, at what commitment level, and which PostgreSQL database to write to — plus the canvas that defines what it actually does. One indexer becomes one running worker.

Canvas#

The visual definition of the pipeline: a graph of nodes joined by edges. The canvas is freely editable and autosaved. Editing it changes nothing about what is currently running — only a deploy promotes the canvas into something live.

Nodes#

The components you place. Two of them — Program and Database — are put there for you and cannot be deleted; they are the entry and exit of the pipeline. The rest you drag from the palette. See the node reference.

Edges#

A wire from one node's output handle to another's input. An edge is the data mapping: dragging from an instruction's amount field to a table's amount column is the whole instruction to write one into the other. Which connections are legal is enforced as you draw them.

Transform#

A block of AssemblyScript that takes named inputs and returns named outputs. It is compiled to WebAssembly in your browser, and the resulting module runs inside a sandbox in the worker. Transforms exist for the cases where a straight field-to-column wire is not enough — arithmetic, string formatting, deriving one value from several.

Trigger#

A side channel out of the pipeline. A webhook POSTs a JSON payload to a URL you own; a WebSocket trigger broadcasts it to a live topic your clients can subscribe to. Both are optional and independent of the database writes. A trigger condition can gate either one so it fires only on the events you care about.

Version#

An immutable snapshot taken at deploy time: the transform source and compiled Wasm, the program and instruction filters, the triggers, the database schema, the generated DDL, and the platform runtime it ran on. A version is never edited — a change produces a new one. This is what makes rollback meaningful. See versions & rollback.

Runtime version#

A separate, platform-owned concept, labelled “Indexer Version” in the UI. Your version records what runs; the runtime version records how it runs — the worker image and the Wasm ABI your compiled transform has to satisfy. You pin one when you create an indexer.

Deployment#

One attempt to make a version live. It runs a series of preflight checks, then dispatches a command to the orchestrator, which starts or replaces your worker pod. See deploying.

Worker pod#

The isolated container that actually does the work: it holds the validator stream open, decodes matching transactions, executes your Wasm, writes to your database, and fires your triggers. It is yours alone — not shared with other tenants — and it is what consumes credits while it runs.

The two databases#

This distinction causes more confusion than anything else on the platform, so it is worth being explicit:

• The platform database stores your account, your indexers, your canvases and your version history. You never connect to it.
• Your database is the PostgreSQL you supplied. It receives the decoded rows and nothing else. Syncro creates and migrates the tables your canvas defines, and touches nothing it did not create.