Introduction

Data Sync is a change data capture engine. Point it at a database, choose the tables you care about, and every insert, update and delete lands in your warehouse within a second — backfilled first, then streamed continuously, with no polling and no nightly batch window.

What Data Sync does

A sync is the unit of work: one source connection, one sink connection, a set of tables, and a replication mode. When you start a sync, Data Sync does two things in sequence.

First it takes a snapshot — a consistent, parallelised backfill of every selected table, split into partitions so large tables load across many workers at once. Then it switches to CDC, tailing the source's own change log (the Postgres write-ahead log, SQL Server's CDC tables or transaction log, a Spanner change stream) and applying each change to the sink as it commits.

The handoff between the two is the part that is easy to get wrong and that Data Sync handles for you: the log position is captured before the backfill begins, so changes committed while the snapshot is running are replayed afterwards rather than lost. The resulting overlap is harmless because sink writes are idempotent.

The Syncs page lists every replication sync in the workspace with its live lag and state.

What Data Sync is not

Data Sync moves bytes. It does not transform them beyond column-level projection, and it does not model your warehouse. There is no SQL layer, no dbt generation, no orchestration DAG. If you need a table reshaped, joined or aggregated, that belongs downstream of the sink.

What Data Sync does give you at the mapping layer is deliberately narrow: rename a table or column, drop a column before it ever leaves the source, add a computed column from an expression, or fold several source tables into one target. Everything else is replication.

The moving pieces

Full definitions, the sync state machine and the replication modes are in Core concepts.

Where your data goes

This is worth being precise about, because it decides which deployment model you need.

Rows travel source → runner → sink. They do not travel through Blunox's control plane. What the control plane stores is metadata: sync definitions, checkpoints, run history, table and column names, and operational metrics like lag and throughput. No row values, ever.

That split gives you three ways to deploy:

• Managed — Blunox operates the runner fleet. Credentials are held encrypted in the Blunox credential store and unwrapped per use.
• Bring your own cloud (BYOC) — the same runner binary runs inside your own cloud account and reads credentials from your secret store. It opens a single outbound connection on TCP 443; there is no inbound path into your network and nothing for you to expose.
• Air-gapped — you operate the entire installation, control plane included. Nothing leaves your perimeter.

Correctness posture

Data Sync targets exactly-once delivery, and it is honest about how that is achieved: there is no distributed transaction spanning the source read and the sink write. Instead, the checkpoint only advances after a sink flush has durably succeeded, and sinks write idempotently. A crash therefore replays a bounded window of already-applied changes, and the sink absorbs the duplicates.

The strength of that guarantee is a property of the sink, not of Data Sync in the abstract. A keyed upsert target like Postgres or Spanner converges on replay at any point in time. An append-only target like Kafka does not, and is at-least-once by construction. The per-sink matrix is in Delivery guarantees — read it before you design around exactly-once.

Connectors

Data Sync ships connectors for databases, warehouses, lakes and streams. These docs cover five in depth:

The complete catalog — including MySQL, MongoDB, DynamoDB, ClickHouse, Kafka, Pub/Sub, Iceberg, S3 and GCS — is on the connectors page, and is always visible in the console when you add a connection.