Schema & migrations

Designing destination tables, generated DDL, and the destructive-change gate.

The tables on your canvas are the schema of your own database. When you deploy, Syncro works out the difference between what your canvas describes and what your database currently has, and applies the migrations needed to close the gap.

Column types#

Postgres Table nodes offer the types that map cleanly to decoded on-chain data:

Available column types
Field	Type	Description
VARCHAR	text	Bounded text. The usual choice for signatures and public keys.
TEXT	text	Unbounded text, when you would rather not pick a limit.
BIGINT	integer	64-bit signed. Fine for slots and counts; not safe for an unsigned u64 that can exceed its range.
INTEGER	integer	32-bit signed, for small counters and enum-like values.
NUMERIC	exact decimal	Arbitrary precision. The right home for token amounts — no rounding, no overflow.
BOOLEAN	bool	Flags decoded from account or instruction data.
JSONB	json	Structured output from a transform. Build the JSON string yourself and let Postgres parse it.
TIMESTAMPTZ	timestamp	Block times and derived timestamps, with a timezone.
UUID	uuid	For your own identifiers. Not for public keys — those are base58 strings.
BYTEA	bytes	Raw byte arrays kept in their binary form.

How migrations are applied#

Each deploy generates the DDL for your current schema and compares it against what has already been applied to your database. Only the difference runs. Adding a table or adding a nullable column is uneventful — new objects are created, existing data is untouched.

Syncro only ever manages the tables it created. Other tables in the same database are not inspected, not migrated, and not dropped.

Working around a destructive change#

If you do not want to lose the old data, the usual pattern is to add the new column alongside the old one, deploy, backfill in your own database at your own pace, and only then remove the old column in a later deploy.

Importing an existing schema#

If your tables already exist, or you would rather write SQL than click columns, use Import SQL Schema on the Database node. Paste CREATE TABLE statements and Syncro creates matching table nodes wired to the Database node.

schema.sql

SQL

CREATE TABLE token_swaps (
  id          BIGSERIAL PRIMARY KEY,
  signature   VARCHAR(128) NOT NULL,
  owner       VARCHAR(64)  NOT NULL,
  amount      NUMERIC       NOT NULL,
  occurred_at TIMESTAMPTZ   NOT NULL
);

You still need to wire fields into the imported columns — the import gives you the destination, not the mapping.

Practical advice#

Store the signature. It is the only reliable way to trace a row back to the transaction that produced it.
Use NUMERIC for token amounts. Lamport values and SPL amounts are unsigned 64-bit and will outgrow BIGINT.
Add your own indexes. Syncro creates the tables and columns your canvas defines; tuning the read side is yours to do, in your own database, whenever you like.
Expect duplicates to be possible. A redeploy or a stream reconnection can replay an event. If exactly-once matters, add a unique constraint on something stable, such as the signature plus an index.