A source is the operational system Fabric reads from. You add one inside the New Sync wizard — pick the source family on the first step, then fill its connection form. Fabric keeps one isolated, supervised runner process per source, so a failure in one pipeline never affects the others.
Every source runs on a native connector. There is no Kafka, no Kafka Connect, no Schema Registry, and no Debezium anywhere in the path — the runner connects to the source directly and writes to your destination.
Supported sources
| Kind | Sources | Change capture |
|---|---|---|
| Database | PostgreSQL, MySQL, MariaDB, SQL Server, IBM Db2 | Transaction log / change tables |
| Database | MongoDB | Change streams (oplog) |
| SaaS | Zoho CRM | Polling REST API |
Setup, end to end
- Prepare the source system. Enable its change-capture mechanism and create a login Fabric can use. Each source page lists the exact server settings, SQL, and grants.
- Pick the family and fill the connection form. Only the fields for the family you picked are shown.
- Save. Saving runs a live preflight: Fabric opens a real connection and checks the source-side prerequisites. The source is only created if the preflight passes, so a bad setting fails at setup rather than at the first run.
- Choose tables and a sink. Fabric discovers the source's tables automatically; you select the ones to sync and where they land.
The connection test
Fields every source shares
The connection block differs per family, but these fields are common to all of them:
| Field | Required | What it does |
|---|---|---|
| Connector name | Yes | Unique name for this source; also the runner's identity. |
| Snapshot mode | Yes | initial (default) / no_data / never — see below. |
| Snapshot chunk size | No | Rows paged per chunk during the initial snapshot. Defaults to 20,000; a table can override it from the table list. |
| Commit interval (ms) | No | How often buffered records flush as a new file in the destination. Defaults to 30,000 (Snowflake raises this to 300,000). Takes effect on the next restart. |
| Parallel snapshot workers | No | Concurrent scan connections during the initial load. 1 = serial; MySQL and MariaDB always run serial. Takes effect on the next restart. |
TLS and encryption in transit
Every database source carries its own TLS setting, which decides how the runner encrypts its connection to your database. It belongs to the source, not the workspace, so two sources on the same engine can use different modes. The modes, weakest first:
| Mode | What it does |
|---|---|
disable | No TLS. Traffic to the database is plaintext. |
prefer | TLS if the server offers it, plaintext if not. The certificate is not verified, so anyone on the path can strip the encryption. |
require | Require TLS, but do not verify the server's certificate — encrypted, yet anyone who can intercept the path can impersonate the server. |
verify-ca | Require TLS and verify the certificate chain against the CA you supply. The certificate's host name is not checked. |
verify-full | Everything verify-ca does, and the host name in the certificate must match the database's host name. |
Not every engine implements every mode. Where a mode would have to be silently downgraded, Fabric refuses the combination when you save instead:
| Engine | Modes |
|---|---|
| PostgreSQL, MySQL, MariaDB | disable, prefer, require, verify-ca, verify-full |
| SQL Server | disable, require, verify-full |
| IBM Db2, MongoDB | disable, require, verify-ca, verify-full |
SQL Server's ODBC driver validates the certificate chain and the host name together and takes no separate CA, so it has no verify-ca; its CA must be installed in the runner image rather than supplied per source. PostgreSQL, MySQL, MariaDB, Db2 and MongoDB take a CA PEM with the source when you pick verify-ca or verify-full.
A new hosted source starts at require
require — encrypted, certificate unverified — until you choose a stronger mode. disable and prefer are refused there unless the operator has enabled plaintext sources for the service. A source left on the engine default keeps the behaviour it has always had, so an upgrade never changes a connection that works today.Where to get the CA
Managed services publish their CA as a download — take it from the provider, and never paste a private key or a fingerprint anywhere. The CA PEM is stored encrypted with the source's other secrets. Start here:
- Amazon RDS and Aurora — Using SSL/TLS to encrypt a connection (download the certificate bundle for your region).
- Google Cloud SQL — Configure SSL/TLS certificates (MySQL; the same page exists for PostgreSQL and SQL Server under the other engines).
- Azure Database for MySQL — Transport Layer Security (TLS).
- Azure Database for PostgreSQL — Transport Layer Security (TLS).
Through an SSH tunnel
A tunnel makes the driver dial localhost, so a verify-full host-name check would run against localhost rather than your database's name. Only PostgreSQL can be handed the real name separately; on MySQL, MariaDB, Db2 and MongoDB use verify-ca through a tunnel (the CA is still verified), and on SQL Server, which has no verify-ca, use require — or connect to the database without the tunnel.
Snapshot modes
The snapshot runs once, before streaming begins. The mode controls how much of it happens:
| Mode | Behavior |
|---|---|
initial (default) | Full snapshot of the selected tables, then stream changes from the captured starting point. |
no_data | Schema only — no rows copied. Streaming starts from the current position. Use this when the tables were pre-loaded from a dump. |
never | Skip the snapshot entirely and stream from the current position. |
Where the data goes
The wizard's Sink step attaches a destination to the source. Pick a destination kind (Iceberg, Delta Lake, S3 Tables, Postgres, Snowflake, or ClickHouse) and a concrete destination, or leave it on use default destination to use that kind's default. The available sinks are documented under Sinks.