All connectors
A connector is the implementation for one system — postgres, bigquery, elasticsearch. Every connector declares a role, and that role decides which half of a sync it is allowed to occupy.
Sources and sinks
A source connector reads: it discovers your schema, backfills existing rows, and then tails the system's own change log. A sink connector writes: it takes batches of change events and applies them to a target. Some connectors do both — PostgreSQL and Cloud Spanner can each sit on either side of a sync, including both sides of the same sync.
The badge shown next to a connector in the console's catalog is what governs this. A connector badged Source only ever appears in the source slot of the create-a-sync wizard; a connector badged Sink only ever appears in the sink slot. There is no way to force a connector into a role it does not declare, so if a system you expected is missing from one of the two dropdowns, check its badge here first.
The same list appears in the first step of the add-a-connection wizard. Each connector’s role badge is what the sync wizard filters on later.
The full catalog
Grouped the way the console groups them. Every connector has its own page. Spanner Omni is covered on the Cloud Spanner page.
| Connector | Role | What it is |
|---|---|---|
| Databases | ||
| Google Cloud AlloyDB | Sink | Google Cloud's PostgreSQL-compatible database service. |
| Google Cloud Bigtable | Source | Google Cloud's wide-column NoSQL database. |
| Google Cloud SQL for PostgreSQL | Sink | Managed PostgreSQL on Google Cloud. |
| Amazon DynamoDB | Source | AWS key-value and document database. |
| Elasticsearch | Source | Sliced point-in-time snapshot, then watermark-based polling. No sink. |
| MongoDB | Source | Change streams, self-hosted or Atlas. |
| MySQL | Source | Row-based binary log with GTID positioning. MySQL and MySQL-compatible databases. |
| PostgreSQL | Source Sink | Logical decoding with pgoutput as a source; batched upserts as a sink. |
| Google Cloud Spanner | Source Sink | Change streams as a source; the Mutations API as a sink. |
| Spanner Omni | Source Sink | The self-hosted Spanner variant. Same connector, with a required endpoint. |
| SQL Server | Source | CDC capture tables, or the transaction log read directly. No sink. |
| Warehouses | ||
| Google BigQuery | Sink | Storage Write API with CDC upsert and delete on a declared primary key. |
| ClickHouse | Sink | Column-oriented analytical database, written over the native protocol. |
| Lakes & storage | ||
| Azure Blob Storage | Sink | Object storage on Azure. |
| Google Cloud Storage | Source Sink | Object storage on Google Cloud. |
| Apache Iceberg | Sink | Open table format over object storage. |
| Local Files | Source Sink | Files on the runner's own filesystem. |
| Amazon S3 / S3-compatible | Source Sink | Object storage on AWS, or any S3-compatible endpoint. |
| Streaming & events | ||
| Apache Kafka | Source Sink | Event streaming. As a sink it is append-only, and therefore at-least-once. |
| Google Cloud Pub/Sub | Source Sink | Managed messaging. As a sink it is append-only, and therefore at-least-once. |
| Utility | ||
| Standard Input | Source | Reads records from standard input on the runner. |
Documented in depth
Five connectors are documented in full: the mechanism they use, the setup they need on your side, every connection and sync field, the type mapping, and the limitations worth knowing before you commit to a design.
pgoutput, a resumable CTID-paginated backfill, and batched ON CONFLICT writes.sys.fn_dblog, or parsing the .ldf file — behind a hard preflight gate._change_type and a change sequence number, so replays deduplicate durably.The rest have a setup page: what to prepare on your side, every connection field with its default, and the credentials the wizard asks for.
What every source connector gives you
The mechanisms differ — a write-ahead log, a capture table, a change stream, a polled watermark — but the contract a source has to satisfy is the same, so you get the same four things regardless of which one you pick.
| Capability | What it means in practice |
|---|---|
| Change capture | Inserts, updates and deletes are read from the system's own change record rather than by polling for modified rows, so a change is observed once and in commit order. The one exception is Elasticsearch, which has no change log and polls a watermark field instead — and therefore cannot see deletes. |
| Resumable partitioned snapshot | The initial backfill is planned as non-overlapping partitions and dispatched one partition per task, so large tables load across many workers at once. Each partition reads from a consistent point-in-time view and records its own progress, so a runner dying mid-backfill costs you that partition, not the table. |
| Schema discovery | The source enumerates schemas, tables and columns for step 3 of the sync wizard, which is why you pick tables from a list instead of typing names. The same discovery is what later mapping validation and derived-column type checking run against. |
| Type mapping | Every source column is mapped into one common in-memory representation, so a sink never has to know what a numeric(12,2) or a UNIQUEIDENTIFIER was on the way in. |
That last point has a rule attached that is worth stating on its own: a type with no specific mapping falls back to text. Geographic types, money types, vendor extensions and anything else exotic arrive at the sink as strings rather than being skipped. A column is never silently dropped because Data Sync did not recognise its type — if you see a column arriving as text, that is the fallback doing its job, and the per-connector type tables tell you which types take it.
What every sink connector gives you
Sinks vary far more than sources do, because the guarantee you get on replay is a property of the target system. Three behaviours are common to all of them.
| Capability | What it means in practice |
|---|---|
| Batched, idempotent writes | Events are accumulated into micro-batches and flushed on whichever of 1,000 events, 4 MiB or 100 ms comes first — plus immediately whenever the source goes quiet, so low-traffic streams stay low-latency. Within a batch, CDC compaction is last-event-wins per key. Writes are shaped so that re-applying an already-applied batch converges rather than duplicating. |
| Additive schema evolution | When a new column shows up mid-stream and the sink is allowed to evolve, it adds the column and nothing else. No sink turns a dropped or retyped source column into destructive DDL. Widening, renaming and dropping at the target stay yours to do. |
| An explicit create-vs-use-existing choice | Per table, in step 4 of the sync wizard, you choose Auto-create (Data Sync creates the target) or Use existing (Data Sync validates the target and never issues DDL). Not every sink can auto-create — the PostgreSQL sink, for instance, never creates tables at all — so check the connector page before you rely on it. |
How strong "idempotent" is depends on the target. A keyed upsert sink like PostgreSQL or Spanner converges on replay at any point; BigQuery deduplicates durably on a change sequence number; Kafka and Pub/Sub are append-only and at-least-once by construction. The full per-sink matrix is in Delivery guarantees, and it is the right thing to read before you design around exactly-once.