A sink (also called a destination) is where your data lands. You create one from the Destinations page, then attach it to a source in the sync wizard's Sink step — or leave the source on use default destination to route it to that kind's default.
The write contract is the same regardless of which sink you pick: batching, checkpoint ordering, quarantine, and schema-refusal handling are identical. What differs is the storage format, the write semantics, and how you query it.
Supported sinks
| Sink | Shape | Where it lands |
|---|---|---|
| Iceberg | Append-only history | Apache Iceberg tables on S3-compatible object storage |
| S3 Tables | Append-only history | AWS-managed S3 Tables table bucket (Iceberg) |
| Delta Lake | Append-only history | Delta tables — Parquet plus a _delta_log directory |
| Postgres | Upsert, no history | Plain tables in a PostgreSQL database |
| Snowflake | Append-only history | Snowflake tables loaded via an internal stage |
| ClickHouse | Append-only history | A plain MergeTree table per synced table |
History vs. current state
Every sink except Postgres is append-only: each insert, update, and delete is a new row, and nothing is overwritten. That makes the table a complete history of the source. To read current state you dedupe by the identifier columns, take the latest version by timestamp, and drop rows marked deleted — see Data shape & metadata.
Postgres is the exception: it keeps a live mirror with INSERT … ON CONFLICT DO UPDATE and physically removes deleted rows. Pick it when you want the current state queryable without a dedupe step, and the history sinks when you need every version.
Fields every sink shares
| Field | Required | What it does |
|---|---|---|
| Name | Yes | Unique label for this destination. |
| Default destination | No | Sources without an explicit destination of this kind land here. One default per kind; the first destination created becomes it. |
Creating a sink
On Destinations, choose a kind — Iceberg, Delta Lake, S3 Tables, Snowflake, Postgres, or ClickHouse. Iceberg then asks for a catalog (metadata plane) and an object store (data plane); S3 Tables owns its data plane, so it skips the object-store choice; the other kinds go straight to their form.
Test before you save
Editing and deleting
Secret fields (passwords, keys, tokens) are write-only: they are never shown again, and leaving one blank on edit keeps the stored value. Destination edits are read by the runner at its next start. A destination that is still attached to a source cannot be deleted until every source is re-pointed.