How Fabric stacks up against the way you're doing it today

Fabric — hosted — Yes: We run it; you bring credentials

The hosted plans run the control plane, the runners and the maintenance for you. You bring the source and destination credentials and configure the pipelines.

Fabric — self-hosted — Partial: One Helm chart, your cluster

Self-hosted is one Helm chart into the Kubernetes cluster you already run; nothing else to install, but the cluster and the upgrades are yours to operate.

Fivetran — Yes: Fully managed; hybrid on Enterprise

Connectors run on Fivetran's cloud, so there is nothing to install. Hybrid Deployment moves the data path into your network on Enterprise or Business Critical plans.

Debezium + Tableflow on Confluent Cloud — Partial: Managed, or run Connect yourself

Fully managed Debezium connectors, the Kafka cluster and Tableflow on Confluent Cloud; the cluster and its connectors are settings you own, and self-managed Kafka Connect is the other route.

Estuary — Partial: Managed, BYOC, or private

Public deployments are fully managed by Estuary; BYOC and Private put the processing in your own cloud or network, which you then operate.

DIY — No: You run every service

Kafka, Kafka Connect, the Debezium connectors and a writer of your own — every one deployed, tuned and upgraded by you.

Fabric — hosted — Partial: Encrypted; rows in memory

Rows land in your own destination account, and the runner holds changes in memory until the commit. Credentials are stored encrypted and the runner decrypts them to connect — a vendor-run runner transits your rows.

Fabric — self-hosted — Yes: Never leaves your network

The self-hosted chart runs in your VPC against your object storage: credentials and row data never leave your network.

Fivetran — No: On Fivetran's cloud

Connectors run on servers in Fivetran's regions. Hybrid Deployment keeps the data path inside your network, on Enterprise or Business Critical plans.

Debezium + Tableflow on Confluent Cloud — Partial: Public egress or PrivateLink

Confluent runs the connector; it reaches your database over public egress, PrivateLink or VPC peering — or you run Kafka Connect yourself.

Estuary — Partial: Public cloud; BYOC, private

Public deployments process on Estuary's cloud; BYOC and Private keep data and processing inside your own cloud or network.

DIY — Yes: Your own network throughout

Every service sits in infrastructure you own; nothing routes through a vendor's copy.

Fabric — Yes: 5 sinks, format per pipeline

Iceberg (including S3 Tables), Delta Lake, Snowflake, ClickHouse or Postgres — chosen per pipeline.

Fivetran — Partial: Warehouses, databases and lakes

Warehouses, databases and lakes; managed lake tables are always Iceberg, with Delta metadata as an option — the format follows the destination, not a per-pipeline choice.

Debezium + Tableflow on Confluent Cloud — Partial: Topics first; Tableflow makes tables

Debezium writes to Kafka topics; a sink connector or Tableflow — Iceberg or Delta — is what materializes tables.

Estuary — Partial: Warehouses, databases and lakes

Its own materializations into warehouses, databases and lakes; Iceberg through a dedicated connector.

DIY — No: Whatever you build

Debezium lands changes in Kafka topics; the sink connector that turns them into table files — the writer, and its format — is yours to build and run.

Fabric — Yes: Built in, scheduled hourly

Compaction, snapshot expiry and orphan-file cleanup are built in and scheduled per source.

Fivetran — Partial: Automatic on managed lakes

For managed lake tables, snapshot expiry, delete-marker removal and orphan-file cleanup are automatic.

Debezium + Tableflow on Confluent Cloud — Partial: Tableflow compacts; sinks vary

Kafka log compaction is opt-in, and destination table maintenance belongs to the writer — Tableflow or your own job.

Estuary — Partial: Yours, unless Glue optimizers

Regular maintenance of materialized tables is yours to run unless a Glue optimizer is configured.

DIY — No: A job you write and run

Iceberg puts the maintenance procedures in your hands: compaction, snapshot expiry and orphan-file cleanup are run, and scheduled, by you.

Fabric — Yes: Additive-only, no restart

Additive-only: new columns land nullable, types are never retyped, and a source ADD COLUMN flows through without a restart. (A MySQL DDL across downtime needs a reset; live DDL does not.)

