How bridges work

A bridge is the saved sync path: a source, a column mapping, one or more destinations, and a trigger that decides when rows move. This page is the mental model — how a bridge turns into jobs and deliveries, what each trigger mode does, and what Syncle guarantees about what lands on the other side.

Bridges, jobs and deliveries

Three words carry everything here. A bridge is the configuration: the source (a table, optionally filtered and sorted, or a raw query on a connection), the transform, the destinations, and the trigger. A job is one execution of a bridge. A delivery is one row — or one batch, when batching is on — delivered within a job; it is the unit the live timeline shows and the unit you can retry or skip.

Every trigger funnels rows through the same delivery pipeline, so the timeline, retry controls and idempotency behave the same whether a row came from a one-shot replay, a poll, or a change event. Two knobs are narrower than that: batching applies to replay jobs only — watch and CDC always deliver one row per delivery — and the minDelayMs rate limit paces replay and watch deliveries but not CDC.

The three trigger modes

Replay

A replay bridge runs on demand: press Run job and it streams the source once, a page at a time, delivering every row (or the filtered subset). This is the mode for an initial backfill or a one-off migration, and it is the default for a new bridge.

Watch

A watch bridge polls the source on a cursor and delivers whatever is new. Polling works on every engine — including SQLite, which has no change log — so watch is the universal live mode. Three strategies decide what "new" means:

The watch trigger itself has three knobs: pollIntervalMs (1000–3600000, default 5000), startFrom (beginning or now, default now — which ignores existing rows and only delivers ones added after the watch starts), and maxPerPoll (default 500), which caps rows delivered per poll cycle as backpressure.

CDC

A CDC bridge streams changes from the database's own change log — real time, no polling: Postgres logical replication, MySQL binlog, MongoDB change streams, Redis keyspace notifications. You can subscribe to a subset of operations (insert, update, delete; default all three). SQLite has no change log, so CDC is not available there — use a watch bridge. Each engine has prerequisites and honest limitations, and the bridge builder runs a readiness check that lists anything missing; the CDC setup page covers all of it.

Delivery guarantees

Database writes are idempotent upserts keyed by columns you choose, using each engine's atomic upsert: ON CONFLICT on Postgres and SQLite, ON DUPLICATE KEY on MySQL, updateOne with upsert on MongoDB. Delivery is at-least-once end to end, and the keyed upsert is what turns that into an exactly-once result — a replayed, retried or redelivered row overwrites itself instead of duplicating. On a CDC bridge, inserts, updates and deletes all propagate; a delete routes to a keyed delete on the target. Watch bridges only surface what polling can see — the table above says which strategy detects what, and none of them detects deletes.

On relational targets a batch is written inside a transaction, so a retried batch is all-or-nothing. MongoDB and Redis have no transaction here; their retry safety comes from the per-row idempotent upsert and delete. Jobs checkpoint progress as they go, survive restarts, and auto-resume after a crash.

Database destinations

A database destination is a list of targets — one bridge can write to several at once. Each target is described by:

Auto-created tables use cross-engine type translation: each source column type is collapsed to a portable type (integer, bigint, number, boolean, timestamp, json, uuid, text — falling back to text) and rendered in the target engine's dialect, with keyColumns as the NOT NULL primary key and nothing auto-increment. The mapping preview in the builder renders exactly the mapping the runner performs.

HTTP destinations

Instead of a database, a bridge can POST, PUT or PATCH each row (or batch) to a URL, with optional headers and auth — none, a bearer token, or a custom header, with secrets encrypted at rest. An optional idempotency toggle adds an Idempotency-Key header derived from the job id plus a stable per-delivery identity — the delivery sequence on a replay, the row's key on a watch bridge, the change cursor on CDC — so a redelivery always carries the same key and the receiver can dedupe it.

The request body comes from a JSON template with tokens. The default template is "{{$row}}" — the whole projected row:

{
  "event": "row.changed",
  "op": "{{$op}}",
  "row": "{{$row}}",
  "sent_at": "{{$now}}"
}

Substitution happens on the parsed JSON tree, never by string splicing, so a value containing quotes or newlines cannot break the JSON and nothing in a row is ever executed. A string that is exactly one token keeps the value's real type — "{{$row}}" becomes the object itself, not a string — while a token mixed into other text is stringified. Unresolved tokens surface as warnings, never as failures. Outbound requests never follow redirects; the rest of the destination security posture is on the self-hosting page.

Delivery tuning

Every bridge carries the same set of delivery knobs. Three of them — maxAttempts, backoffMs and timeoutMs — govern HTTP deliveries only: a database write is a single attempt, and its retry safety comes from the keyed upsert plus the job-level retry controls. The rest apply to both destination kinds.

Job lifecycle and control

A job moves through these statuses:

Control is in-place: you can cancel a job, resume a paused or interrupted one, skip queued deliveries by range or selection, or retry only the failed rows — the retry re-queues the same job and re-sends just its failed delivery cells, which flip to success in place. All of these are also plain endpoints, documented on the HTTP API page; reading the delivery timeline is covered in the quickstart.

Fan-out and chaining

Because a database destination is a list of targets, one bridge can fan a source out to several databases at once — each target with its own mapping, write mode and key columns. And because any connection can sit on either end, bridges chain: database A feeds B, and a second bridge watches B and feeds C.

Workspaces

Workspaces are the top-level container: every connection and bridge belongs to one. A default workspace always exists, so the concept stays invisible until you create a second one. Deleting a workspace tears down everything in it — CDC slots dropped, watchers stopped, in-flight jobs canceled — before the delete cascades.