Fivetran — Partial: New columns; table re-syncs

New source columns are added to the destination automatically, which triggers a re-import or incremental sync of the table.

Debezium + Tableflow on Confluent Cloud — Partial: Registry governs; Tableflow applies

Schema changes go through Schema Registry, change events carry new columns, and Tableflow applies adds, removals and type widening.

Estuary — Yes: Automatic adds; NULL history

New fields are added automatically; historical rows show NULL for them.

DIY — No: Your writer's job

Debezium emits the schema change; applying adds, removals and type changes to the destination tables is your writer's job.

Fabric — Yes: Every 30 seconds by default

Commits every 30 seconds by default, set per source — Snowflake and ClickHouse have higher floors.

Fivetran — Partial: 15 minutes by default

Databases sync every 15 minutes by default (six hours for other sources), configurable from one minute to 24 hours — the one-minute end needs Enterprise or Business Critical.

Debezium + Tableflow on Confluent Cloud — Partial: Tableflow commits every ~5 min

Debezium streams changes in near real-time; Tableflow publishes them to the table approximately every five minutes.

Estuary — Partial: Continuous capture, 30-minute commits

Captures run continuously; warehouse materializations commit on a 30-minute schedule by default.

DIY — Partial: As fast as you tune it

Debezium tails the log in near real-time; the commit cadence, buffering and sink tuning are yours to build.

Fabric — Partial: Python per table; rows count twice

Per-table Python transforms run in a fresh sandbox on every flush, on Pro and Enterprise; a transformed row is counted twice.

Fivetran — Partial: In the destination, via dbt

Transforms run downstream in the destination, through dbt or Coalesce — a project you bring.

Debezium + Tableflow on Confluent Cloud — Partial: SMTs; Flink SQL beyond

Single-message transforms handle simple edits; anything heavier needs Flink SQL, ksqlDB or Kafka Streams.

Estuary — Partial: Inline SQL, Python, TypeScript

Derivations run inline as data moves, in SQL, Python or TypeScript — Python on private/BYOC data planes only.

DIY — Partial: SMTs; Streams beyond

Single-message transforms make lightweight, per-message edits — field-level operations you configure; stateful stream processing is a separate library you deploy and run.

Fabric — Yes: Checkpoint after commit

A write is checkpointed only after the commit lands, so nothing acked is ever lost. A replay after a crash is deduped per sink: upsert keys on Postgres and ClickHouse, deterministic staged files on Snowflake, and __source_offset order on Iceberg and Delta.

Fivetran — Yes: Idempotent merge

Loads are idempotent, applied as a merge — upsert plus insert — so a re-run keeps the destination an accurate replica.

Debezium + Tableflow on Confluent Cloud — Partial: At-least-once by default

At-least-once by default; exactly-once takes Kafka Connect's exactly-once support on both the worker and the connector (off by default), and Cloud sink connectors vary.

Estuary — Partial: Exactly-once on transactions

Exactly-once for targets that support transactions; at-least-once to Kafka.

DIY — Partial: At-least-once; dedupe is yours

Kafka's default guarantee is at-least-once delivery; deduplicating replays in the destination is your writer's job.

Fabric — Yes: Chunked, resumable, no locks

A chunked, resumable snapshot with the engine's own mark taken before the scan — no table locks, no downtime.

Fivetran — Yes: Plain SELECTs; no locks

The first full load is plain SELECTs — key-ordered and paginated on B-tree sources, whole-table on heap ones; a read replica keeps production isolated.

Debezium + Tableflow on Confluent Cloud — Partial: Locks vary by connector

Incremental snapshots run in parallel with streaming and block nothing; the classic initial snapshot blocks streaming, and its locks vary — a global read lock by default on MySQL, none on PostgreSQL.

Estuary — Partial: Backfill; standby optional

A backfill captures the tables' current state and then streams; a read-only standby keeps the load off production.

DIY — No: Classic snapshot locks

Debezium's classic initial snapshot holds a global read lock on MySQL's tables by default; incremental snapshots are an opt-in mode you configure.