We read each vendor's own documentation on 8 October 2026. We quote no prices here.

How SQL Server CDC works, in plain terms​

Change data capture means spotting the inserts, updates and deletes in a database and sending only those on. In SQL Server, Microsoft's CDC docs say the source of change data is the transaction log, the file where the database records every change in order.

A job called the capture job reads that log and writes the changes into change tables. Each tracked table gets a capture instance, which is one change table plus up to two query functions. By default the instance is named schema_table, and its change table gets _CT added, per Microsoft.

Every change row carries a log sequence number (LSN) and an operation code. 1 is a delete, 2 is an insert, 3 is the row before an update and 4 is the row after. So an update adds two rows, per Microsoft's change table reference.

Two details trip up first-time readers. Don't order by __$seqval; use __$command_id, which orders changes inside a transaction. And Microsoft recommends calling the cdc.fn_cdc_get_all_changes_ and cdc.fn_cdc_get_net_changes_ functions instead of reading the change tables directly (reference).

Two SQL Server Agent jobs do the work, and their defaults matter. Microsoft's docs say the capture job runs continuously, handles up to 1,000 transactions per scan and waits 5 seconds between scans. The cleanup job runs daily at 2 A.M. and keeps entries for 4,320 minutes (3 days).

Microsoft Learn, "What is change data capture (CDC)?", Agent jobs section, October 2026.

CDC or change tracking? Your first choice​

SQL Server ships two built-in ways to find changed rows. Microsoft's comparison page says change data capture reads the log after the fact and keeps history, while change tracking records changes as you write and keeps no history.

Change tracking notes that a row changed and gives its primary key (the column that uniquely identifies each row), but not the changed values. That's fine for the latest state, but no use for history.

Your edition can settle things fast. Microsoft's editions table lists change data capture as Yes for Enterprise and Standard, and No for Express. Attaching a CDC database, or restoring it with the KEEP_CDC option, on an edition without CDC is blocked (Microsoft).

Microsoft Learn, "Editions and supported features of SQL Server 2025", Replication table, October 2026.

Azure SQL Database plays by different rules. Microsoft says a scheduler replaces the Agent jobs, and databases on the Database Transaction Unit (DTU) model need tier S3 or higher.

How to turn CDC on​

It's two commands, but the permissions differ. Per Microsoft's enable guide, sysadmin is required to enable CDC for a database, and a db_owner can then enable each table.

USE MyDB;
EXEC sys.sp_cdc_enable_db;
EXEC sys.sp_cdc_enable_table
  @source_schema = N'dbo', @source_name = N'MyTable',
  @role_name = NULL, @supports_net_changes = 1;

Per the same guide, CDC needs exclusive use of a schema and a user both named cdc, so enabling fails if you already have either. Net changes queries need a primary key or unique index on the table. A @role_name of NULL (no value) turns off the access role.

On Amazon Relational Database Service (RDS), per its CDC guide, you run msdb.dbo.rds_cdc_enable_db instead. AWS also says snapshot and point-in-time restores disable CDC and remove its metadata.

Amazon RDS User Guide, "Using change data capture for Amazon RDS for SQL Server", October 2026.

How we picked​

We included maintained tools that document their SQL Server source in public, and looked at how each reads SQL Server, what the docs say about schema changes and retention, and where the data lands. We did not run these tools; this is a documentation reading, not a lab test, and speed or reliability claims on vendor pages are the vendor's.

Each entry has one "What users say" line, with short quotes from public threads and review sites that we opened on 8 October 2026. Most of that talk is about other databases, so treat it as general experience with the tool. The order inside a group isn't a ranking.

SQL Server CDC tools at a glance​

Tool	How it reads SQL Server	How you run it	Change tracking	Read replica
Native CDC	Agent jobs copy the log into change tables	Inside SQL Server	Separate feature	Not covered here
Debezium	CDC change tables, to Kafka topics	Self-hosted	Not covered here	Not covered here
Fivetran	Change tracking, CDC, Binary Log Reader or Teleport Sync	Managed, or Hybrid	Yes	CDC yes, change tracking no
Airbyte	CDC, with scheduled syncs	Core self-managed, or Cloud	Not covered here	Not covered here
Estuary	CDC, change tracking or batch connectors	Managed, private or BYOC	Yes	CDC yes, worker runs on the primary
Qlik Replicate	Two connection types: a standard endpoint and MS-CDC	Client-managed	Not covered here	Not covered here
Striim	MS SQL Reader (CDC tables) or MSJet (log backups)	Cloud, or self-managed	Not covered here	Not covered here
AWS DMS	MS-Replication and MS-CDC	Runs in the AWS Cloud	Not covered here	Read-only replica source: manual MS-CDC set-up
Google Datastream	Change tables or transaction logs	Google Cloud	Not covered here	Not covered here
Fabric mirroring	CDC (2016 to 2022) or change feed (2025)	Microsoft Fabric	Not covered here	Not covered here
OLake Go	CDC capture instances	Self-hosted	Not covered here	Yes, with ApplicationIntent=ReadOnly

MS stands for Microsoft: MS-CDC is its CDC feature, MS-Replication is its replication feature, and MS SQL Reader is a Striim reader. "Not covered here" means we didn't find the point on the pages we read, not that the tool can't do it.

The 11 best SQL Server CDC tools​

Built into SQL Server​

1. Native SQL Server CDC: best when the consumer is your own code​

At a glance

• Reads SQL Server through: Agent jobs and change tables
• Lands data in: nowhere, you query it
• Price: part of SQL Server editions that include it

Native CDC is the base layer under most tools below, so it's worth knowing on its own. Microsoft's docs name the query functions that return changes over a range of LSNs.

What's good

• It needs no extra software and keeps history, with the values before and after each update, per Microsoft's change table reference.
• Microsoft says stopping the capture job loses no change data. It only pauses log scanning.
• Setting @supports_net_changes to 1 also generates a net changes function for the capture instance, and Microsoft's enable guide says that needs a primary key or unique index on the table.
• If an existing column changes data type, Microsoft says the change is propagated to the change table.
• On Amazon RDS, once you run msdb.dbo.rds_cdc_enable_db, AWS says any db_owner of the database can enable or disable CDC on its tables.

Where it falls short

• It only fills change tables (Microsoft), so you still need something to move the rows.
• Even in simple recovery mode, Microsoft says the log truncation point doesn't advance until captured changes are gathered, and CHECKPOINT won't truncate the log if the capture process isn't running while changes wait to be gathered. So a stopped capture job makes the log grow.
• Microsoft says both capture methods need SQL Server Agent running, and its editions table lists change data capture as Yes for Enterprise and Standard and No for Express.
• Ask for a range that starts before the oldest kept change and Microsoft says there could be missing change data from aggressive cleanup. A range outside the valid window makes the query functions fail.
• New columns are ignored until you create a second capture instance, and Microsoft says a table can have at most two at once.
• In a capture instance, Microsoft says computed columns always have a value of NULL, and by default a captured column can take at most 65,536 bytes (64 KB) in one INSERT, UPDATE, WRITETEXT or UPDATETEXT statement.

What users say: One Hacker News commenter ran SQL Server CDC into Debezium and Azure Event Hubs and reported a "5-10 second delay from source system transaction commit till update/insert" (Hacker News, "Turning the database inside-out (2015)", January 2025). We found no user write-up on log growth or Agent trouble, so those limits rest on Microsoft's docs alone.

Run it yourself​

2. Debezium: best for teams that already run Kafka​

Debezium home page, October 2026.

At a glance

• Reads SQL Server through: CDC change tables
• Lands data in: Kafka topics, one per table
• Price: free licence, you pay for servers and staff

Debezium is an open-source CDC engine. Its SQL Server connector docs say it is based on the CDC feature in SQL Server 2016 Service Pack 1 and later, Standard or Enterprise edition.

What's good

• It takes a consistent snapshot first, then streams changes and picks up from the last log position after a restart (docs).
• Incremental snapshots copy a table in chunks (1,024 rows by default), and the SQL Server docs say they run alongside streaming and can resume after an interruption without losing data.
• The docs say it can capture from an Always On read-only replica, though CDC must still be enabled on the primary node.
• The docs cover tuning the SQL Server capture job: a higher pollinginterval lowers the load on the database host and raises latency.
• The docs say its schema history provides the table structure in effect when a change event occurs.

Where it falls short

• Offsets are saved on a schedule, so after an outage the docs warn of duplicate events, so your loads must cope with repeats.
• The docs say SQL Server CDC isn't designed to store a complete history of changes, so the connector takes a snapshot to set a baseline.
• A table whose schema wasn't in the initial snapshot fails with a missing schema error. The documented fix starts with removing the schema history topic and clearing Kafka Connect offsets, and the docs say removing offsets should be done only by advanced users.
• The docs say it doesn't support schema changes while an incremental snapshot is running, and changing a primary key during one can cause incorrect results.
• Incremental snapshots need the connector to have permission to write to the signaling table (docs).
• tasks.max defaults to 1, and the docs say it can be raised to at most the number of entries in database.names.

What users say: One Hacker News commenter found "dealing with the kafka connect errors and fixing replication slots... ehhh was painful" (Hacker News, launch thread for the Ingestr CDC tool, July 2026).

Managed or vendor-run​

3. Fivetran: best for teams that want a vendor to run SQL Server loads​

Fivetran home page, October 2026.

At a glance

• Reads SQL Server through: change tracking, CDC, Binary Log Reader or Teleport Sync
• Lands data in: warehouses; Apache Iceberg through its Managed Data Lake Service
• Price: usage-based, billed on monthly active rows, so the bill moves with how many rows change

Fivetran's SQL Server connector docs list four ways to find changes. Teleport Sync is the odd one out, because it skips SQL Server's change features and instead scans tables and compares row hashes between syncs. If a table has both change tracking and CDC on, Fivetran uses CDC.

What's good

• Its docs list four SQL Server methods and point to Teleport Sync when change tracking or CDC can't be enabled.
• Its connector docs cover SQL Server 2012 to 2025, with Binary Log Reader on 2016 to 2025 only.
• Its docs say CDC data can be read from secondary replicas in an Always On availability group, but SQL Server doesn't allow CDC setup on a secondary, so all CDC setup happens on the primary node.
• With CDC, its docs say column type changes propagate automatically, and extra permissions let CDC track DDL changes without re-syncing the modified table.
• For change tracking, its docs say Fivetran detects when it couldn't process changes before they were deleted from the change table and triggers a re-sync of that table.
• Its docs say it supports the SaaS and Hybrid deployment models for all SQL Server implementations, and Hybrid needs an Enterprise or Business Critical plan.

Where it falls short

• With CDC, Fivetran syncs only tables with a single capture instance, so a new column means a new instance and removing the old one (docs).
• Change tracking can't sync tables without a primary key or run on a replica (docs).
• With CDC, its docs say column type changes propagate but renamed columns, new tables and new columns do not.
• Iceberg goes through Managed Data Lake Service, a separate destination whose docs say it supports the SaaS deployment model.
• That page also says Fivetran doesn't support position deletes for Iceberg tables, and on AWS the Glue catalog supports only one table per combination of schema and table names within a Region.
• Under usage-based pricing, rollback syncs may fetch data from the previous month, and those past records count as new unique records toward monthly active rows for the current month.

What users say: A Hacker News commenter (thread on the Fivetran and dbt Labs merger, October 2025) says "Fivetran is convenient but absurdly expensive."

4. Airbyte: best for open-source SQL Server loads on a schedule​

Airbyte home page, October 2026.

At a glance

• Reads SQL Server through: CDC, in scheduled syncs
• Lands data in: warehouses and lakes; Apache Iceberg on S3 through its S3 Data Lake destination
• Price: Core is free, Cloud is paid

Airbyte's SQL Server docs say the connector uses SQL Server CDC with the transaction log, and CDC setup needs db_owner rights. Its CDC sync runs on a schedule, and Airbyte's CDC docs say it doesn't treat CDC sources as infinite streaming sources.

What's good

• Core is free to self-run, and Airbyte calls it open source (its licence is Elastic License 2.0). Beside CDC, the connector also has full refresh and incremental modes.
• Its SQL Server docs say the certified connector offers CDC using SQL Server's own CDC feature, for SQL Server 2016 Service Pack 1 and later.
• Its S3 Data Lake docs say the connector writes Iceberg tables to S3 or S3-compatible storage using a REST, AWS Glue, Nessie or Polaris catalog, and that deduping is merge-on-read.
• The same S3 Data Lake page says it handles adding or removing a column, widening a column and changing the primary key. Because it never rewrites existing Iceberg data files, other schema changes are not handled.
• For truncate refreshes the S3 Data Lake connector writes to a staging branch and swaps it in at the end, so queries read the old version until then. It keeps the staging branch after a failed sync so a retry can recover.
• Its CDC docs say Airbyte adds metadata columns that begin with _ab_cdc_ for CDC sources.

Where it falls short

• Incremental CDC needs a primary key, so tables without one get full refresh only (docs).
• Delivery is at least once (docs). CDC can't be enabled on tables with a clustered columnstore index (a storage layout built for analytics), and hierarchyid and sql_variant are not processed.
• Its CDC docs say changes made by TRUNCATE or ALTER will not appear in the logs and so not in the destination, and a refresh is required after any new table is added to a CDC connection.
• CDC syncs launch on a sync interval and read the logs up to the sync's start time (CDC docs). The first CDC sync takes a snapshot with a SELECT statement, which is effectively a full refresh.
• On the S3 Data Lake page, a Number-type primary key is stored as an Iceberg string, so ordering on it is lexicographic, and objects and unions are written as JSON strings.
• The same page cautions that if compaction runs at the same time as a truncate refresh sync, it deletes files from the current generation and causes data loss. It does not say who handles compaction.

What users say: A GitHub issue from February 2026 (since closed) says a connector update broke SQL Server CDC on Azure SQL geo-replicas for connections "running successfully for many months".

5. Estuary: best when you need to choose between CDC and change tracking​

Estuary Flow home page, October 2026.

At a glance

• Reads SQL Server through: three connectors, CDC, change tracking or batch
• Lands data in: the destinations you choose, such as warehouses and lakes
• Price: not covered here

Estuary's SQL Server docs include a table of its three connectors. CDC is log-based and real time, and it handles tables without a primary key. Change tracking is real time too, stores only primary keys, and can capture computed columns, which CDC can't.

What's good

• Its docs set out the CDC versus change tracking tradeoff in a table, and say to use the batch connector for views or custom queries.
• The docs list three SQL Server connectors plus variants for Azure SQL Database, Amazon RDS and Google Cloud SQL, with setup steps for each platform. They say it is regularly tested against SQL Server 2017 and up.
• The docs describe the CDC connector as log-based and real time, suited to full audit history and to tables without a primary key, but for those tables you set a key by hand in the collection definition.
• Change tracking is real time too, stores only primary keys for lower storage overhead on the source, and can capture computed columns, which CDC can't (docs).
• After a schema change, its docs say the connector detects a second capture instance and switches over once both are valid. An optional "Automatic Capture Instance Management" setting manages the instances for you.

Where it falls short

• CDC can read a replica, but the CDC worker must run on the primary. Change tracking doesn't support read replicas (docs).
• The batch connector polls, so expect latency of minutes to hours (docs).
• Its docs say a captured table should have a primary key, and without one you must specify a key manually in the Estuary collection definition.
• The docs say CDC cannot capture computed columns or computed primary keys, and change tracking may combine intermediate changes that happen in rapid succession.
• Automatic Capture Instance Management needs additional permissions (docs).
• Private and BYOC deployments need an annual plan and add fees based on the cloud infrastructure required. Its pricing docs publish no figure for those fees.

What users say: A G2 reviewer, seen on AWS Marketplace (August 2026), says "The logs are also pretty noisy and hard to follow, especially when I'm troubleshooting."

Enterprise platforms​

6. OLake Go: best for SQL Server changes into Iceberg or Parquet on your own storage​

OLake home page, October 2026.

At a glance

• Reads SQL Server through: CDC capture instances, SQL Server 2017 or later
• Lands data in: Apache Iceberg or Parquet only
• Price: free licence, you pay for servers and staff

OLake Go is open source under Apache 2.0 and reads SQL Server in four sync modes: full refresh, full refresh plus CDC, CDC only, and full refresh plus incremental (see the SQL Server connector guide).

What's good

• The SQL Server connector guide lists parallel chunking, checkpointing and automatic resume for failed full loads. An optional VIEW DATABASE STATE grant (VIEW DATABASE PERFORMANCE STATE on SQL Server 2022 or later) gives faster chunking for tables without a primary key.
• A "Manage Capture Instance" option creates new capture instances when schemas change, if the user has db_owner (see the guide).
• It can read from a read-only secondary replica with ApplicationIntent=ReadOnly, while CDC stays enabled on the primary. With Manage Capture Instance on, it asks for the primary's credentials so it can manage capture instances there (see the guide).
• It writes Iceberg tables to eleven catalog types, such as AWS Glue, REST, Polaris, Nessie and Unity (see the catalogs page), or Parquet files if you prefer.
• For Iceberg, a two-phase commit tracks per-chunk commit status in destination state, covering full refresh, incremental and CDC for MSSQL, to avoid inconsistencies and duplicate writes (see the v0.5.0 release notes).
• The guide gives the CDC enable commands for Amazon RDS and Google Cloud SQL, and the source supports SSL modes and SSH tunnels.

Good to know

• OLake Go is built for Iceberg and Parquet output, and you run it on your own infrastructure.
• Keep it reading inside the three-day change table window. Computed columns come through as NULL, and a clustered columnstore index blocks CDC, as it does in SQL Server itself.

Bottom line: Pick it if you want SQL Server changes in Iceberg tables on storage you own and can run a container. Snowflake, BigQuery and Redshift can still query the Iceberg tables it writes, depending on the catalog (see the compatibility page).

7. Qlik Replicate: best for large mixed estates with an existing Qlik contract​

Qlik Replicate / Qlik Talend Cloud home page, October 2026.

At a glance

• Reads SQL Server through: two source connection types (endpoints), a standard SQL Server endpoint and an MS-CDC endpoint
• Lands data in: the targets Qlik supports, listed in its support matrix
• Price: not published

What's good

• Qlik's MS-CDC endpoint docs say it reads Microsoft change tables instead of the log, which Qlik says lowers the risk of data loss from short log retention or unreachable log backups.
• The replication task turns on MS-CDC for the source tables for you, unless you'd rather do it by hand.
• The same endpoint can also be used to replicate from an Amazon RDS for SQL Server source, per the endpoint docs.
• Its prerequisites page points to sys.sp_cdc_change_job and a small @pollinginterval value to reduce latency.
• Qlik's pricing page lists "Qlik Open Lakehouse with ingestion and adaptive optimization for Apache Iceberg" in the Standard edition of Qlik Talend Cloud.

Where it falls short

• Prices aren't published, and the product is client-managed software, so you run the server.
• The prerequisites page says the CT table names must use the default <SchemaName>_<TableName>_CT format and the CT table must include the listed columns.
• The MS-CDC capture and cleanup jobs must be running (prerequisites).
• Microsoft ODBC Driver 18.5 must be installed on the Replicate machine, on Windows or Linux (prerequisites).
• On the pricing page, log-based CDC first appears in the Standard edition list for Qlik Talend Cloud, not in Starter.

What users say: One PeerSpot reviewer (May 2024) finds it "too costly for small businesses".

8. Striim: best for log-backup reading and low load on the source​

Striim home page, October 2026.

At a glance

• Reads SQL Server through: MS SQL Reader (CDC tables) or MSJet (log backups)
• Lands data in: many targets; Iceberg on Google Cloud Storage or S3 Tables
• Price: contact sales, with a Developer tier

Striim's SQL Server page says MSJet has higher throughput and lower use of the source server's compute, memory and disk than MS SQL Reader (Striim's claim, which we did not test). MS SQL Reader supports older SQL Server versions and more cloud SQL databases.

What's good

• You can pick the reader per source: MS SQL Reader for CDC tables, or MSJet for log backups (docs).
• Its Iceberg Writer docs list two write modes, Merge and Append Only, and say it propagates DDL changes from supported sources to the Iceberg tables.
• Its S3 Tables Writer docs list APPENDONLY and MERGE modes, with an Optimized Merge option for partial-image CDC, and DDL propagation for supported source operations.
• The SQL Server docs say Striim provides wizards for creating applications that read from SQL Server and write to various targets.
• Its pricing page lists a self-managed Striim Platform with clustered deployments with HA, and Striim Cloud with dedicated compute and networking.

Where it falls short

• MSJet reads log backups on disk, and the docs say backups on tape, virtual devices, mirror backups or Azure Storage aren't supported.
• Its Iceberg Writer is Google Cloud Storage only; S3 Tables has its own writer.
• The Iceberg Writer needs a compute engine and a catalog: Google Cloud Managed Service for Apache Spark and a Lakehouse, Nessie or Polaris catalog (docs).
• With the Iceberg Writer, partitioned tables need manual table creation, and time source data types are written as strings (docs).
• The S3 Tables Writer uses Amazon EMR as the compute engine, and S3 Tables requires lowercase table, namespace and column names, which breaks wildcard mappings against uppercase-identifier sources.
• Both Iceberg writers recover on restart with at-least-once processing (Iceberg Writer, S3 Tables Writer).

What users say: A PeerSpot reviewer (August 2026) says "Striim would not intuitively tell me the culprit table or database behind the lag."

Cloud services​

9. AWS Database Migration Service (DMS): best for AWS-centered teams​

AWS DMS home page, October 2026.

At a glance

• Reads SQL Server through: MS-Replication and MS-CDC
• Lands data in: AWS stores such as S3 files; Apache Iceberg is not in its target list
• Price: not covered here

DMS uses two methods, per its SQL Server CDC docs. On a self-managed server, it uses MS-Replication for tables with primary keys and MS-CDC for tables without. Amazon Relational Database Service (RDS) for SQL Server doesn't support MS-Replication, so DMS uses MS-CDC for all tables there.

What's good

• AWS operates it, and the docs cover set-up with and without the sysadmin role.
• Its overview says you can run one-time migrations or replicate ongoing changes to keep sources and targets in sync.
• DMS version 3.4.7 and later can set up MS-CDC for the database and all tables automatically, if you are not using a read-only replica (CDC docs).
• Version 3.5.3 adds reading from log backups of Amazon RDS for SQL Server, per the CDC docs, and Kerberos authentication for SQL Server sources, per the source docs.
• The source docs say it supports named instances of SQL Server and can use SSL between the endpoint and the replication instance.

Where it falls short

• It has no Iceberg target in its target list, so you add a second step to build Iceberg tables from the S3 files.
• Self-managed sources need a distribution database for MS-Replication (docs). That's extra set-up work.
• The source docs say columnstore indexes, memory-optimized tables, temporal tables, sparse columns and column-level encryption are not supported, and neither is replication from databases with accelerated database recovery (ADR) turned on.
• Per the source docs, changes to computed fields aren't replicated, truncate commands aren't captured, and renaming tables or columns with sp_rename isn't supported.
• If the database is set up for neither MS-Replication nor MS-CDC, per AWS, tables without a primary key capture only INSERT and DELETE events; UPDATE and TRUNCATE events are ignored.
• The source docs say you may lose events if SQL Server archives them from the active transaction log to the backup log, or truncates them from it.

What users say: A PeerSpot reviewer (September 2024) says "the error messages from DMS are very ambiguous and sometimes misleading."

10. Google Cloud Datastream: best for Google Cloud teams that want BigQuery or Cloud Storage​

Google Datastream home page, October 2026.

At a glance

• Reads SQL Server through: change tables or transaction logs, your choice per stream
• Lands data in: BigQuery, Cloud Storage, and Apache Iceberg tables in BigQuery, with the data in your own buckets
• Price: not covered here

Datastream's SQL Server page lists self-managed servers (Enterprise 2008 and later, Standard 2016 Service Pack 1 and later), Amazon RDS, Cloud SQL and Azure SQL Database. For Cloud SQL, Express is not supported.

What's good

• Datastream documents two methods per stream. Change tables have fewer limits and no risk that log truncation fails a stream for good, at lower throughput, while the transaction logs method is faster and needs fewer resources.
• The docs say the change tables method supports replication of encrypted tables, which the transaction logs method does not (it can't handle Transparent Data Encryption).
• With the enable_ddl_support_for_ct label, Datastream checks cdc.ddl_history every five minutes and, when a column is added, creates a new capture instance, reads the old one up to the change, then reads the new one. You still delete the original instance afterwards, since SQL Server allows two per table.
• Datastream replicates user-defined data types, but stores the base data type they derive from in the destination.

Where it falls short

• The transaction logs method doesn't support Transparent Data Encryption or column-level encryption (that data becomes NULL), and doesn't replicate columns added after a stream is created (docs).
• Streams are limited to 10,000 tables, and a table with more than 500 million rows can't be backfilled unless it has a unique index with no nullable columns, all included in the stream.
• Its Iceberg tables in BigQuery are append-only, and the page does not mention Amazon S3.
• SQL_VARIANT, HIERARCHYID, GEOMETRY and GEOGRAPHY columns aren't replicated (docs).
• Databases with delayed durability or accelerated database recovery (ADR) enabled aren't supported, and neither is Windows Active Directory authentication (docs).
• With the change tables method, dropping a column replaces its data with NULL, and renaming columns isn't supported when CDC is enabled (docs).

Google Cloud Datastream, SQL Server source behavior, October 2026.

11. Microsoft Fabric mirroring: best for teams whose target is Microsoft Fabric​

Microsoft Fabric home page, October 2026.

At a glance

• Reads SQL Server through: CDC (SQL Server 2016 to 2022) or change feed (2025)
• Lands data in: Microsoft Fabric OneLake
• Price: replication compute is free, per Microsoft; queries use Fabric capacity, so check what that costs you

Fabric mirroring copies a SQL Server database into Fabric. Data lands in OneLake as Delta tables, which Microsoft says now include virtual Iceberg metadata. Microsoft's limits page says mirroring of SQL Server 2016 to 2022 requires CDC, while SQL Server 2025 uses a different change feed.

What's good

• Microsoft's docs say that for SQL Server 2016 to 2022 it reuses CDC if it's already on, or can set it up.
• The mirroring page lists SQL Server on Windows (Standard, Enterprise and Developer), Linux from 2017 CU18, and instances hosted on-premises, on an Azure VM or on non-Azure clouds for 2016 to 2022.
• Each mirrored database gets an autogenerated SQL analytics endpoint, a read-only copy you can query with T-SQL (docs).
• To mirror a server behind a firewall, the docs say to set up an on-premises data gateway or a virtual network data gateway.
• If CDC isn't on, the limits page says the tutorial makes fabric_login a temporary member of the sysadmin server role to configure it.

Where it falls short

• Microsoft says you can't mirror a SQL Server 2025 database that has CDC enabled (limits page). SQL Server 2025 mirroring also needs Azure Arc and isn't supported on Linux or on an Azure VM.
• A schema change breaks mirroring on 2016 to 2022 until you re-enable CDC for the table, and it restarts a full snapshot on 2025 (limits page).
• Per the limits page, mirroring works only on a primary database of an availability group, doesn't support a failover cluster instance, and can't mirror a database already mirrored in another Fabric workspace.
• You can mirror up to 1,000 tables, and the limits page says tables above that are not replicated.
• On the limits page, clustered columnstore indexes aren't supported, tables using temporal history, Always Encrypted, in-memory, graph or external features can't be mirrored, and LOB columns over 1 MB are truncated to 1 MB.
• Active transactions hold log truncation until the mirror catches up, and Microsoft says to monitor the source transaction log so it doesn't fill.

What users say: A SQL Server blogger notes that "a process that reads the log file every 5 seconds" feeds the mirror (sqlreitse.com, April 2026), while another warns "Active transactions hold log truncation until the mirrored database catches up" (sqlfingers.com, February 2026).

What actually breaks SQL Server CDC​

The diagram shows the three failures that stop a pipeline outright. A fourth, large columns, corrupts data quietly (we counted no real incidents, only what the docs say).

The Agent stops. Microsoft says both capture methods need SQL Server Agent running. No Agent, no changes.

The tool is down longer than retention. The default is three days, which sounds fine until a long weekend. Fivetran's docs recommend seven days and, for change tracking, say it triggers a re-sync of a table when changes were deleted before it could process them. Microsoft says a request for a range outside the valid window fails or can miss data.

A column is added. Microsoft says new columns are ignored unless you create a second capture instance. A dropped column gets NULL (no value). At most two capture instances per table are allowed.

Large columns come through empty. Microsoft says varchar(max), nvarchar(max) and varbinary(max) columns are NULL on update rows unless the column changed in that update. Columns of type text, image and ntext are NULL on delete and update rows. A loader that treats NULL as "set to empty" will overwrite good data.

A schema change, step by step​

Microsoft's fix for a new column is a second capture instance, with a new name, that has the new shape.

EXEC sys.sp_cdc_enable_table @source_schema = 'dbo', @source_name = 'my_table',
  @role_name = 'my_role', @capture_instance = 'dbo_my_table_v2';

Tools that overlap instances. Estuary and OLake Go say they detect the second instance and switch when both are valid. Wait for your tool to confirm the switch before you delete the old instance.

Tools that expect one instance. Fivetran only supports tables with a single capture instance, so its docs tell you to create the new instance and delete the old one. Its feature table adds that CDC tracks schema changes by re-syncing the modified table, unless you grant extra permissions.

A check to run before every restart​

Microsoft says the query functions fail if your range is outside the valid window, so compare your tool's saved position with the oldest and newest positions SQL Server still holds.

SELECT sys.fn_cdc_get_min_lsn('dbo_my_table') AS oldest_lsn,
       sys.fn_cdc_get_max_lsn()               AS newest_lsn;

Debezium keeps its position as an LSN in its offsets. If your saved position is older than oldest_lsn, cleanup has already removed changes you never read.

A worked selection case​

The case below is invented to show the method, and we tested no tool.

Suppose a SQL Server 2022 Standard edition server has 300 tables. Twenty have no primary key, two have a clustered columnstore index, and the target is Apache Iceberg on Amazon S3. Schemas change about monthly.

Requirement	Fits	Does not fit, and why
Twenty tables without a key	Estuary CDC, AWS DMS (MS-CDC), Fivetran CDC	Airbyte CDC copies those tables by full refresh only; Fivetran change tracking skips them
Two columnstore tables	Fivetran Teleport Sync, which its docs point to when CDC can't be enabled	CDC tools for those two tables, since Microsoft says CDC can't be enabled on a clustered columnstore index
Iceberg on S3	Fivetran Managed Data Lake Service, Airbyte S3 Data Lake, OLake Go	Datastream (Google Cloud Storage), Striim (Google Cloud Storage or Amazon S3 Tables, not plain S3), Fabric mirroring, AWS DMS without a second step
Monthly schema changes	Estuary and OLake Go (switch to a second instance)	Fivetran needs a new capture instance each time

No single tool covers every row, so each path needs a compromise.

Airbyte can do CDC for tables with keys and full refresh for the rest. OLake Go covers the ordinary tables with CDC and offers a full refresh mode too. Confirm how CDC treats the twenty keyless tables before you commit.

So which tool should you pick?​

If two rows fit, shortlist both and test them.

Your job	Look at
Kafka is already your hub	Debezium
A vendor runs loads to a warehouse	Fivetran or Estuary
Self-run loads on a schedule	Airbyte
Lower load on a busy source (Striim's claim)	Striim with MSJet
Data goes to AWS stores, Google Cloud, or Fabric	AWS DMS, Datastream, or Fabric mirroring
You want to choose between change tables and log reading	Datastream or Qlik Replicate
Self-hosted Iceberg or Parquet files	OLake Go
CDC is not allowed on the server	Fivetran Teleport Sync, or Estuary's batch connector (its docs say it polls)

FAQ​

Every fact below comes from Matillion's own pages, read from saved copies dated October 8, 2026, with the page linked beside the claim.

When Matillion doesn't publish a number, we say "not published". We did not run Matillion. This is a careful read of its documents, not a hands-on test.

What is Matillion?​

Matillion home page, October 2026.

Matillion describes itself as born in Manchester, with headquarters in Denver and Manchester. Its about page lists Matthew Scullion as a founder and says "Empowering data teams since 2011".

These days the lead message is Maia. The home page calls Matillion "the company behind Maia, the agentic data team", and the Maia docs call Maia "the AI Data Automation platform by Matillion".

The short version: Matillion is software that moves data into a cloud data warehouse and gets it ready for analysis. Snowflake and Amazon Redshift are two examples of a data warehouse, a database built for reports. Teams save their steps as a pipeline, a series of steps that moves or reshapes data.

You'll often hear this kind of tool called ETL, short for extract, transform, load. Extract means read data from a source. Load means write it to a destination, and transform means clean it up and reshape it along the way.

Matillion's own comparison post describes the same idea: load data into a cloud data platform, then run the transformations there as SQL.

The four names you will meet​

The product names overlap, and they changed in 2026.

Sources: deployment options, credit terms, Matillion ETL docs.

Matillion's terminology page says that in early 2026 it decided to rebrand Data Productivity Cloud as Maia. It also renamed "agents" to "runners" and the "Enterprise edition" to the "Scale plan". The pricing page still says Data Productivity Cloud in places, so expect to see both names.

The Matillion ETL docs now say they only host Matillion ETL documentation, because the Maia docs moved. They have Create Project pages for Snowflake, Amazon Redshift, Google BigQuery, Azure Synapse Analytics and Delta Lake on Databricks. For Maia Foundation, the home page says its connectors span Snowflake, Databricks, BigQuery and Redshift.

How Matillion works​

So what does a Matillion pipeline actually do? It has up to three parts, and Matillion bills them differently.

1. Load. Pre-built connectors copy data from a source into your warehouse. In Matillion's words, these sit in orchestration pipelines, meaning the load-and-flow-control kind, which "handle the loading of data from source systems to a target data warehouse" (docs). A connector is just a ready-made piece of software for one kind of source. The Matillion ETL product page says "over 150 pre-built connectors".
2. Transform. Transformation pipelines work on tables already in the warehouse, with steps such as Table Input, Filter, Aggregate and Rank (docs). You build them on a visual canvas, or in SQL or Python. Matillion's own comparison post says Maia Foundation runs transformations as native SQL pushed down into Snowflake, Databricks or AWS Redshift. So the warehouse does the heavy lifting, and yes, your warehouse bill grows with it.
3. Chain and schedule. A pipeline can run on a schedule and call other pipelines. Each component has green, gray and red paths, so you can branch on success or failure. And a transformation pipeline slots into a load pipeline through a Run Transformation component.

On top of that, Matillion says Maia has an AI helper that builds pipelines from plain-language requests. We did not test it, and the next line matters.

Per the credit terms, the Maia AI product is an add-on, priced as a separate annual fixed fee.

What about the free trial? The pricing page calls it "time-bound, fair-use" and gives no length.

Matillion's free trial doc says new accounts get 14 days and 500 complimentary credits, with every feature open.

When the trial ends, the runner is suspended until you subscribe. If you started from a marketplace or added payment details, a Pay-Go plan kicks in instead.

Connector counts do not agree​

Count the connectors and you get different answers. The home page says Maia Foundation has 150+ connectors and the ETL product page claims over 150. Matillion's comparison post, dated July 16, 2025, says 130+ in its table and 150+ in its text, and its connector page states no count in the text we read.

Our advice: quote the page you used, with its date. And if one source matters to you, check that it's on the live list before you plan around it.

Change data capture and its limits​

Change data capture (CDC) means reading the log where a database records every change, so you copy only what changed instead of the whole table.

Matillion calls its CDC feature streaming pipelines. Per the streaming docs, they only support relational databases: the International Business Machines (IBM) database Db2 for IBM i, Microsoft SQL Server, MySQL, Oracle and PostgreSQL. The pages say nothing about MongoDB or other non-relational sources, so don't assume.

Streaming is near-real-time, and change records are written in batches as Avro files to Amazon S3, Azure Blob Storage or Google Cloud Storage, or loaded to Snowflake. Each streaming pipeline needs its own runner. One more catch: the pricing page lists streaming change data capture only under the Scale plan.

How Matillion is priced​

Matillion sells annual packages of credits. A credit is its smallest unit of charge, and the pricing page says credits are used up by pipeline run time (called task hours) and by extra developer users. The page lists three plans and shows no dollar amount for any of them.

Matillion's pricing page, October 2026.

Source: Matillion pricing page, saved October 8, 2026.

An account can hold one active subscription, so you're on one plan at a time. You can buy directly or through the AWS, Azure or Snowflake marketplace. (A Service Level Agreement is a written promise about uptime or response times.)

The Maia Foundation meter​

The credit consumption terms set the rates for Maia Foundation. A task hour is the combined run time of each task, counted in 2-second steps, and only while a pipeline runs. Per the terms, validation and sampling are not billed.

The terms say these rates are "fixed across the customer base and non-negotiable". But they don't define "essential" and "premium", and they don't say how an always-on streaming pipeline is counted. Ask Matillion both questions before you plan a streaming budget.

Matillion's credit consumption terms, October 2026.

The Matillion ETL meter​

Now flip to the older product. The same terms page sets a different meter for Matillion ETL: one credit equals one virtual core for one hour, counted while the software is switched on in your cloud account. Each subscription includes 5 active users, and each extra one costs 50 credits in any month they log in.

Matillion's credit consumption terms, October 2026.

Matillion ETL editions are listed as Basic, Advanced and Enterprise.

Data Loader is metered by rows: in its first band, 1 to 5,000,000 rows a month, one credit buys 20,000 batch rows or 7,000 CDC rows. Matillion's own comparison post says "There's no per-user charge", yet the terms charge developer users. Our read: trust the terms over the blog post.

A worked example, with invented usage​

These numbers are illustrative: the usage is our own pick, while the rates come straight from the terms. No dollar value appears, because Matillion doesn't publish one.

Maia Foundation. Say a team on Teams has 7 developers, so 2 are beyond the 5 included. Their nightly load pipelines run 1.5 task hours a day, and their transformation pipelines run 0.5 task hours a day, for 30 days.

• Load (orchestration): 1.5 hours x 1 credit x 30 days = 45 credits.
• Transformation: 0.5 hours x 3 credits x 30 days = 45 credits.
• Extra developers: 2 x 70 credits = 140 credits.
• Total: 230 credits for the month.

The seats are the biggest slice, and a transformation hour costs 3 times a load hour.

For a 14-day trial, scale the run time: (45 + 45) x 14 / 30 = 42 credits. Even if the seat credits were also scaled, 230 x 14 / 30 is about 107. Both are far under the 500 trial credits, so they can cover a real test.

Matillion ETL. Say one instance has 4 virtual cores. Left on all month, it uses 4 x 24 hours x 30 days = 2,880 credits. Switched off outside 8 working hours a day, it uses 4 x 8 x 30 = 960 credits.

Same software, 3 times the bill. Matillion ETL bills for time switched on, not for work done.

What Matillion does not publish​

Sources: pricing page, credit terms, free trial doc.

What third parties report​

Mammoth reports $20,000 to $35,000 a year for small teams and $100,000 to $300,000 or more for enterprises. It says these figures come from Reddit and G2 posts, not from Matillion. Estuary, a rival, said in a post updated September 11, 2026 that Matillion does not publish simple starting prices.

Treat those dollar ranges as unverified reports, not quotes. Your own quote may look very different.

Costs outside the credits​

Credits are not the whole bill. Because transformations are pushed into your warehouse, the warehouse provider bills you for that compute too. Then add any marketplace terms and the Order Form overage rate.

Maia has a Budgets and alerts page. Its docs say budgets "do not restrict or block usage", so pipelines keep running past a threshold and you only get an alert (docs). A runaway job can overspend a credit pack and nothing stops it.

And watch the end of the contract. The terms allow Pay-Go for up to 60 days with no support, then access is lost unless you sign a new term.

Where Matillion fits and its limits​

What's good​

• One canvas, three ways to build. The Developer plan lists a low-code canvas with SQL and Python, pre-built connectors, unlimited projects and a built-in Git repository, and Scale adds bring-your-own Git. Matillion says a no-code designer builds custom REST API connectors.
• Scheduling and error handling are built in. Basic mode sets schedules in a graphical screen, and advanced mode takes Quartz cron expressions. The Retry component reruns a step until it succeeds or hits a maximum number of attempts, with no delay by default or a delay of about 2 seconds.
• You choose where the runner lives. In Hybrid SaaS you deploy the runner inside your own private cloud, and the docs recommend TLS 1.2 or higher between Matillion and your runners. The pricing page lists hybrid deployment under Scale.
• Usage is metered in small steps and is easy to see. The credit terms count task time in 2-second steps, and validation and sampling are not billed. The usage dashboard refreshes every 3 hours, splits credits by Orchestration, Transformation, Streaming and Additional Users, and exports to CSV. Budgets take up to two percentage thresholds and send alerts by email, Slack or webhook.
• Streaming change capture is near-real-time. The PostgreSQL source uses the Debezium PostgreSQL connector and supports versions 12 to 16. The streaming docs call the pipelines "self-healing" because they adapt to source schema changes.
• Audited security. The security page lists SOC 1 Type II, SOC 2 Type II and SOC 3 accreditation with ISO 27001 certification, and says its ISO 27001 surveillance audits finished "with no reported non-conformities".

Where it falls short​

• Streaming change capture is narrow and plan-gated. The docs say streaming pipelines "only currently support relational databases as sources": Db2 for IBM i, SQL Server, MySQL, Oracle and PostgreSQL. They are "only available to customers on specific Maia plans" and the pricing page lists them under Scale. Each pipeline needs its own runner, and a MySQL source needs a driver you provide.
• Schema changes follow the data, not the source DDL. Per the same docs, a source schema change does not reach the target until the data changes, a dropped column stays in the target with NULL values, and an incompatible type change renames the column with a timestamp suffix (_yyyymmddhhmmss). A new source table needs a new streaming pipeline.
• Output is warehouse tables or files, and the platform is closed source. The connectors page says its connectors are "built to load into Snowflake, Google BigQuery, Databricks or Redshift", and streaming writes Avro files to Amazon S3, Azure Blob Storage or Google Cloud Storage, or loads to Snowflake. No Apache Iceberg destination appears in the Maia docs index or the 2026 changelog as of October 8, 2026, and Matillion publishes no open-source licence for its platform.
• Spend is hard to predict and hard to cap. A transformation hour costs 3 credits against 1 for a load hour, the warehouse bills you separately for push-down compute, and the Retry component's backoff delays can add to billable task time. Budgets only alert, the price per credit is not public, and the overage rate is on the Order Form only (credit terms).
• Names and components keep changing. Early 2026 brought the Maia rebrand, the Enterprise edition became Scale and agents became runners. The 2026 changelog renames the Runner role to Operator and deprecates the Google Cloud Storage Load component. The MongoDB Query component is deprecated too: it "can no longer be added to new pipelines", and each run drops and recreates its target table.
• Matillion ETL runs on a support clock and bills while on. It uses 1 credit per virtual core hour while the software is switched on, whatever work it does. The supported releases page lists 1.78 LTS ending support in November 2026 and 1.80 LTS with the end date to be confirmed, and each LTS version gets 18 months of support.

Running Matillion ETL today? Check which version you're on and plan the upgrade now, not in November.

PeerSpot shows Matillion Data Productivity Cloud at 4.2 out of 5 from 28 reviews. Reviewers mention the drag-and-drop interface, limited concurrency and documentation gaps, though one calls the docs "top-notch". It's a small sample, so take it as a hint, nothing more.

What practitioners say​

Independent talk about Matillion lives mostly on review sites. We found no substantive Reddit thread, and G2, Capterra and Gartner Peer Insights block automated readers, so we didn't use them directly. Each quote below is verbatim and was checked against a saved page copy dated October 8, 2026.

Reviewers mention support and ask for clearer prices. A reviewer on the AWS Marketplace review list, which republishes G2 reviews, wrote in June 2026: "My main concern is around pricing. I'd really like more transparency and predictability on cost".

Other complaints are about setup and the older product.

An AWS Marketplace review from September 2026 said: "The onboarding documentation could be stronger. We ended up having to figure out certain workflows through trial and error".

On the older VM-based Matillion ETL, a PeerSpot reviewer wrote in April 2023: "Before considering the licensing cost of Matillion itself, you need to consider the cost of hosting the virtual machine" (PeerSpot, Matillion ETL pricing thread). That quote is old, so it doesn't describe the current Maia product.

Security and deployment​

Matillion's security page lists System and Organization Controls (SOC) 1 and SOC 2 audit reports, both Type 2, plus International Organization for Standardization (ISO) 27001, an information security standard. It says it meets the EU General Data Protection Regulation (GDPR). The text doesn't mention the US health privacy law, the Health Insurance Portability and Accountability Act (HIPAA), so ask if you need it.

Maia runs in two modes (docs). In Full SaaS, Matillion manages the runner for you. In Hybrid SaaS, you run it in your own private cloud, which gives you control over network isolation.

One catch: the runner still needs outbound internet access to Matillion's control plane.

Who Matillion suits, and who should look elsewhere​

Matillion fits teams that:

• Want load, transform and schedule on one canvas, with transformations running as SQL pushed down into Snowflake, Databricks or Amazon Redshift.
• Need an audit log and a Service Level Agreement (Teams), or custom single sign-on, data lineage tracking and 180+ day log retention (Scale).
• Must keep the runner inside their own private cloud, which the Scale plan lists as hybrid deployment.
• Want change capture from Db2 for IBM i, SQL Server, MySQL, Oracle or PostgreSQL into cloud storage or Snowflake, and can budget for the Scale plan.

Look elsewhere if you need:

• Apache Iceberg tables as output. No Iceberg destination appears in Matillion's docs index as of October 8, 2026.
• Change capture from MongoDB or other non-relational sources. The streaming docs list five relational databases only.
• A hard spending cap. Matillion's budgets only alert, and the price per credit is not public.
• A vendor-run loader: Fivetran describes its service as managed.
• Free software you run yourself: Airbyte Core (Elastic License 2.0, which restricts offering it as a hosted or managed service) or Debezium (Apache License 2.0), per their own pages.
• A published price list: compare each vendor's own pricing page.

Questions to ask Matillion before you sign​

• Plan. Is streaming change capture in my plan, and what do "essential" and "premium" mean?
• Trial. Can I test streaming and my real sources inside the 500 trial credits, and can the trial be extended?
• Credits. What is my price per credit, my overage rate, and how are always-on pipelines counted?
• Sources. Is each of my sources on the live connector list today?
• Version. If I use Matillion ETL, when does support for my version end?
• Exit. What happens at renewal, and how long does Pay-Go last?

Conclusion​

Matillion is a warehouse-focused platform for loading, transforming and scheduling data, sold by credit. Before you sign, get the price per credit in writing, run your real usage through the meter tables above, and compare at least one other quote.

FAQs​

Prices come from each vendor's own pages. We checked them on October 8, 2026. Plans change often, so confirm before you decide.

Best data integration tools by use case​

The table matches a job to a short list, plus the thing to check before you sign.

One narrow case: if you only want Postgres, MySQL, MongoDB or SQL Server changes in Iceberg or Parquet files you own, OLake Go is built for that.

What data integration means, in plain words​

Data integration means getting data out of the systems where it's created, such as databases, apps like Salesforce and files, and putting it in a warehouse (a database built for reports) or a data lake (cheap file storage many tools can read).

ETL (extract, transform, load) reshapes data before it lands, and ELT (extract, load, transform) lands it first. Change data capture (CDC) reads a database's log of changes and sends only what changed.

How we picked​

A tool had to be still sold and updated, publish pricing or billing documents we could open, and move data rather than only schedule jobs. We left out iPaaS tools (platforms that link apps through workflows) such as MuleSoft or Zapier. This is a reading of documents, not a lab test.

Two entries have a "What users say" line, copied word for word from a linked public page with the site and month. Read each as a single voice, not a verdict. Inside each group, the order is not a ranking.

Data integration tools at a glance​

Every figure below comes from the vendor's own pricing page, linked in its entry further down. "Not published" means the vendor's page shows no figure. It doesn't mean no figure exists.

Tool	Who runs it	Billing meter	Free option	Price shown on the vendor's own page, October 2026
Fivetran	Vendor	Monthly active rows (MAR) per connection	Free to 500,000 MAR	$5 base charge per connection (1 to 1M MAR); $12,000 annual minimum; per-row rates in its Service Consumption Table
Airbyte	Both	Credits	Core is free software	Cloud Standard $20 a month with 5 credits; Plus from $189 a month for 40 credits
Hevo	Vendor	Events	Free to 1M events	Starter $265 a month billed annually ($299 billed monthly); Professional $750 a month billed annually ($849 billed monthly)
Skyvia	Vendor	Records per month	Free, 10k records a month	Basic $79 a month billed annually ($99 billed monthly)
Stitch	Vendor	Replicated rows	None, 14-day trial	Standard from $100 a month; Advanced $1,500 a month and Premium $3,000 a month, both billed annually
Estuary	Both	Gigabytes plus connector instances	Free to 10 GB a month	$0.50 per GB, plus connector instances at $100 a month each for the first six, then $50
Integrate.io	Vendor	Flat fee	14-day trial	Core $1,999 a month, billing period not stated on the card
Rivery (Boomi)	Vendor	Credits	14-day or 1,000-credit trial	$0.9 per credit, Base edition pay as you go
Meltano	You	None for the software	Free, open source	Meltano Cloud dollar prices not published
OLake Go	You	None for the software	Free, Apache 2.0	Open source, no software fee; you pay for your own servers and storage
dlt	You	None for the library	Free, Apache 2.0	dltHub platform $12,000 a month, 12-month minimum
Matillion	Both	Credits per task hour	Trial only	No dollar price shown
Informatica	Both	Informatica Processing Units (IPU)	Free to 20M rows or 10 compute hours a month	No dollar price per IPU; one AWS Marketplace bundle is $131,760 for 12 months
Qlik Talend Cloud	Both	Capacity band	Not stated on the pricing page	Not published
AWS Glue	Cloud service	Data processing unit (DPU) hours	None for ETL jobs	$0.44 per DPU-hour, or $0.308 on Glue 6.0 and above (US East, Ohio)
Azure Data Factory	Cloud service	Activity runs, copy hours, data flow hours	None listed for activity runs or copying	$1 per 1,000 activity runs; $0.25 per Data Integration Unit (DIU) hour of copying (US East)

Sources: Fivetran billing docs, Fivetran Service Consumption Table, Airbyte pricing, Hevo pricing, Skyvia pricing.

More sources: Stitch pricing, Estuary pricing, Integrate.io pricing, Rivery pricing, AWS Glue pricing.

Also: Informatica's free plan, Matillion pricing, Qlik pricing and Meltano pricing.

Last sources: Azure Data Factory pricing and dltHub pricing. Informatica's figure is from its AWS Marketplace listing, shown in the screenshot below, and the $0.308 Glue rate is from AWS's published US East (Ohio) price list. Checked October 2026.

Fivetran's pricing page, October 2026.

Informatica listing on AWS Marketplace, October 2026.

What each tool does with databases and Iceberg​

This second table covers the two limits that surprise buyers most. Apache Iceberg is an open table format that lets many query engines read the same files in a data lake. Each cell comes from the vendor's docs, linked in the tool's entry or in the cell.

Tool	Database change capture, per its docs	Writes Apache Iceberg, per its docs
Fivetran	Change data capture for SQL Server (its docs); Oracle, SAP and Db2 (Beta) sources need higher plans (billing docs)	Yes, through its Managed Data Lake Service; no position deletes (a type of row-level delete)
Airbyte	Log-based on a schedule, not continuous	Yes, S3 Data Lake destination
Hevo	Log-based; streaming must be enabled by sales (docs)	Early Access, Snowflake-managed only
Skyvia	We found true CDC named only for SQL Server	Not listed
Stitch	Log-based, scheduled	Not listed
Estuary	Change capture for Postgres, MySQL, MongoDB, Oracle and SQL Server, per its pricing page	Yes, needs AWS EMR Serverless and S3
Integrate.io	Lists CDC among its products (pricing page)	Not listed
Rivery (Boomi)	Oracle CDC on the Enterprise edition, per its pricing page	Not listed
Meltano	Depends on the tap (connector) variant	No official loader
OLake Go	Postgres, MySQL/MariaDB, MongoDB and SQL Server, per its docs (not tested by us)	Yes, Iceberg tables or Parquet files are its only outputs
dlt	Postgres replication source is the only log-based option we found in its open-source docs	Yes, through PyIceberg
Matillion	Streaming CDC listed on the Scale edition (pricing page)	Not listed
Informatica	Yes for many database sources, per its database ingestion docs	Describes Snowflake-managed Iceberg tables for database ingestion; the formats behind its "Open Table" target are not stated
Qlik Talend Cloud	Log-based from the Standard edition	Yes, Qlik Open Lakehouse
AWS Glue	Zero-ETL from self-managed Oracle, SQL Server, MySQL and PostgreSQL goes to Redshift only	Yes, read and write
Azure Data Factory	Native CDC for a short list of sources	Copy activity can write Iceberg to Azure Data Lake Storage Gen2 only

"Not listed" means we did not find it in the vendor's docs, which is not proof it is missing. Check the docs for your catalog, delete handling and who runs file cleanup.

What one month costs, where the page lets you work it out​

Only some vendors let you work out a monthly number from public pages. The workloads below are invented illustrations, so swap in your own, and don't read the rows as a ranking.

Sources: Hevo pricing, Estuary pricing, Integrate.io pricing, dltHub pricing, AWS Glue pricing and the Service Consumption Table.

The Informatica bundle is from its AWS Marketplace listing, and $0.308 is from AWS's US East (Ohio) price list. Checked October 2026.

Estuary's row counts the 50 GB twice, once in and once out, because Estuary's own pricing example does: 800 GB and 2 connector instances show as $1,000 a month. On Fivetran, the Service Consumption Table says Standard starts at $495 per million monthly active rows (MAR) plus a $5 base charge for the first tier.

These sums cover each vendor's own meter and nothing else. Glue jobs also need storage and a catalog, and Estuary's Iceberg connector needs a Spark application on AWS and an S3 bucket, which AWS bills separately. Airbyte Core, Meltano, dlt and OLake Go have no software fee, but you pay for servers and staff time.

How to choose​

Four questions, asked in order. Stop as soon as you're down to two or three tools.

1. Who will run it? If nobody on your team can, look at the vendor-run tools. If you have engineers who will, add Airbyte Core, Meltano, dlt and OLake Go.
2. What are the sources? Mostly SaaS apps? Look at Fivetran, Hevo or Airbyte. Databases that need fresh data point to Estuary, Qlik Talend Cloud or Fivetran Enterprise.
3. Where must the data land? A warehouse is easy almost everywhere. Iceberg tables on your own catalog shrink the field to the second table above, and each tool there has limits.
4. Can you price it? If the meter counts rows, events or credits, price your busiest month, not your average one. If the vendor won't print a rate, ask for a written quote that states your volume.

If your sources include databases, put three more questions to each vendor and ask them to point at a docs page:

• What happens if the change log is gone before the tool reads it? Databases keep change records for a limited time. Fivetran's SQL Server page says the default window is 3 days and recommends 7.
• Does it run continuously or on a schedule? Airbyte's CDC docs say syncs are scheduled, and Hevo's docs say streaming must be enabled through its sales team. Both are linked in their entries below.
• Which Iceberg features does the writer skip? Fivetran's Managed Data Lake Service page (linked in the table above) says it does not support position deletes for Iceberg tables. Other tools list their own limits, so read the destination page before you sign.

The 16 best data integration tools​

Vendor-run tools for databases and apps​

1. Fivetran: best for SaaS sources and a hands-off setup​

Fivetran home page, October 2026.

At a glance

• Billing: monthly active rows (MAR) per connection
• Free option: Free plan up to 500,000 MAR

Fivetran runs pre-built connectors that copy data from apps, databases and files into a warehouse or lake. We did not test any of it.

Fivetran's billing docs say pay-as-you-go adds a $5 base charge to each connection that uses 1 to 1M rows, with a $12,000 minimum for annual contracts. Per-row list rates are in its Service Consumption Table: Standard starts at $495 per million MAR, then falls to $170 per extra million from 1 million MAR, before discounts.

What's good

• Its pricing page claims 700+ connectors and 200+ activation destinations (reverse ETL), with 15-minute syncs on Standard and 1-minute syncs on Enterprise. We did not count the connectors or test the sync times, so ask for a trial on your own sources.
• Per its billing docs, the Free plan has all Standard features up to 500,000 connector MAR, 3,500 activation MAR and 5,000 model runs a month, and annual contracts carry a built-in 5% discount.
• Its Service Consumption Table puts each connection on its own volume curve. Standard list rates run from $495 per million MAR for the smallest connections to $170 per million from 1M MAR, $58 from 4M and $19.70 from 16M, before discounts.
• Its SQL Server page lists four incremental sync methods: change tracking, change data capture, Binary Log Reader and Teleport Sync. Teleport Sync compares row hashes between syncs instead of reading the transaction log, and the page suggests it when enabling change tracking or CDC is not feasible.
• Its Managed Data Lake Service docs say your data stays in your own cloud storage account (Amazon S3, Azure Data Lake Storage or Google Cloud Storage), and that Fivetran always creates Iceberg table metadata and manages the catalogs and maintenance, with snapshot cleanup once a day.

Where it falls short

• Per its billing docs, Oracle, SAP and Db2 (Beta) database sources are only on Enterprise and Business Critical, so the free plan can't use them, and its High-Volume Agent connectors for Oracle and SQL Server are listed for those two plans as well.
• The pricing page prints no per-row rate (the list rates are in the Service Consumption Table), and since January 1, 2026 deleted rows count as paid MAR, per Fivetran's pricing update.
• The Service Consumption Table says you cannot combine MAR across connections for a better rate, so each connection pays its own base spend, such as the $500.00 the table lists at the 1M MAR tier on Standard.
• On SQL Server, the same page gives a default CDC retention window of 3 days (7 recommended). With CDC on, column type changes carry over, but renamed columns, new tables and new columns do not, and new ones need a new CDC instance.
• Its Managed Data Lake Service page lists no support for position deletes on Iceberg tables, and on AWS lakes none for the S3 Glacier Flexible Retrieval, Glacier Deep Archive and Intelligent-Tiering archive tiers (docs).
• The same docs say orphan files are moved to an orphans folder on the second and fourth Saturday of each month, and that deleting or editing that folder can permanently damage your tables.

What users say: A commenter on a Hacker News thread about the Fivetran and dbt Labs merger wrote in October 2025, "Fivetran is convenient but absurdly expensive."

2. Airbyte: best for a big connector list you can self-host or rent​

Airbyte home page, October 2026.

At a glance

• Billing: credits on Cloud, nothing for Core
• Free option: Core is free; Cloud has a 14-day free trial

Airbyte is one product wearing several hats: Core (self-run), Cloud (Standard, Plus and Pro) and Enterprise Flex (hybrid). On its pricing page, Cloud has a 14-day free trial, Standard starts at $20 a month with 5 credits and extra credits at $5 each, and Plus starts at $189 a month for 40 credits. Pro and Enterprise Flex show "Custom".

What's good

• Core has no credit meter, so you pay for servers and staff time instead. Cloud is the rented option, billed in credits.
• Per its licence FAQ, anyone can use Airbyte free of charge and run it at scale on their own infrastructure, with "no limitations exist on volume, number of users, number of connections, etc." for open source users.
• Its pricing page lists 700+ connectors on all four plans, with a maximum sync frequency of 1 hour on Standard, 15 minutes on Plus and 5 minutes on Pro and Enterprise Flex.
• Its CDC docs list current support for Postgres, MySQL, SQL Server, MongoDB, Oracle, SAP HANA and IBM Db2.
• Its S3 Data Lake docs say the connector writes Iceberg tables to S3 or S3-compatible storage through a REST, AWS Glue, Nessie or Polaris catalog, and its Append + Deduped mode is merge-on-read on the stream's primary keys.

Where it falls short

• Airbyte's CDC docs say "We do not treat CDC sources as infinite streaming sources", so syncs run on a schedule. Its sync schedules page lists hourly as the shortest, bar 15 minutes on Cloud Plus.
• The same CDC docs say CDC incremental needs primary keys for most sources, changes made by TRUNCATE or ALTER do not appear in the logs and so not in the destination, and a refresh is required after you add a table to a CDC connection.
• Core uses the Elastic License 2.0, which its licence FAQ says bars selling a hosted Airbyte service.
• Its S3 Data Lake docs say the connector never rewrites existing Iceberg data files, so it handles only adding or removing a column, widening a column and changing the primary key. Objects and unions are written as serialized JSON strings.
• The same page does not say who handles compaction or snapshot expiry, and it cautions that compaction running during a truncate refresh sync deletes files from the current generation and causes data loss.
• It also warns that Snowflake does not recognize native Iceberg row-level deletes for tables in external catalogs such as Glue, so queries there return all versions of a record.

Airbyte's pricing page, October 2026.

3. Hevo: best for a low entry price and a free plan​

Hevo Data home page, October 2026.

At a glance

• Billing: events (each record inserted, updated or deleted)
• Free option: Free, up to 1M events a month and 5 users

Hevo is a managed service for ETL and ELT pipelines, and it's one of the few that shows entry prices up front. On its pricing page, Starter shows $265 a month billed annually, or $299 a month billed monthly, for 5M events. Professional shows $750 a month billed annually, or $849 a month billed monthly, for 20M events.

What's good

• Its page shows a free plan (labelled "free forever for limited connectors") and entry prices up front. The 24/7 support and 150+ connector figures on the Starter card are Hevo's claims, which we did not test.
• Per its docs, log-based pipelines read BinLog (MySQL), logical replication (PostgreSQL), Streams (DynamoDB), change streams or OpLog (MongoDB), Change Tracking (SQL Server) and redo logs (Oracle).
• Its pricing page shows the Free plan with up to 5 users, and Starter adding up to 10 users, a dbt integration and SSH/SSL.
• Its Snowflake Iceberg docs say the table data and metadata files are stored in your Amazon S3 bucket, and that external engines such as Spark and Trino can read the tables through the Horizon Iceberg REST Catalog API.

Where it falls short

• Hevo's docs say streaming pipelines must be enabled through its sales team and are not available for SQL Server or DynamoDB.
• Its pricing page shows 1-hour scheduling on the Free and Starter plans, and "limited connectors" on Free against all connectors on Starter and above.
• Usage above your plan's event quota is billed on-demand on top of the plan, and the page shows no rate for it (pricing FAQ).
• Its Iceberg option is Early Access and Snowflake-managed only, per its docs. It must be enabled through a Hevo account executive or Support, and needs a Snowflake account, warehouse and database, an S3 bucket with an IAM policy, and a Snowflake external volume.
• The log-based docs list troubleshooting pages for "Pipeline failure due to BinLog expiry" (MySQL) and "Redo Log expiry" (Oracle), so log retention on your source matters (docs).
• We also found no self-hosted edition.

Hevo's pricing page, October 2026.

4. Skyvia: best for small teams that want a no-code tool​

Skyvia home page, October 2026.

At a glance

• Billing: records per month
• Free option: Free plan, 10k records a month, once a day

Skyvia is a no-code cloud service from Devart, so you click rather than code. Its pricing page shows Basic at $79 a month with the annual toggle and $99 monthly.

What's good

• A low entry price and a no-code builder.
• Its pricing page shows unlimited connections and users on all four plans, with the maximum run frequency at once a day on Free and Basic, once an hour on Standard and once a minute on Professional.
• Scheduled integrations run 2 on Free, 5 on Basic, 50 on Standard and unlimited on Professional, and schedules expire after 30 days on Free only.
• The page has a Monthly/Annually toggle labelled 20% off above the plan cards.
• Enterprise is a custom annual package with a dedicated virtual machine, unlimited record volume and priority support, with a quote on request.

Where it falls short

• We found true CDC named only for SQL Server in its docs, and no log-based CDC for other databases.
• We found no Iceberg destination in its docs.
• Per the pricing page, the Free and Basic plans run at most once a day and list simple mapping features, with advanced mapping starting at Standard.
• Free allows 2 scheduled integrations and Basic 5, while Standard allows 50 (pricing page).
• Additional records are billed beyond each plan's allowance at $0.06 and $0.02 per 1,000 records, but the page text does not label which plan each rate belongs to.

5. Stitch: best for simple row-based loading, with an owner change to know​

Stitch home page, October 2026.

At a glance

• Billing: replicated rows per month
• Free option: none, 14-day trial

Its home page says Stitch is now part of Qlik and tells new users to try Qlik Talend Cloud. Its pricing page shows Standard from $100 a month for 5M rows, Advanced at $1,500 a month billed annually, and Premium at $3,000 a month billed annually.

What's good

• Its log-based replication docs name MySQL, PostgreSQL, MongoDB, SQL Server, Oracle and DynamoDB.
• Its pricing FAQ says you set the replication frequency for each integration, from minutes to hours, and every user can use cron-expression scheduling.
• The Standard card lists 5 to 300 million rows a month, 5 users and 7-day extraction log retention, and Premium lists 1 billion rows a month and 5 destinations.
• Its home page advertises 130+ data sources, a vendor claim we did not count.

Where it falls short

• We found no Iceberg in its destination list.
• The home page says Stitch is now part of Qlik and points new users to Qlik Talend Cloud, and it publishes no end-of-life date.
• Per its log-based docs, log-based replication on PostgreSQL works only with a master instance, some cloud versions of the supported databases may not support it, and changes made by event types the database does not write to its log are not detected.
• The pricing page lists 1 destination and 10 standard sources on Standard, and "Unlimited (Enterprise sources)" on Advanced, so connectors marked Enterprise sit in a higher tier.
• The page shows no overage rate per row beyond a plan's allowance, and Advanced and Premium are billed annually, so you commit for a year at a time.
• Support is chat and email during regional business hours (8 a.m. to 8 p.m. Eastern, Monday to Friday), per the same FAQ.

6. Estuary: best for streaming and batch from one tool​

Estuary Flow home page, October 2026.

At a glance

• Billing: $0.50 per GB plus connector instances
• Free option: 10 GB a month and 2 connector instances

Estuary captures data into collections and sends it on to destinations, with real-time and batch modes. The fee structure has a quirk. On the Cloud plan the first six connector instances are $100 a month each, then $50 each, according to its pricing page.

What's good

• Its pricing page FAQ lists Postgres, MySQL, MongoDB, Oracle and SQL Server among supported databases and says change capture streams changes in real time.
• The same FAQ says a pipeline starts with a historical backfill and then switches to real-time CDC, and that you can disable or scope the backfill.
• The Cloud plan lists "Millisecond latency or batch, no extra charge" and a 30-day free trial that starts on its own when you pass the free tier, with no credit card.
• Adding a target means paying only for that target and the data sent to it, with no need to re-extract from each source (pricing FAQ).
• Its Iceberg docs support AWS Glue catalogs and S3 table buckets, and let you set Glue Table Optimizers for compaction, snapshot retention and orphan file deletion.

Where it falls short

• Its Iceberg connector (docs linked in the table above) runs Spark jobs on a compute system you configure, and the docs list an AWS EMR Serverless Spark application (release emr-7.7.0), an S3 bucket and dedicated IAM roles as prerequisites.
• Each connector instance adds a monthly fee on top of the per-GB charge, and those fees add up.
• The Iceberg docs label the section for REST catalogs other than AWS Glue as Beta, and say only REST catalogs that use Amazon S3 storage are supported, with GCP and Azure planned.
• The same page says nested types are not currently supported, and array and object fields are written as string columns.
• Compaction through the Glue optimizer defaults to off, and Hard Delete is off by default, so deletes in the source stay as soft deletes unless you change it.
• The Cloud plan lists standard support through community Slack and email, and custom SLA terms appear only in the Enterprise column (pricing page).

Estuary's pricing page, October 2026.

7. Integrate.io: best for a flat fee and visual pipelines​

Integrate.io home page, October 2026.

At a glance

• Billing: flat fee, "unlimited data volumes" on the pricing page
• Free option: 14-day trial

Per its pricing page, Integrate.io sells ETL, ELT, CDC and reverse ETL (sending warehouse data back to apps). The page lists Core at $1,999 a month with a 60-second pipeline frequency, and the card shows only "/mo" with no billing period. Its terms describe paid plans with prepaid node hours that are "monthly and billed annually", so ask in writing what Core includes.

What's good

• A flat list price, so there is no per-row meter on the pricing page.
• Per its pricing page, the Core card lists unlimited data volumes, pipelines and connectors, full platform access, 60-second pipeline frequency and 30-day onboarding.
• Its FAQ says it covers 150+ sources and destinations, including Salesforce, HubSpot, Shopify, Stripe, MySQL, PostgreSQL, MongoDB, Snowflake, BigQuery and Redshift.
• The FAQ also says every plan includes 24/7 support with a 2-minute average first response, a vendor claim we did not test.

Where it falls short

• We found no Iceberg destination in its docs.
• Its terms say subscription periods are monthly and billed annually and renew automatically for a year unless you give notice, that fees are non-refundable, and that you pay the whole subscription period even if you stop using the service.
• The same terms have a fair usage policy: usage far above its norms may be reviewed, with remedies that include service limitations or pricing changes, which sits beside the pricing page's "No limits on data volume" header.
• The terms also allow overage fees if you exceed the node hours in your plan, and let the company revise fees with at least 7 days' notice on a paid plan.
• After the free trial, an account with no paid plan is downgraded to a free plan that cannot run jobs, and the terms say you may lose access to stored packages and schedules.
• The "Design Your Plan" card on the pricing page shows no price.

8. Rivery (Boomi Data Integration): best for credit-based ELT​

Rivery (Boomi Data Integration) home page, October 2026.

At a glance

• Billing: credits
• Free option: 14 days or 1,000 credits

Rivery now carries the Boomi Data Integration name. Its pricing page counts in Boomi Data Unit credits and lists $0.9 per credit pay as you go on the Base edition, with database sources charged by bytes moved.

What's good

• It publishes a credit price on its pricing page.
• Per its pricing page, database, file and webhook sources are charged only on data transferred, at 1 credit per 100MB regardless of how often you run. Its example of 1,725MB a month from Postgres to a warehouse is 17.25 credits.
• The same page says it does not charge per connector or per user, and every data source is available on every edition.
• The Base edition lists one environment, two users and unlimited connections, and the maximum sync frequency is 60 minutes on Base, 15 on Professional and Pro Plus, and 5 on Enterprise.

Where it falls short

• Its pricing page puts Oracle CDC on the Enterprise edition only.
• We found no Apache Iceberg destination in its docs.
• Log-based CDC is charged 2 credits per 100MB, double the 1 credit per 100MB for standard database replication (pricing page).
• API sources are charged by run: 0.5 credit each time data is ingested from a single output table, 0.5 credit per 50MB above 50MB per run, and 0.5 credit for a run that finds no data.
• Professional shows only "Start for free", and Pro Plus and Enterprise show "Contact Sales", so only the Base edition has a printed price.
• The $0.9 per credit rate is for monthly billing, the page says annual billing saves more but prints no annual price, and Base is limited to 2 users and 1 environment.

Open-source tools you run yourself​

9. Meltano: best for pipelines kept as code​

Meltano home page, October 2026.

At a glance

• Billing: none for the software
• Licence: open source
• Owner: Matatika (its pricing page calls it "an open source project by Matatika")

Meltano is the option that lives in Git. Its pricing page says it is "Open source and free to use, with paid support options". It runs Singer taps, small programs that pull data from a source, and keeps settings in Git files.

What's good

• No software fee, so you pay for servers and staff time instead.
• Per its pricing page, every plan, including the open-source one, gets the full library of 600+ connectors, and pipelines are Git-native.
• The Meltano Cloud plans list 200 compute hours a month on Starter (25 workspaces, unlimited users, reverse ETL included), 2,000 on Growth and 5,000 on Scale, with 8 and 15 hours of engineering on demand on Growth and Scale.
• Paid support options are listed beside the free software.

Where it falls short

• CDC depends on the tap variant, and its Hub lists no official Iceberg loader.
• The same page says self-hosted Meltano is "not really suited for production teams unless you have a dedicated DevOps crew."
• Its FAQ says that with Meltano Open you manage your own infrastructure, monitoring and uptime.
• No dollar price is shown on any Meltano Cloud plan, and Enterprise is custom, so budgeting a hosted plan needs a quote.

10. OLake Go: best for database changes into Iceberg or Parquet on your own storage​

OLake home page, October 2026.

At a glance

• Billing: none for the software
• Free option: open source under Apache 2.0, you pay for your own servers and storage
• Runs on: your own infrastructure

OLake Go is an open-source tool, Apache 2.0 on GitHub, that copies database tables into Apache Iceberg tables or Parquet files. You run it yourself with Docker, Helm on Kubernetes, the OLake UI or the command line.

Docs: Postgres, MySQL, MongoDB, SQL Server. We did not test any connector.

What's good

• Its docs list change data capture for Postgres, MySQL (including MariaDB), MongoDB and SQL Server, and Oracle, Db2, S3 and Kafka sources without it.
• It writes Iceberg tables or Parquet files to Amazon S3, MinIO or Google Cloud Storage, and its catalogs page lists the Iceberg catalogs.
• The docs list four sync modes: Full Refresh, Full Refresh + Incremental, Full Refresh + CDC and CDC Only. For its database sources, one tool does the first load and then the change capture.
• Syncs split large tables into chunks that are read in parallel, and they resume automatically from the last checkpoint after an interruption (docs).
• For the Iceberg destination, it uses a two-phase commit during full refresh, incremental and CDC (MongoDB, Postgres, MySQL, SQL Server), tracking per-chunk commit status so syncs avoid duplicate writes (docs).
• In Upsert mode it can write equality deletes, positional deletes or Iceberg v3 deletion vectors (docs), and its partitioning guide covers identity, year, month, day, hour, bucket and truncate transforms.

Good to know

• It reads databases, Kafka and S3 only: there are no SaaS-app sources and no transformations.

Bottom line: Pick it if you run Postgres, MySQL, MongoDB or SQL Server and want the data in Iceberg or Parquet on storage you own. For support or enterprise terms, contact the OLake team.

11. dlt: best for Python teams that want a library​

dlt / dltHub home page, October 2026.

At a glance

• Billing: none for the library
• Licence: Apache 2.0

dlt (data load tool) is a Python library you add to a script, so there's no server to sign up for. Its pricing page says the library stays Apache 2.0 and lists the dltHub platform at $12,000 a month with a 12-month minimum. One line in its FAQ says $11,900, so we quote the headline figure.

What's good

• Sources cover SQL databases, REST APIs and files, and its Iceberg docs say Iceberg tables are written through PyIceberg.
• The same docs say dlt uses PyIceberg's catalog loading, so it works with the catalogs PyIceberg supports, including REST and SQL catalogs, and supports upsert and insert-only merge strategies.
• Iceberg partitioning is set with an iceberg_adapter that offers year, month, day, hour, bucket and truncate transforms.
• Its Postgres replication docs say it reads changes through logical decoding with the built-in pgoutput plugin, and describe Debezium as a route for CDC from other databases.
• Its pricing page says "The dlt library stays Apache 2.0, always".

Where it falls short

• Iceberg needs a catalog setting, and without one dlt falls back to an in-memory SQLite catalog.
• Its Postgres replication source is the log-based option we found in the open-source docs, and it does not support the scd2 merge strategy.
• Per the Iceberg docs, partition evolution is not supported, upsert runs in chunks of 1000 rows until a later PyIceberg release, and schema changes are not supported with upsert on PyIceberg 0.10.0.
• The same docs do not support the az scheme with Iceberg (use abfss), and on Google Cloud Storage they mark service accounts as not supported.
• The pricing FAQ says every paid dltHub subscription includes a licence for source-available capabilities including CDC and Apache Iceberg support, and the open-source Iceberg page does not say which features need a subscription (pricing FAQ).

What users say: In a July 2026 newsletter post about moving one pipeline off Fivetran, the author wrote "The pipeline does not reproduce Fivetran's soft-delete behavior for physical source deletes". Keep in mind that's one person's test.

Enterprise suites​

12. Matillion: best for transformations inside a cloud warehouse​

Matillion home page, October 2026.

At a glance

• Billing: credits per task hour
• Free option: trial only

Matillion's product is now called Maia, which its credit terms say was previously Data Productivity Cloud (so older articles use the old name). Its credit terms set 1 credit per task hour for pipelines that run jobs, 3 for transformation pipelines, and 1 or 2 for streaming CDC.

What's good

• Its credit terms name Snowflake, Amazon Redshift, Google BigQuery and Databricks as example cloud data platforms, and price transformation pipelines on their own meter.
• Per its credit terms, Task Hours are charged only while a pipeline runs, in 2-second increments, and validation and sampling do not count.
• Its pricing page shows Developer with 1 developer user, unlimited projects, a low-code canvas with SQL or Python and a built-in Git repository, and Teams with 5 developer users, an audit log and a service level agreement.
• Scale adds custom SSO, hybrid cloud deployment, data lineage and streaming change data capture, with 180+ days of log retention.
• Its FAQ says you can contract directly or pay through your AWS, Azure or Snowflake account.

Where it falls short

• Its pricing page lists streaming change data capture on the Scale card, and we found no dollar price shown there.
• We found no Iceberg target in its docs.
• The credit terms put Developer Users at 70 credits per user a month, and the terms state no dollar price per credit, so cost cannot be worked out from public pages.
• The terms price an essential CDC pipeline at 1 credit per task hour and a premium one at 2, but do not define the two types.
• Under Pay-Go, the period cannot exceed 60 days after the contracted term, you lose access to all products unless you sign a new term, and the overage rate is on the Order Form.
• The comparison table shows community support on Developer, and the service level agreement as "Included with Annual subscription".

13. Informatica: best for governance and large, mixed estates​

At a glance

• Billing: Informatica Processing Units (IPU)
• Free option: Free Cloud Data Integration to 20M rows or 10 compute hours a month

Its Cloud and Product Description Schedule, version 39.2 from September 11, 2026, prints Informatica Processing Unit (IPU) rates per service, such as 0.1 IPU per GB for the first 2 TB of database ingestion.

What's good

• Its database ingestion docs list many sources, including Db2, SAP HANA, Teradata (initial load only) and Oracle. We did not test any connector.
• The same docs mark SQL Server, MongoDB, MySQL, PostgreSQL, Oracle, Db2 and SAP HANA as supported for initial, incremental and combined loads, and list targets such as Amazon S3, Databricks, Google BigQuery and Snowflake.
• Its Cloud and Product Description Schedule prints the meter: database ingestion change capture is 6.5 IPU per million rows for the first 15M, 0.55 from 15M to 750M and 0.05 above that.
• The same document says Database Ingestion and Replication jobs run on a Secure Agent that you install in your own environment, or serverless on an Informatica-managed environment on Azure, subject to applicable functionality.
• Its docs have separate pages on Oracle log access methods for CDC, log-based CDC for SAP HANA and change capture mechanisms for SQL Server.

Where it falls short

• We found no dollar price per IPU on Informatica's site, so you'll need a quote. The AWS Marketplace listing shows 120 IPUs a month for $131,760 over 12 months, with 12, 24 and 36 month contract tabs.
• Its database ingestion docs describe Iceberg only as Snowflake-managed Iceberg tables, and they do not say which formats its "Open Table" target covers.
• Under the monthly IPU model, IPUs do not carry over to the next month, and going over means you must subscribe to more IPUs for the rest of the period (schedule).
• The schedule does not say whether a volume tier applies to the whole quantity or only the units inside each band.
• For Azure SQL Database sources, the docs say log-based capture with a transaction log is not supported, and incremental loads use query-based and CDC Tables capture.
• IPU and Flex IPU must be provisioned separately and cannot be deployed in the same Org.

14. Qlik Talend Cloud: best for CDC plus Iceberg from one vendor​

Qlik Talend Cloud home page, October 2026.

At a glance

• Billing: a capacity band based on data volume, job runs and run time
• Free option: not stated on its pricing page

Qlik's pitch is CDC and Iceberg from one vendor. Its pricing page puts log-based CDC and Qlik Open Lakehouse for Apache Iceberg in the Standard edition. We did not test either, and the page prints no price, so ask for a written quote that states your volume.

What's good

• Log-based CDC and Qlik Open Lakehouse for Apache Iceberg, both from the Standard edition.
• Its pricing page lists "Cloud, client managed, or hybrid deployment" under Standard.
• Enterprise lists SAP application and Mainframe connectivity, as everything in Premium plus that.
• Qlik says usage is measured by data volume moved, job executions and execution duration, and customers can watch it in a self-serve telemetry dashboard.

Where it falls short

• No dollar price is published, and the Starter edition has no CDC.
• Starter, Standard, Premium and Enterprise all show "Contact Us" on the pricing page, and prices for Talend Data Fabric are not published either.
• Because usage combines three measures (volume, job runs and run time), predicting a bill needs figures from all three.
• The page lists SAP and Mainframe connectivity only under Enterprise, and states no free option.

Cloud-provider services​

15. AWS Glue: best for Spark jobs inside AWS​

AWS Glue home page, October 2026.

At a glance

• Billing: data processing unit (DPU) hours, per second
• Free option: none for ETL jobs

AWS Glue is a serverless service for finding, preparing and moving data (serverless means you don't manage the servers). AWS's pricing page lists $0.44 per data processing unit (DPU) hour for ETL jobs and $0.308 on Glue 6.0 and above, in US East (Ohio), per AWS's price list.

What's good

• You do not manage servers, and its docs say it can read and write Iceberg tables in S3 (Glue 3.0 and later).
• Per the same docs, Glue 6.0 supports Iceberg table format versions 2 and 3 (v2 by default), and Glue 4.0 and later use optimistic locking for Iceberg by default.
• AWS's pricing page bills per second with a 1-minute minimum, and the FAQ says you pay for the time your job runs, not for environment provisioning or shutdown.
• The Data Catalog's first million objects and first million requests a month are free, and Flex jobs cost $0.29 per DPU-hour ($0.203 on Glue 6.0 and above) in the US East (Ohio) price list.
• Its zero-ETL docs list DynamoDB, Oracle Database@AWS and SaaS apps such as Salesforce, SAP and Zendesk as sources, with S3 and S3 Tables among the targets, and AWS charges no extra fee for the integration itself.

Where it falls short

• Its zero-ETL docs list self-managed Oracle, SQL Server, MySQL and PostgreSQL sources, and add that for those sources you can replicate "only to an Amazon Redshift data warehouse." We found no log-based CDC engine documented for Glue ETL jobs themselves.
• An ETL job needs at least 2 DPUs, and by default Glue gives each job 10, per its FAQ.
• The Iceberg page says "Update is not supported for Iceberg tables", and ALTER TABLE RENAME is not available on Glue 3.0 with Iceberg 0.13.1 (docs).
• Glue 3.0 with Iceberg 0.13.1 also needs a DynamoDB lock manager configuration, and moving a table from Iceberg v2 to v3 cannot be reversed.
• Costs sit outside DPU-hours: temporary, shuffle and data quality files in S3 are billed at S3 rates, and Data Catalog objects past the first million cost $1 per 100,000 a month (pricing page).

16. Azure Data Factory: best for pipelines inside Azure​

Azure Data Factory home page, October 2026.

At a glance

• Billing: activity runs, copy hours and data flow hours
• Free option: none listed for activity runs or copying

Azure Data Factory is Microsoft's managed ETL and ELT service.

Azure's price list for US East shows $1 per 1,000 activity runs and $0.25 per Data Integration Unit (DIU) hour for copying, with data flows billed separately.

What's good

• A self-hosted integration runtime for on-premises data, priced per hour.
• Its CDC docs page say "Pipelines in ADF are batch only, but the CDC resource can run continuously", and that native CDC uses the database's own change data capture with no timestamp or ID columns needed.
• The same page lists auto incremental extraction for sources including SQL Server, Azure Database for MySQL and Azure Database for PostgreSQL, and says ADF manages the checkpoint for each activity run.
• The pricing page describes the integration runtime as serverless in Azure and self-hosted in hybrid scenarios, with charges prorated by the minute.
• Its Iceberg format page covers an Iceberg sink in the Copy activity, with IcebergSink and IcebergWriteSettings (docs).

Where it falls short

• Its CDC docs page lists native CDC for SAP, Azure SQL, SQL Server, Cosmos DB and Snowflake, and not for PostgreSQL, MySQL, MongoDB or Oracle.
• Its Copy activity can write Iceberg only to Azure Data Lake Storage Gen2, per its Iceberg format page, which shows a dataset type and folder location but no catalog setting and no update, delete or merge setting.
• For auto incremental extraction from databases, the CDC page says an incremental column is required to identify the changes.
• The CDC resource is billed for four cores of General Purpose data flows while data is processed, and the pricing page ties that rate to the period "during public preview of CDC".
• Data flows have an 8 vCore minimum cluster and also bill for managed disk and blob storage, and copying data out of an Azure datacenter adds a separate outbound transfer line.

FAQs​

ETL (extract, transform, load) copies data out of one system, reshapes it, and loads it into another. Many teams now load first and reshape later (ELT), and people search for both as "ETL", so this page covers both.

Prices and limits come from each vendor's own pages, read on 8 October 2026. Rates change often, so confirm on the vendor's page before you buy.

AWS loads its rate tables in the browser, so the AWS rates below come from its official price list files. Those are the Glue file (US East, Ohio, published 6 October 2026) and the DMS (Database Migration Service) file (US East, N. Virginia, published 11 September 2026).

AWS ETL tools at a glance​

Tool	Kind	Best for	Database change capture	Billing unit
AWS Glue	AWS service	Spark code, batch jobs, the Data Catalog	Not found in the docs for self-managed databases	DPU-hours
AWS DMS	AWS service	Moving a live database into AWS	Yes, from database logs	Instance or capacity hours
Glue zero-ETL	AWS feature	SaaS apps and DynamoDB into the lake	Self-managed databases go to Redshift only	Per GB ingested plus compute
Amazon AppFlow	AWS service	Small SaaS pulls into S3 or Redshift	Not found in the docs	Flow runs and GB
Amazon Data Firehose	AWS service	Streams into S3, Redshift or Iceberg	Database source preview ended	Per GB
OLake Go	Open-source replication	Database changes into Iceberg or Parquet	Yes, from database logs, for four databases	Free licence, you run the servers
Fivetran	Managed ELT	Many connectors, no servers	Not covered here	Monthly active rows
Airbyte	Self-hosted Core and cloud	Connector choice, self-hosting	Yes, on scheduled syncs	Credits (Cloud), free (Core)
Hevo	Managed ELT	Small teams, Redshift	Log-based pipelines per its docs	Events
Matillion	Managed ETL	Visual pipelines in Redshift	Streaming CDC listed on the Scale card	Credits
Informatica	Enterprise suite	Large, governed estates	Not covered here	Processing units

How we picked​

Two tests. A tool had to move data into AWS storage or a warehouse, and its own pages had to say how you buy it or how it bills. We started with AWS's own services, then added outside tools that name Amazon Redshift or S3 as a destination in their docs.

This is a reading of vendor documents, not a lab test. We did not run these tools.

Entries carry a "What users say" line only where a public thread or review page we opened in October 2026 shows a concrete experience. Every quote is one person's view, not a verdict.

Anything we could not source from a primary page is left out, which covers AWS Lambda, Amazon EMR (Elastic MapReduce), Amazon MWAA (Managed Workflows for Apache Airflow) and Amazon Kinesis Data Streams as stand-alone ETL options. The tools are grouped by kind, not ranked: each entry says what it is best for and where it is the wrong choice.

Which tool fits which source​

Your source cuts the list in half. A SaaS app has an API and no database log. Databases keep a log of changes that some tools can read, and streams or piles of files need a different kind of tool again.

You will see change data capture (CDC) a lot below. It means reading a database's own log of changes instead of re-reading whole tables, which keeps a copy fresh without hammering the source.

The 11 best AWS ETL tools​

AWS native services​

1. AWS Glue: best for Spark code and batch jobs​

AWS Glue home page, October 2026.

At a glance

• Kind: serverless Spark-based ETL (extract, transform, load) service
• Billing: DPU-hours, billed by the second per the Glue FAQ (a DPU is a data processing unit, the compute Glue rents to run a job)
• Rates: $0.44 per DPU-hour for earlier Glue versions and $0.308 for Glue 6.0 and above (US East, Ohio, AWS price list file published 6 October 2026)

AWS describes Glue as a serverless data integration service. Glue runs jobs on Apache Spark, a data processing engine, and has a visual editor called Glue Studio. Alongside jobs it keeps the Glue Data Catalog, a table list that other tools below can use as an Iceberg catalog (the index that tells an engine where a table's files are).

AWS announced Glue 6.0 on 21 August 2026 with "30% lower pricing than previous AWS Glue versions" (AWS News Blog). AWS's job docs say a job created without a version defaults to Glue 5.1, which is the higher rate, so set the version on purpose.

What's good

• AWS says Glue is serverless, so there is no infrastructure to manage, and that you can connect to "more than 70 diverse data sources". Other tools here can write to its Data Catalog.
• You pay for the time a job runs, not for environment provisioning or shutdown, and billing is per second with a 1-minute minimum (Glue FAQ).
• The Data Catalog's first million metadata objects and first million requests a month are free, and extra objects cost $1.00 per 100,000 a month (pricing page).
• Worker sizes run from G.1X (1 DPU, 4 vCPU, 16 GB) up to G.16X (16 DPU, 64 vCPU, 256 GB), per the job docs.
• Iceberg table optimization in the Data Catalog is billed at $0.44 per DPU-hour, per second, with a 1-minute minimum (pricing page).
• AWS's DMS data lake blog uses Glue jobs to apply database changes to Iceberg tables, one way to do the step after DMS.

Where it falls short

• Glue's docs describe job bookmarks (a record of what a job already processed) and JDBC reads (queries over a standard database connection) for incremental loads, and we found no native log-based CDC for self-managed databases in them.
• A Glue ETL job needs at least 2 DPUs and gets 10 by default (Glue FAQ), and the Spark code is on you.
• The pricing page shows no free tier for ETL jobs. Its free items are the Data Catalog's first million objects and requests.
• Crawlers are billed at $0.44 per DPU-hour (pricing page) with a 10-minute minimum per run (Glue FAQ).
• Memory-optimized job runs cost more, at $0.52 per DPU-hour, or $0.364 on Glue 6.0 and above (US East, Ohio, price list file).
• Temporary files, data quality results and shuffle files stored in S3 are billed at standard S3 rates (pricing page).

2. AWS DMS: best for moving a live database into AWS​

AWS DMS home page, October 2026.

At a glance

• Kind: managed replication service
• Billing: hourly for replication instances or Serverless capacity
• Rate: $0.0745 an hour for a dms.t3.medium instance (US East, N. Virginia, single-AZ, on-demand, AWS price list file published 11 September 2026)

DMS copies a whole database, then keeps it current. AWS's CDC docs describe reading changes from the transaction logs of sources such as Oracle, SQL Server, MySQL and PostgreSQL.

What's good

• One task can load existing data and then keep applying changes, or apply changes only, per the CDC docs.
• The same docs say DMS reads Oracle redo logs with the LogMiner API or a binary reader, SQL Server through MS-Replication or MS-CDC, and MySQL from row-based binary logs.
• The pricing page lists three options: on-demand, serverless and Database Savings Plans. On-demand, you pay for replication instances and any additional log storage.
• Serverless capacity is billed by the hour: 1 DCU is $0.0819 an hour and 16 DCU is $1.311 an hour in US East (N. Virginia), per the price list file.
• All data transfer into DMS is free, and so is transfer to RDS and EC2 databases in the same Availability Zone (pricing page).
• The S3 docs say CSV is the default output with Parquet as an option, and the first field of each CDC record marks an insert (I), update (U) or delete (D).

Where it falls short

• AWS's DMS target list has no Apache Iceberg entry.
• AWS's data lake blog lands changes in S3, then uses Glue jobs. In that design a file for a table with no primary key is not processed, and an SQS FIFO queue keeps the change files in order.
• The CDC docs say "There are no SLAs for CDC latency." Latency can increase to several minutes or longer depending on source workload, network and other factors.
• S3 targets record "no ALTER statement" when a source column changes, and DMS does not alter earlier records to match (S3 docs).
• The same S3 docs say BatchApply is not supported for an S3 endpoint and might lose data, and that full LOB mode is not supported.
• The CDC start point is fixed when the task is created, so a different start point needs a new task. PostgreSQL sources do not support a custom CDC start time (CDC docs).

What users say: In the Hacker News thread "We migrated our PostgreSQL database with 11 seconds downtime" (January 2024), one commenter wrote that "schema changes totally messed it up".

AWS DMS documentation, target endpoints, October 2026.

3. AWS Glue zero-ETL: best for SaaS and DynamoDB data with no pipeline code​

AWS Glue home page, October 2026.

At a glance

• Kind: managed integrations inside Glue
• Sources listed: DynamoDB, Oracle Database@AWS and SaaS apps such as Salesforce, SAP and Zendesk
• Billing: $1.50 per GB of data ingested from applications (US East, Ohio, AWS price list file published 6 October 2026), plus target compute

Targets include Amazon S3 and S3 Tables, plus Redshift. Glue's docs are clear about the limit for databases.

What's good

• AWS calls these fully managed integrations that minimize the need to build ETL pipelines.
• The Glue docs list application sources including Facebook Ads, Instagram Ads, Salesforce, SAP OData, ServiceNow, Zendesk and Zoho CRM, plus DynamoDB and Oracle Database@AWS.
• Listed targets are a general purpose S3 bucket, S3 Tables, Redshift Managed Storage and a Redshift data warehouse (same docs).
• AWS says it does not charge an additional fee for the zero-ETL integration. You pay for the source and target resources (pricing page).
• For application sources the same price file lists $0.44 per DPU-hour for the compute that processes zero-ETL data written to S3.

Where it falls short

• AWS's docs say: "For self-managed database sources, you can replicate data only to an Amazon Redshift data warehouse. Other targets are not supported." The self-managed sources listed are Oracle, SQL Server, MySQL and PostgreSQL.
• Ingestion from applications is billed at $1.50 per GB (US East, Ohio, price list file), and each ingestion request has a minimum volume of 1 MB (pricing page).
• For S3 targets you also pay Glue compute per DPU-hour, billed per second with a 1-minute minimum (same page).
• For DynamoDB sources, DynamoDB charges a separate fee to export data from continuous backups (same page).

4. Amazon AppFlow: best for small SaaS pulls​

Amazon AppFlow home page, October 2026.

At a glance

• Kind: managed SaaS-to-AWS flow service
• Billing: $0.001 per successful flow run, per AWS's pricing page
• Data: $0.02 per GB processed, the rate AWS uses in its pricing examples for destinations on AWS

AWS says AppFlow transfers data between SaaS apps, such as Salesforce, and AWS services, such as S3 and Redshift. Its pricing page says a flow run that checks for new data counts as a run even when nothing new is found.

What's good

• Two numbers set the price, and a small flow costs cents (see our arithmetic below).
• Pricing is pay as you go with no upfront fees, per the pricing page.
• Flows can run on demand or on a schedule, and one docs example triggers a flow on each new record created in Salesforce (AppFlow docs).
• A docs example moves Salesforce, Marketo, ServiceNow and Zendesk data to S3 weekly, in aggregate up to 100GB per flow (same docs).
• Custom Connector SDKs for Python and Java let you build connectors for sources the service does not already integrate (same docs).
• AppFlow supports ingestion of Salesforce Platform events and Change Data Capture events. The docs name no database change capture (same docs).

Where it falls short

• AWS's overview names SaaS apps as sources, not databases, and we found no database log reading on it.
• Destinations that are not on AWS are priced differently, so check the pricing page before you plan one.
• The overview names S3 and Redshift as destinations and does not mention Iceberg.
• Beyond runs and data processed, you are charged standard request and storage rates to read and write AWS services such as S3 (pricing page).
• Some connectors, SAP for example, allow extra concurrent processes per flow run, and each extra process is charged as an additional flow (same page).
• The pricing page states no free tier amount.

5. Amazon Data Firehose: best for streams into S3, Redshift or Iceberg​

Amazon Data Firehose home page, October 2026.

At a glance

• Kind: managed delivery service for streaming data
• Iceberg: can route records from one stream into different Iceberg tables and apply inserts, updates and deletes (AWS docs)
• Billing: for an Iceberg destination, per GB ingested, per AWS's Firehose pricing page, which has no database-source rate

Think of Firehose as a delivery truck for streaming records. AWS's pricing page lists Amazon MSK (managed Kafka) and Kinesis Data Streams among its sources, and its Iceberg docs say the tables can sit in S3 or S3 Tables.

What's good

• It is an AWS path from an event stream to Iceberg tables, and one stream can feed several tables.
• For Iceberg destinations the pricing page lists $0.045 per GB delivered from a Kinesis Data Streams source, billed per GB ingested with no 5KB increments.
• Firehose supports fine-grained access control on Iceberg tables in S3 with AWS Lake Formation (destination docs).
• The considerations page says the Glue Data Catalog supports automatic compaction of Iceberg tables, and that you can compact by hand with Athena OPTIMIZE and expire snapshots with VACUUM.
• Setting the AppendOnly flag to true, for inserts only, lets Firehose scale automatically to match your throughput, and it can be set only through the CreateDeliveryStream API (same page).

Where it falls short

• The database-as-source feature was only a preview, and AWS's announcement post now says the preview period "has ended on 09/30/2025".
• For self-managed Iceberg tables, you handle compaction (merging small files) and snapshot expiration (removing old table versions) yourself. AWS adds that the Glue Data Catalog can compact Iceberg tables automatically, billed separately (Firehose docs).
• An update writes a delete file (a marker for removed rows) plus an insert, and delete files incur S3 put charges, per AWS.
• Column names and data types in the source data must exactly match those of the target tables for Firehose to deliver successfully (same page).
• As ingest throughput rises, the number of partitions that can be written actively falls: about 3,000 at 20 MB/s or less, 100 at 40 to 400 MB/s, and 1 at 750 MB/s to 1.5 GB/s (same page).
• Amazon MSK Serverless is not supported as a source for Iceberg tables, and AWS does not recommend several streams writing to the same Iceberg table (same page).

AWS News Blog, Amazon Data Firehose database replication post, October 2026.

Tools from outside AWS​

6. OLake Go: best for database changes into Iceberg on storage you own​

OLake home page, October 2026.

At a glance

• Kind: open-source database replication, licensed Apache 2.0
• Change capture: Postgres, MySQL/MariaDB, MongoDB and SQL Server, per the connector docs (we did not test them)
• Output: Apache Iceberg and Parquet
• Price: free licence, you pay for your own servers
• Support: contact the OLake team

OLake Go moves databases, not SaaS apps, and it does not transform data on the way. You run it yourself with Docker, Helm on Kubernetes or the OLake UI.

What's good

• One tool does the first load and then the change capture for four database families, with Full Refresh, Full Refresh + Incremental, Full Refresh + CDC and CDC Only sync modes (docs).
• Oracle, Db2, S3 and Kafka also work as sources, without database change capture.
• It writes Iceberg tables to catalogs such as AWS Glue, with eleven catalog types listed on the catalog compatibility page, or Parquet files on object storage such as S3, MinIO and Google Cloud Storage.
• Syncs are stateful and resumable: after a crash, a network failure or a pause they resume from the last checkpoint instead of starting over (docs).
• Parallel chunking splits large tables into chunks that are read in parallel, in the Full Refresh, Full Refresh + CDC and Full Refresh + Incremental modes (docs).
• Schema discovery runs at the start of every sync, and a new source column is added to the Iceberg schema automatically (schema evolution docs).

Bottom line: Pick OLake Go when your sources are Postgres, MySQL/MariaDB, MongoDB or SQL Server and you want Iceberg or Parquet on storage you run.

7. Fivetran: best for many connectors with no servers​

Fivetran home page, October 2026.

At a glance

• Kind: managed ELT service
• Free plan: up to 500,000 monthly active rows (MAR)
• Billing: MAR, counted per connection; list rates are in its Service Consumption Table (V.10, effective 1 February 2026: Standard starts at $495 per million MAR plus a $5 base per connection)

Fivetran's docs list Amazon Redshift among its destinations. It can also write Parquet files to an S3 bucket through its Managed Data Lake Service, with AWS Glue as an optional catalog for Iceberg tables.

What's good

• Fivetran describes itself as fully managed, so you run no servers (we did not test that), and its pricing page lists a free plan.
• Its pricing page lists Standard with unlimited users, 15-minute syncs, 700+ fully managed connectors and a dbt Core integration. Enterprise adds 1-minute syncs, custom roles and a Hybrid deployment option.
• The same page says you can save up to 22% on an annual contract.
• Its Managed Data Lake Service docs say it writes Parquet files to cloud object storage (Amazon S3, Azure Data Lake Storage or Google Cloud Storage) and always creates and maintains Iceberg table metadata.

Where it falls short

• Its troubleshooting docs say AWS Glue compaction is not supported on Fivetran-managed Iceberg tables, and the next sync restores the managed state.
• A row counts as active when it changes (MAR definition), and the pricing page says updates include deletes, so busy tables push the bill up.
• The pricing page prints no per-row rate; the service consumption table lists Standard from $495 per million MAR, Enterprise from $661.67 and Business Critical from $1,061.67 (list price per connection, before discounts).
• The pricing page lists 15-minute syncs for Standard and 1-minute syncs for Enterprise. It also applies a $5 base charge to standard connections with usage between 1 MAR and 1M MAR.
• The Managed Data Lake Service docs say Fivetran does not support position deletes for Iceberg tables, nor the S3 Glacier Flexible Retrieval, Glacier Deep Archive or Intelligent-Tiering archive tiers.
• The destinations page says it is not always possible to load large datasets into row stores like PostgreSQL and MySQL, and that your provider's compute charges depend on data volume and sync frequency.

What users say: A Hacker News commenter on the thread about Fivetran and dbt Labs merging (October 2025) wrote that "Fivetran is convenient but absurdly expensive."

8. Airbyte: best for connector choice and self-hosting​

Airbyte home page, October 2026.

At a glance

• Kind: ELT with a self-hosted Core edition and a paid cloud
• Core: free to self-host under the Elastic License 2.0 (licence FAQ)
• Cloud: Standard "Starting at $20 /month" with 5 credits included and extra credits at $5 each, per Airbyte's pricing page (read 8 October 2026)

Airbyte's docs list Redshift, S3, S3 Data Lake and others as destinations. The S3 Data Lake connector writes Iceberg to S3 and supports AWS Glue, Nessie, Polaris and REST (representational state transfer, a standard web interface) catalogs.

What's good

• Airbyte's licence FAQ says no limits exist on volume or users for open-source use. Your costs are servers and the people who run them.
• The comparison matrix on its pricing page lists 700+ connectors on all four plans.
• Its CDC docs list Postgres, MySQL, SQL Server, MongoDB, Oracle, SAP HANA and Db2 as current CDC sources, read on a sync interval.
• The S3 Data Lake docs list Full Refresh Overwrite, Append and Overwrite + Deduped, plus Incremental Append and Append + Deduped. Dedup is merge-on-read, using the stream's primary keys as Iceberg identifier columns.
• The pricing page shows a 14-day free trial with 400 credits, and Plus starting at $189 a month for a 40-credit package.
• Its Max Sync Frequency row reads 1 hr for Standard, 15 min for Plus, and 5 min for Pro and Enterprise Flex (same page).

Where it falls short

• Database change capture runs as scheduled syncs, not as a continuous stream, per its CDC docs. The first CDC sync takes a snapshot with a SELECT statement, which is effectively a Full Refresh.
• The same docs say changes made by TRUNCATE or ALTER do not appear in the logs, so they do not reach the destination, and a refresh is required after you add a new table to a CDC connection.
• The S3 Data Lake docs say the connector never rewrites existing Iceberg data files and warn against running compaction during a truncate refresh (a full reload that replaces the table's data).
• In the S3 Data Lake connector, objects and unions are written as string columns of serialized JSON. On Airbyte Cloud with the Glue catalog, an Airbyte team member must enable IAM role authentication.
• Marketplace connectors are community-maintained with no SLA, per Airbyte's support levels. Enterprise connectors are not available to Open Source or standard Cloud customers.
• Pro and Enterprise Flex use capacity-based pricing with "Talk to sales" on the pricing page, so no price is published for them.

What users say: A reviewer on AWS Marketplace (August 2026) notes "occasional syncing issues or rate-limit errors with third-party APIs".

9. Hevo: best for small teams loading Redshift​

Hevo Data home page, October 2026.

At a glance

• Kind: managed ELT service
• Free plan: $0, up to 1 million events a month
• Paid: Starter from $299 a month ($265 on annual billing), Professional from $849 a month, per Hevo's pricing page (read 8 October 2026)

Hevo's docs list Amazon Redshift and Redshift Serverless as destinations. Its billing word is "event", which means every record inserted, updated or deleted in the destination.

What's good

• The plans are tiered and posted, and there is a 14-day free trial with no credit card (pricing page).
• Hevo's docs describe log-based pipelines for MySQL (BinLog), PostgreSQL (logical replication), SQL Server (Change Tracking), MongoDB (Change Streams or OpLog), Oracle (Redo Logs) and DynamoDB (Streams).
• The pricing page says the Free plan allows up to 5 users and 1-hour scheduling, with limited connectors.
• Starter adds up to 10 users, 150+ connectors, a dbt integration, SSH/SSL and 24*7 email and live chat support (same page).

Where it falls short

• Streaming pipelines show on the Professional and Business Critical columns of the pricing page, and the docs say Hevo Sales must enable streaming, which from Release 2.21 covers those sources except SQL Server (all variants) and DynamoDB. Business Critical is "Custom."
• Its only Iceberg route in the docs we read is an Early Access Edge destination into Snowflake-managed Iceberg tables, not Iceberg on S3 with an open catalog.
• That route needs an active Snowflake account, a Snowflake warehouse and database, and an S3 bucket with an IAM policy that grants Snowflake access. Engines such as Spark and Trino read the tables through the Horizon Iceberg REST Catalog API (same docs).
• The same docs warn that a Snowflake Iceberg destination configured with access credentials may stop connecting at any time, because Snowflake is deprecating password-based authentication. Hevo recommends key pair authentication.
• By Hevo's definition, every insert, update or delete is an event, so a row updated five times is five events and busy tables use up quota fast.
• Events above your plan's quota are on-demand and charged on top of the plan, and the page shows no rate for them (same page).

What users say: A reviewer on AWS Marketplace (August 2026) says "Hevo is designed for fast individual pipelines, but struggles with many concurrent pipelines."

10. Matillion: best for visual pipelines inside Redshift​

Matillion home page, October 2026.

At a glance

• Kind: cloud ETL platform
• Billing: credits, driven by task hours (credit consumption terms)
• Price: not published on Matillion's pricing page (read 8 October 2026)

Matillion's streaming docs say streaming pipelines can write to Amazon S3, and a pre-built pipeline loads that change data into Redshift. The streaming runner is deployed in your own cloud.

What's good

• Analysts can design pipelines visually. The Developer card on the pricing page lists a low-code canvas with SQL and Python, pre-built connectors and a built-in Git repository.
• The credit rates are public in Matillion's credit consumption terms: orchestration is 1 credit per task hour and transformation is 3. Streaming CDC pipelines are 1 credit per task hour for the essential type and 2 for the premium type.
• Task hours count only while a pipeline runs, in 2-second increments. Validation and sampling do not count (same terms).
• Matillion's streaming docs list Db2 for IBM i, SQL Server, MySQL, Oracle and PostgreSQL as CDC sources, and describe "near-real-time data ingestion" into cloud storage or a warehouse.
• The Teams card lists 5 developer users, an audit log and a Service Level Agreement. Scale adds custom SSO, hybrid cloud deployment and data lineage tracking (pricing page).
• Per the pricing FAQ, you can contract directly with Matillion or pay through your AWS, Azure or Snowflake account.

Where it falls short

• No plan shows a dollar price, and the price per credit is not published.
• Streaming change data capture is listed on the Scale card of the pricing page, and the streaming docs say the feature is "only available to customers on specific Maia plans."
• Streaming pipelines "only currently support relational databases as sources" per the streaming docs. The streaming runner is deployed and configured in your own cloud infrastructure, with one runner per pipeline.
• Developer users beyond the included ones cost 70 credits per user a month (credit terms).
• The credit terms say the overage rate "will be listed on the Order Form", and under Pay-Go (capped at 60 days after the term) you lose access to all Products unless you sign a new term. Pay-Go brings no support services.
• The terms do not define the "essential" and "premium" CDC pipeline types.

What users say: A reviewer on AWS Marketplace (June 2026) wrote "My main concern is around pricing. I'd really like more transparency and predictability on cost," in a review about whether the Maia AI assistant stays bundled.

11. Informatica: best for large, governed estates​

At a glance

• Kind: enterprise data management suite (the cloud product is called IDMC)
• Price: an AWS Marketplace listing shows $131,760 for 12 months for a bundle of 120 IPUs (Informatica Processing Units) a month (read 8 October 2026)
• Iceberg: its connector docs describe an Amazon SageMaker Lakehouse connector that can read from or write to Apache Iceberg tables

The listing is a list price for one bundle, not a rate card.

What's good

• Its AWS Marketplace listing describes IPUs as one shared currency across data integration, ingestion and master data management services, and offers 12-month, 24-month and 36-month contract tabs.
• Its connector docs describe an Open Table Connector that reads or writes Apache Iceberg or Delta Lake tables.
• The same docs say the Amazon SageMaker Lakehouse connector works with Iceberg data in S3 managed by the AWS Glue Data Catalog or the S3 tables catalog.
• The Oracle CDC V2 Connector retrieves Oracle change records from a PowerExchange change data capture environment (same docs).
• The pricing page lists "Free Cloud Data Integration" and a "Data Warehouse Trial" under Get Started.

Where it falls short

• Its pricing page shows no dollar price per IPU and no calculator, and ends with a "get quote" button.
• The page says IPU consumption is calculated per scaler, based on the scaler's usage including Secure Agent, CDI-e and Data Mass Ingestion volume, so several usage measures feed the bill.
• Overage fee rates are not published on the page either.

What each option bills for​

The billing unit is usually the answer to a surprising invoice, and it matters more than any feature. Glue and DMS charge for capacity or compute time, so an idle DMS instance still costs money. AppFlow charges per run and per gigabyte, and Fivetran charges per changed row.

Here are four small examples with invented workloads. The first row comes from AWS's Glue page, and the rest are our arithmetic on the vendor rates above, so treat them as illustrations, not quotes.

Sources: AWS Glue pricing for the $0.66 example, AWS Glue US East (Ohio) price list, AWS DMS price list, Amazon AppFlow pricing. Checked October 2026.

Glue rates are US East (Ohio) and the DMS rate is US East (N. Virginia). The AppFlow row uses the rates in AWS's worked pricing example (Europe, Frankfurt, S3 to Snowflake hosted on AWS). Other regions can differ, and storage, data transfer and target costs come on top.

Pick the right AWS ETL tool​

If your situation is...	Start with	Iceberg tables on S3, per the sources above
A few SaaS apps into S3 or Redshift	AppFlow	Not named on AppFlow's overview
SaaS apps or DynamoDB with no pipeline to build	Glue zero-ETL	S3 Tables is a listed target, not for self-managed databases
A live database moving into AWS	DMS	No Iceberg target, so a second step is needed
Database changes into Iceberg tables on S3	DMS plus Glue, or a tool that writes Iceberg itself	AWS's blog uses Glue jobs after DMS
Spark code and big batch transforms	Glue	AWS's DMS data lake blog uses Glue jobs to write Iceberg
Events already in Kafka or Kinesis	Firehose	Delivers streams into Iceberg tables
Many SaaS connectors, no servers	Fivetran or Airbyte Cloud	Both document an Iceberg route, with the limits above
A tool you host yourself	Airbyte Core	The S3 Data Lake connector writes Iceberg
Postgres, MySQL, MongoDB or SQL Server changes into Iceberg you run	OLake Go	Writes Iceberg and Parquet itself, per its docs
Redshift loads, a small team, posted prices	Hevo	Only Snowflake-managed Iceberg, in Early Access
Visual pipelines run inside Redshift	Matillion	Not covered here
A big governed estate	Informatica	A SageMaker Lakehouse connector reads and writes Iceberg

Want a quicker answer? Try this short quiz.

Tools that often appear on these lists but are not here​

AWS Data Pipeline is not a current option. AWS's docs say it is "no longer available to new customers" and is in maintenance mode with no new features planned. Existing customers can keep using it, so do not start a new project on it.

A note on Iceberg and open table formats​

Many teams now want Apache Iceberg tables on S3, so several engines can read the same data. AWS's DMS target list does not name Iceberg, AppFlow's overview does not mention it, and Firehose takes streams rather than databases as its source now. Glue, Airbyte, Informatica and Fivetran each document a route, and the limits we found are in their entries above.

If that is your goal, OLake Go (entry 6) writes Iceberg or Parquet on storage you own, and the OLake Go docs cover the rest.

Test two finalists before you commit​

Run one real table through two finalists and write down what you see. This checklist is our suggestion, not a vendor procedure, and one table does not prove production reliability.

• Initial load: do the row counts in the destination match the source?
• Update: does a changed row show up as a change or as a second copy?
• Delete: what happens to a row you delete at the source?
• Column change: add or rename a column and note what lands, or what fails.
• Restart: stop the job mid-run, restart it, and check for gaps or duplicates.
• Bill: compare the month's usage with the vendor's billing unit, then confirm the rates on its page.

FAQs​

Every fact about a tool comes from its own documentation or pricing page, read on 1 October 2026. Prices were re-read on 7 October 2026. When a page says nothing, we write "not stated" instead of guessing.

We did not run the other tools, so any "easy", "fast" or "reliable" claim below about them is the vendor's, not ours. There are no user quotes either, because the public threads we found were about Postgres, SaaS sources or came from vendors, and we would rather print none.

What "MySQL to Iceberg" involves​

Picture it: your MySQL database is busy all day, and you want its changes sitting in cheap storage where query tools can read them as tables. That's the whole job. Two parts matter, how you read MySQL and how you write Iceberg.

Reading MySQL. MySQL writes down every change in its binary log, like a diary that never skips an entry. Debezium's MySQL docs call it a record of all operations in commit order, including schema changes. A CDC tool reads each entry and turns it into an insert, update or delete event.

Three settings decide what your tool can actually see.

First, binlog_format must be ROW, so the log holds the changed rows and not just the SQL text. Second, binlog_row_image set to FULL makes MySQL write every column of the row. Supermetal's docs say it's needed "to capture complete before and after row images".

Third, binlog_row_metadata set to FULL adds column details to each event. Only some tools ask for this one, which is where the confusion starts.

The tool joins as a replica. Fivetran's docs say "we connect to your database as a replica", and Flink CDC's docs say its reader joins the cluster as another server. That means most binlog readers here need their own unique server id and a user with replication privileges, as their docs describe. Fivetran calls it a replica ID, and Estuary has an advanced Node ID setting that it picks for you if you leave it unset.

GTID is optional in most docs. A global transaction identifier (GTID) is just a label MySQL sticks on each transaction. Debezium says you don't need it, Supermetal recommends it for failover, and Flink CDC needs it for high availability.

Snapshot, then changes. First the tool copies the rows that already exist. That's the initial snapshot. Then it reads the binlog from where the snapshot began, and Debezium's docs explain why that matters: MySQL purges binlogs after a set time.

Retention is the clock. MySQL throws old logs away, and it won't wait for your tool. Debezium's docs say that if the saved position is gone, the connector fails and asks for a new snapshot, unless you set snapshot.mode to when_needed.

Advice on how long to keep logs runs from 3 days at Supermetal to 10 days at Airbyte.

Writing Iceberg. Apache Iceberg is a table format: Parquet data files plus metadata that lets engines such as Spark, Trino and Athena treat them as one table. A catalog keeps track of where each table's metadata lives, and many offer a REST (web API) interface. Every commit makes a new snapshot, which is just a saved version of the table.

Updates and deletes get into Iceberg one of two ways. Either you rewrite data files, or you write delete files that mark old rows as removed.

A tool that applies each change this way is said to upsert, meaning update or insert. Equality deletes match rows by key value, and positional deletes point at a file path and row position. Here's the catch: the kind you pick decides which query engines can read the result.

Frequent commits leave lots of small files. Compaction rewrites them into fewer big ones, and old snapshots need expiring too.

How we picked​

We kept the rules simple. A tool made the list if its own docs show a MySQL source and an Apache Iceberg destination, or a documented route to one. Then we compared how each reads MySQL, how it writes updates, deletes and schema changes, who compacts, what the price is based on, and what the docs say it cannot do.

One name you might expect is missing, Amazon Data Firehose. AWS's launch post for its database-to-Iceberg feature now says the preview ended on 30 September 2025 and the capability cannot be tried.

Each tool's documented strengths and scope sit side by side in the tables below.

MySQL to Iceberg Tools at a Glance​

Reading MySQL

Tool	Binlog settings the docs list	Retention advice in docs
Debezium Server with community Iceberg sink	ROW, row image FULL; row metadata not listed	Example of 10 days
OLake Go (MySQL 5.7 or newer)	ROW, row image FULL, row metadata FULL listed	7 days in the generic guide
Kafka Connect: Debezium source plus Iceberg sink	Same as Debezium	Same as Debezium
Flink CDC	Row image and metadata not stated on pages we read	Not stated
Airbyte	ROW, row image FULL; row metadata not listed	10 days recommended
Fivetran (binary log method)	ROW; row image and metadata not listed	1 day minimum, 7 recommended
Estuary	ROW; row metadata listed only in the Aurora steps	At least 7 days
Supermetal (MySQL 5.7 or newer)	ROW, row image FULL, row metadata FULL	3 days recommended

Table behaviour and price

Tool	Updates and deletes	Schema changes	Compaction and cleanup	Pricing basis (read Oct 2026)
Debezium Server sink	Append by default; upsert is a setting	New columns added by default	Not on the Debezium page; the sink's own FAQ says to run periodic maintenance	Free (Apache 2.0), you pay for servers
OLake Go	Upsert with equality deletes, positional deletes or deletion vectors (v0.11.0 and later); or append	Adds, drops and renames detected; type widening	OLake Fusion (Lite, Medium, Full)	Free (Apache 2.0), you pay for servers
Kafka Connect	CDC feature, fed by an experimental Debezium transform	Off by default	Not covered	No licence fee, you pay for Kafka and servers
Flink CDC	Primary key required; at-least-once	MySQL source sends schema changes by default	Not described	Free, you pay for the Flink cluster
Airbyte	Dedup mode: equality delete plus insert; or append	Add, drop, widen a column; never rewrites old files	Not described	Core free; Cloud on credits
Fivetran	No position deletes; method not stated	Not stated	Daily snapshot cleanup; compaction not listed	Monthly active rows for connectors; no lake-specific rate found
Estuary	Spark jobs merge updates; delete file type not stated	Not stated	Optional Glue optimizers, off by default	$0.50 per GB moved plus connector instances, read 7 Oct 2026
Supermetal	Merge-on-read (equality by default, or positional) or append	No data type promotion; partition changes need a new table	You run it, with Spark or Trino	Compute based; Enterprise Self-Hosted "from $10K/ year", per its pricing page, read 7 Oct 2026

Prices change often, so double-check the vendor's page before you budget. Estuary's and Supermetal's figures are quoted as the vendors print them.

The 8 tools, one at a time​

1. Debezium Server with the community Iceberg sink: best for Kafka-free Debezium​

Debezium home page, October 2026.

At a glance: Apache 2.0 · self-hosted · Java 21 · free licence

Debezium is an open-source change reader. Debezium Server's docs describe an Iceberg sink that consumes events from a source Debezium connector and calls it "a community-maintained, open-source project" kept in a separate repository.

Debezium's MySQL connector documentation, October 2026.

What's good

• Its docs describe running Debezium's own MySQL reader without Kafka, which is the main reason to pick it.
• The MySQL docs spell out the user privileges and cover Amazon RDS and Aurora, where the snapshot needs LOCK TABLES.

Where it falls short

• It's community maintained, not part of Debezium's core, and the Iceberg sink's docs page doesn't list supported catalogs. Its own FAQ says upsert tables need periodic jobs to compact data and rewrite delete files.
• Upsert is off by default, so a fresh setup just appends every event (the sink's configuration page lists the settings). Even once upsert is on, deleted rows are kept and marked unless you change a second setting.
• On RDS the binlog stays off unless automated backups are on, and binlog_row_value_options must not be PARTIAL_JSON. Both come from the MySQL docs.

2. OLake Go: best for a self-hosted MySQL to Iceberg job run from a UI​

OLake home page, October 2026.

At a glance: Apache 2.0 · self-hosted · UI or CLI · Iceberg or Parquet only

OLake Go is open source under Apache 2.0 and copies databases into Iceberg tables on storage you control. It reads the binlog on MySQL 5.7 or newer and supports the MariaDB flavour as a CDC source (see the MySQL connector page).

It has four sync modes:

• Full Refresh (full_refresh) copies every row.
• Full Refresh + Incremental (incremental) copies rows past a cursor column, such as an updated-at timestamp.
• Full Refresh + CDC (cdc) takes a snapshot, then reads the binlog.
• CDC Only (strict_cdc) reads the binlog with no initial snapshot.

What's good

• Catalogs include Glue, JDBC, Hive and REST catalogs such as Lakekeeper and S3 Tables, on S3, MinIO, GCS or Azure Data Lake Storage Gen2.
• You choose between equality deletes, positional deletes and deletion vectors, which lets you match your query engine, subject to the reader limits below.
• Full loads use parallel chunking and automatic resume for failed runs, with setup guides for Aurora, RDS, Azure and Cloud SQL.
• Compaction is covered too, as OLake Fusion, with Lite, Medium and Full types.

Good to know

• You run it on your own infrastructure, through the UI or the command line (see the UI install guide).
• Deletion vectors are an Iceberg v3 feature that the v0.11.0 release notes add as a delete mode. Pick the delete mode that matches your query engine, and use the engine compatibility page to see which engines read each one.
• The catalogs compatibility page lists Nessie and Polaris as REST catalogs with setup links.
• The prerequisites list binlog_row_metadata=FULL, and the v0.10.0 release notes say MySQL CDC also works without it.
• MySQL BINARY columns written to Iceberg are tracked in an open issue in the OLake repository, reported on v0.8.2.

Bottom line: Pick OLake Go if you want a UI, a documented catalog list and no licence fee. Fivetran, Airbyte Cloud and Estuary suit teams that want a vendor to run the pipeline, and Kafka Connect suits several systems reading one change stream.

The OLake Go MySQL connector page, October 2026.

3. Kafka Connect with a Debezium source and the Iceberg sink: best for teams already on Kafka​

Kafka Connect home page, October 2026.

At a glance: you run Kafka and Kafka Connect · Iceberg sink from the Iceberg project · no licence fee

The Iceberg docs describe a Kafka Connect sink that writes Kafka data into Iceberg tables, and name Debezium source connectors as the way to bring database changes into Kafka. Debezium reads MySQL into Kafka topics, and the sink moves them on from there. Exactly-once delivery is a listed feature, and it relies on Kafka 2.5 or later.

What's good

• Many consumers can read the same Kafka topics, so the lake is just one of several readers.
• Catalog examples include REST, Glue, Nessie and Hive, and one sink can write several tables.

Where it falls short

• Heads up: the Debezium transform that prepares change events is marked experimental in the Iceberg docs.
• Table creation and schema evolution are off by default, and the page doesn't cover compaction.
• You end up running three systems, not one.

4. Flink CDC: best for teams that already run Flink​

Apache Flink CDC home page, October 2026.

At a glance: Apache 2.0 · runs on Apache Flink · Java 11 or newer · pipeline YAML

Flink CDC has a MySQL pipeline source and an Iceberg pipeline sink, so both halves live in one project. The MySQL source docs describe a snapshot followed by the changes. The Iceberg sink docs list automatic table creation, schema synchronisation, and batch or streaming writes.

What's good

• One tool covers both the snapshot and the change stream, and the snapshot is split into chunks of 8,096 rows by default.
• Per the docs, unlike the Postgres source, the MySQL source sends schema change events by default, so the sink can follow table changes.

Where it falls short

• The MySQL JDBC driver isn't bundled, because its GPLv2 licence doesn't fit the project. You download mysql-connector-java 8.0.27 yourself and pass it with --jar.
• The source table must have a primary key, and the Iceberg sink doesn't offer exactly-once semantics. It's at-least-once, so the docs lean on the primary key to make a repeated write give the same result.
• Catalog types are Hadoop, Hive, Glue or a custom class. REST isn't stated, and each parallel reader needs its own server id.

5. Airbyte: best for teams that want one tool for databases and SaaS apps​

Airbyte home page, October 2026.

At a glance: Core self-managed (Elastic License 2.0) · Cloud · Enterprise Flex hybrid · S3 Data Lake destination

Airbyte's MySQL source reads the binlog and recommends CDC over its cursor-based method. Its S3 Data Lake destination calls itself "official support for the Iceberg protocol on S3" and supports REST, Glue, Nessie and Polaris catalogs. The two live on separate docs pages.

What's good

• Airbyte's connectors page, read 7 October 2026, counts its connectors in the hundreds, so MySQL is one of many sources you can wire up.
• The MySQL page lists the exact settings and suggests 10 days of retention.
• Deduplication is documented as merge-on-read, meaning updates are written as delete files and applied when you query. Each update is an equality delete plus an insert. Core is free to self-host, and Cloud is credit based.

Where it falls short

• On Amazon RDS, the binlog retention parameter defaults to 0 hours. The docs say that means logs are removed at once, so you must raise it.
• The destination never rewrites existing Iceberg data files, so only some schema changes work, and objects are written as JSON strings. The page doesn't describe compaction.
• Core uses the Elastic License 2.0, which is NOT an open-source licence. Syncs run on a schedule, not as a continuous stream.

6. Fivetran Managed Data Lake Service: best for hands-off, vendor-run pipelines​

At a glance: SaaS · writes Parquet to your S3, Azure or GCS bucket · Iceberg metadata always created · monthly active rows pricing

Fivetran's MySQL setup guide offers the binary log or Teleport Sync, and wants binlog_format=ROW. Its Managed Data Lake Service docs say your data stays in your cloud storage while Fivetran keeps the Iceberg metadata. We found no page that pairs the two, so treat Fivetran as a conditional candidate and ask it to confirm the combination.

What's good

• Fivetran's docs say it runs the pipeline and the table upkeep, including snapshot cleanup every day. We have not tested that.
• Per its docs, your data stays in your own bucket, with a Fivetran Catalog built on Apache Polaris by default, or another supported catalog.

Where it falls short

• The lake docs say there's no support for Iceberg position deletes, and they don't say which delete method is used.
• Teleport Sync, the alternative to the binary log, "disables large, rapidly changing tables if they fail to sync". Compaction isn't in the lake page's list of maintenance operations.
• The destination runs as SaaS only. Fivetran's connector pricing counts monthly active rows, and we found no separate lake rate.

Ask Fivetran before you rely on it: does the MySQL connector write to the Managed Data Lake Service, which delete method it uses, and what the lake destination adds to the monthly active rows bill.

Fivetran's Managed Data Lake Service documentation, October 2026.

7. Estuary: best for AWS teams that want a vendor to run it​

Estuary Flow home page, October 2026.

At a glance: Cloud, private or Bring Your Own Cloud (BYOC) · Business Source License · MySQL capture plus Iceberg materialization

Estuary's MySQL capture docs need binlog_format=ROW and a binlog expiry of at least 7 days. Its Iceberg connector works differently: it "orchestrates Spark jobs running on your configured compute system to merge updates into materialized tables".

What's good

• One product documents both MySQL capture and Iceberg materialization, plus a hosted option, with MySQL setup steps for self-hosted, RDS, Aurora, Cloud SQL and Azure.
• The docs describe catalog setups for Glue, Snowflake Open Catalog and Dremio Cloud.

Where it falls short

• The Iceberg connector needs an AWS EMR Serverless application you configure, an S3 staging bucket and IAM roles. That is three AWS pieces to set up before a first sync.
• Today it supports only REST catalogs on Amazon S3 storage. GCP and Azure are planned.
• Billing has two meters. Estuary's pricing page (read 7 October 2026) lists $0.50 per GB moved, plus connector instances: $100 a month each for the first six, $50 each after that. It also lists a free tier of 10 GB a month with 2 connector instances.

Ask Estuary before you rely on it: how GB moved is counted for a busy MySQL table, since the bill has two meters.

8. Supermetal: best for a single self-hosted agent priced on compute​

Supermetal home page, October 2026.

At a glance: Self-hosted, described by Supermetal as a single binary · Iceberg V3 or V2 · compute-based price · licence not stated

Supermetal's Iceberg target docs say it writes Parquet to Iceberg through REST, Glue or S3 Tables catalogs on S3 or GCS. New tables default to Iceberg V3, and V2 is selectable for engines that lack V3 support. Its MySQL source reads the binlog and takes snapshots in parallel.

What's good

• You get merge-on-read by default (updates are written as delete files and applied at query time), or positional deletes only, per its docs.
• The MySQL source works without GTID, so that's one less thing to turn on.
• Pricing is compute based, and there's a free trial of 1,000 sync hours on that page. Its pricing page, read 7 October 2026, shows Enterprise Self-Hosted "from $10K/ year".

Where it falls short

• Data type promotion isn't supported yet, and changing partitioning needs a new table.
• Compaction is on you, using Spark, Trino or a table service.
• It asks for binlog_row_metadata=FULL, it's paid after the trial and the free pilot on its pricing page, and the pages we read don't state a licence.

Supermetal's MySQL source documentation, October 2026.

Also considered​

Three more names keep coming up in searches. They don't get a full entry.

RisingWave is a streaming engine. Its MySQL CDC docs list MySQL 5.7, 8.0 and 8.4, plus MariaDB and TiDB, and ask for a unique server id. Its Iceberg docs describe automatic maintenance and a manual VACUUM FULL that compacts data files.

Some compaction behaviour needs a licence, per its release notes. It fits if you also want to run SQL on the stream.

AWS Database Migration Service (DMS) reads MySQL's row-based binary logs. Apache Iceberg isn't in its list of target endpoints, though Amazon S3 and Kafka are. So you'd have to build an extra step to reach Iceberg.

Upsolver now sits inside Qlik as Qlik Open Lakehouse, which Qlik says "writes data as fully spec-compliant Apache Iceberg tables". The pages we read don't say which databases it reads by log.

AWS DMS target endpoints documentation, October 2026. Iceberg is not on the list.

Which Route for Which Team​

Short answer: pick by what you already run, then read the "watch for" column before you get excited.

MariaDB notes​

MariaDB has a binlog like MySQL's, but tools treat it differently. Debezium and Estuary each have a separate MariaDB connector, and Flink CDC lists MariaDB 10.x with MySQL versions.

Fivetran's connector list names MariaDB for the binary log method. Airbyte and Supermetal pages we read don't.

How to test before you commit​

This is a test plan, not results. Take each finalist for a spin on one table with real deletes, updates and a large text column.

1. Run DELETE FROM orders WHERE id = 1;, then read the table from your engine. Pass: the row is gone.
2. Update another column on a row with a large text value. Pass: the large value is intact, and SHOW VARIABLES LIKE 'binlog_row_image'; returns FULL.
3. Run ALTER TABLE orders ADD COLUMN note VARCHAR(50);. Pass: the tool carries it over, or fails loudly.
4. In a test system, stop the tool for longer than your binlog retention, then run SHOW BINARY LOGS;. Make a few inserts, updates and deletes while the tool is stopped, then compare the source and Iceberg rows after it comes back. Pass: the tool says plainly that it needs a new snapshot, or the two sides match exactly. A silent gap in the data is a fail, full stop.
5. After a day, query the Iceberg files metadata table, for example SELECT file_path, file_size_in_bytes FROM my_catalog.my_db.orders.files; in Spark. Lots of tiny files mean you need a compaction plan.

FAQs​

Conclusion​

MySQL to Iceberg is really two jobs: reading a binlog safely and writing tables that stay fast. The tools differ most in the settings they demand, how they handle deletes, and who compacts the files, so test those on your own data first.

One last tip: from day one, watch the tool's lag against your remaining retention. If the lag grows toward the retention window, the oldest logs MySQL keeps are closing in on the tool's saved position, so step in before they pass it.

Do you need a streaming platform at all?​

Apache Kafka calls itself an open-source distributed event streaming platform: changes sit in named topics on machines called brokers until something reads them. Debezium's maintainers give three reasons teams keep it, in their May 2026 post. Kafka Connect has a large library of sink connectors, it handles worker failures with built-in high availability, and it spreads work across a cluster.

The same post gives a test: ask "do I need the capabilities that Kafka provides?" If you don't, you're paying to run brokers for a pipeline with one reader. Also ask whether you need to hold changes while the lake is down, or replay them later, and check how each tool's docs handle restarts.

How we picked​

An option made this list if its own documents say it can read database changes and write Apache Iceberg tables, it can run without Kafka today, and its public pages say enough for us to check catalogs, deletes and table upkeep. We added one baseline, Debezium on Kafka Connect, so you can see what you'd be skipping.

We read each vendor's documentation in September and October 2026 and link every claim. We did not run the other tools, so for them this is a reading of documents, not a lab test.

Where a page says nothing, the table says "not stated". We left out speed claims, because no vendor publishes a comparable test. Where an entry has no "What users say" line, the comments we found did not describe running the tool.

Two tools were left out on those rules. We explain why below.

Database to Iceberg without Kafka: options at a glance​

The first row is the baseline with Kafka, and the next seven don't need it. The Catalogs column lists only what each page names. REST means a catalog with a standard web interface.

Option	What sits between database and Iceberg	CDC sources (per docs)	Catalogs named in docs	Table upkeep
Baseline: Debezium on Kafka Connect with the Iceberg sink	Kafka brokers and Kafka Connect	Debezium connectors such as PostgreSQL, MySQL, MongoDB, SQL Server, Oracle; the sink page has transforms for Debezium messages	REST, Glue, DynamoDB, Hadoop, Nessie, JDBC, Hive, BigQuery Metastore	Not stated on the page we read
Debezium Server with the community Iceberg sink	One Debezium Server process	Same Debezium connectors, one connector per Server instance	Not listed; settings pass through to Iceberg	You; the sink FAQ advises periodic maintenance
Flink CDC	A Flink cluster	MySQL, PostgreSQL, Oracle in YAML pipelines; MongoDB and SQL Server through Flink SQL	Hadoop, Hive, Glue, or a custom class	Not stated on the pipeline page
RisingWave	RisingWave itself, a streaming system	PostgreSQL, MySQL, MongoDB, SQL Server (the overview table's MongoDB row reads "CDC via Kafka")	Built-in, Glue, S3 Tables, JDBC, REST, Lakekeeper, Hive, SeaweedFS, Snowflake, Unity; Snowflake is read-only	Automatic maintenance listed, with a dedicated compactor node; a release note ties the default auto compaction strategy to Iceberg compaction being licensed
OLake Go	One OLake Go process, with a Java helper for the Iceberg write	PostgreSQL, MySQL and MariaDB, MongoDB, SQL Server	11 catalog types: Glue, JDBC, Hive Metastore, S3 Tables, and REST catalogs such as Lakekeeper, Unity, Nessie, Polaris, BigLake and Snowflake Horizon	OLake Fusion for compaction and maintenance
Estuary	Estuary's hosted platform, plus a Spark job on EMR Serverless for the REST connector	PostgreSQL, MySQL, MariaDB, SQL Server, Oracle, MongoDB	Glue, S3 Tables, Snowflake Open Catalog, Dremio Cloud; REST on S3 only	Optional Glue optimizers, off by default
Fivetran Managed Data Lake Service	Fivetran's hosted service	Set per connector, such as logical replication for PostgreSQL; the destination page names no connectors	Fivetran Catalog, Glue, BigLake, Unity, OneLake	Snapshot and file cleanup listed; compaction not listed
dlt	Your own Python code	Log-based for PostgreSQL; the SQL database source reads tables directly, and the docs describe no log-based CDC for other databases	Whatever PyIceberg supports, including REST and SQL	Not described

Prices aren't in the table, and that's on purpose. Several of these are free software with a server and staff bill, and the hosted ones price in different units, so one column would mislead you.

Updates, deletes and delivery: what each tool's docs say​

This is where the options differ most. A primary key is the column that identifies each row. An upsert updates the row if its key already exists and inserts it if not, while an append adds every change as a new row, so the table holds both versions of a changed row.

Iceberg can handle a delete in two ways. Copy-on-write rewrites the affected data files, and merge-on-read writes the delete as a small separate file that is applied when someone reads the table.

Equality deletes match rows by key values, and positional deletes point at a file and a row position. Delivery guarantee means whether a change can land twice (at-least-once) or exactly once.

Option	Update to a row	Delete of a row	Delivery guarantee (per docs)
Iceberg Kafka Connect sink	Not described on the page we read	Not described on the page we read	Exactly-once listed; needs Kafka 2.5 or later
Debezium Server sink	Append-only by default; upsert mode is off by default and keeps the record with the highest value in a dedup column	In upsert mode, kept and marked __deleted=true by default	Not stated for the Iceberg sink; the Server page's JDBC sink section warns exactly-once features may differ from Kafka Connect
Flink CDC (Iceberg pipeline connector)	Primary key keeps repeated writes safe	Not described on the pipeline page	At-least-once; the pipeline page says exactly-once is not supported
RisingWave	Append-only or upsert sink	Upsert sink is for updates and deletes; with force_append_only, deletes are ignored	Exactly-once setting, on by default
OLake Go	Upsert by default, append per table	Equality deletes, positional deletes or deletion vectors	Two-phase commit for Iceberg writes, which avoids duplicate writes (v0.5.0 notes)
Estuary	Merge job on Spark	Soft delete by default, hard delete optional	Not stated on the page we read
Fivetran	Not described on the destination page	Not described; position deletes aren't supported	Not stated on the page we read
dlt	Merge supports upsert and insert-only	Not described on the Iceberg page	Not stated on the page we read

"Not described" and "not stated" mean we couldn't find the answer on the pages we read. If your tool lands there, test one update and one delete yourself.

Baseline: Debezium on Kafka Connect with the Iceberg sink​

At a glance: Apache 2.0 software you run, plus a Kafka cluster. It's the route most tutorials teach.

Debezium reads the database log and puts each change into a Kafka topic, and the Apache Iceberg docs describe a Kafka Connect sink that reads those topics and writes Iceberg tables. Debezium's own sink list for Kafka Connect shows only JDBC (Java Database Connectivity) and MongoDB, so the Iceberg sink comes from the Iceberg project, not from Debezium.

What it writes: Iceberg tables through catalogs such as REST, Glue, Hive and Nessie. The docs list exactly-once delivery, which relies on Kafka 2.5 or later. Automatic table creation and schema evolution are listed too, but both default to off.

Apache Iceberg documentation, Kafka Connect sink page, October 2026.

What's good

• Debezium's post above says Kafka Connect's distributed mode spreads work across workers and handles worker failures. We did not test that. If many systems already read the same topics, the Iceberg sink is just one more reader.

Where it falls short

• You run Kafka brokers and Kafka Connect workers, plus the Debezium and Iceberg connectors that run inside them. The sink page's install steps also have you build the connector zip from the Iceberg source code.
• The page we read doesn't explain how updates and deletes are applied, even though it mentions a "CDC feature". The Debezium transform that feeds it is marked experimental.

1. Debezium Server with the community Iceberg sink: the same Debezium connectors with no Kafka​

Debezium home page, October 2026.

At a glance: Apache 2.0, you run it. Debezium Server is, in its docs' words, a ready-to-use application that streams change events "without requiring Apache Kafka."

The Debezium Server docs list an Apache Iceberg sink. Here's the catch: it is "a community-maintained, open-source project" in a separate repository, memiiso/debezium-server-iceberg, not part of Debezium itself.

What it writes: Parquet files by default, with Avro and ORC (two other file formats) selectable. It has upsert and append modes, but upsert is off by default. Even in upsert mode, deleted rows are kept and marked __deleted=true unless you change a setting.

Debezium Server documentation, Apache Iceberg section, October 2026.

What's good

• You keep Debezium's connector list: its index shows MongoDB, MariaDB, MySQL, PostgreSQL, SQL Server, Oracle, Db2 and Cassandra as main connectors.
• The sink's README claims it replicates "from any database to Iceberg tables" without Spark, Kafka or a streaming platform, which we did not test. The latest release is 1.2.0.Final from October 4, 2026.

Where it falls short

• The sink is community maintained, and the docs name no catalog types. Upsert depends on a Debezium transformation called event flattening, so tables with no primary key stay append-only.
• Each Debezium Server instance runs exactly one connector. A July 2026 Debezium post about its JDBC sink says Kafka Connect's multi-task setting is "not yet available in DS."
• The sink's FAQ says to run periodic maintenance on delete files, so that chore is yours. Full schema evolution isn't supported, though adding fields and promoting types is, and a column dropped at the source stays in the table with nulls.

2. Flink CDC: when you already run Apache Flink​

At a glance: Apache 2.0, you run it, and it needs a Flink cluster. Flink CDC calls itself "a distributed data integration tool for real-time data and batch data, built on top of Apache Flink". Its docs also say some sources use Debezium as the engine inside.

Apache Flink CDC documentation, October 2026.

What it writes: The Iceberg pipeline connector creates tables and syncs added columns. The catalog type can be Hadoop, Hive or Glue, or a custom class. It first appears in the Flink CDC 3.4 line.

What's good

• Its docs describe reshaping data in the same job. Iceberg's own Flink docs describe upserts on version 2 tables with a primary key.
• Its docs list Standalone, YARN or Kubernetes deployment, with no Kafka listed as a requirement.

Where it falls short

• The pipeline page says "The source table must have a primary key." It also says exactly-once isn't supported, and offers at-least-once writes made safe by the primary key.
• The Postgres pipeline source doesn't sync table structure changes. MongoDB and SQL Server CDC are Flink SQL sources, not YAML pipeline sources, so you write more code for them.
• Someone has to run Flink, which is cluster work like Kafka.

3. RisingWave: for a SQL-first team that wants processing and Iceberg together​

At a glance: Apache 2.0 core, self-hosted or hosted, with premium features behind a licence. RisingWave describes itself as an "event streaming platform", so you're skipping Kafka, but not streaming.

RisingWave home page, October 2026.

What it writes: The Iceberg docs show append-only and upsert sinks, merge-on-read writes by default, and an is_exactly_once setting that defaults to true. Exactly-once needs sink decoupling, a RisingWave setting that is on by default, and turning it off disables exactly-once. Catalogs include Glue, S3 Tables, JDBC, REST, Lakekeeper, Hive, Snowflake and Unity.

What's good

• Its ingestion overview lists CDC for PostgreSQL, MySQL and SQL Server, labels MongoDB "CDC via Kafka", and offers SQL for shaping data.
• Its docs say Iceberg maintenance, including compaction and snapshot cleanup, is automatic. We did not test how that behaves on your table sizes, so ask what it costs to run.

Where it falls short

• Some features need a licence key, and RisingWave's pricing page lists direct SQL Server CDC as premium. So "open source" applies to the core only.
• Schema evolution on the Iceberg sink covers adding columns only, and works only while exactly-once is on, per its docs.
• Its Postgres source needs primary keys that match upstream tables.

4. OLake Go: for scheduled copies from Postgres, MySQL, MongoDB or SQL Server​

At a glance: Apache 2.0 open source that runs on your own infrastructure. OLake Go does a full load and then change capture straight from the database, and writes Apache Iceberg or Parquet on storage you control, with no Debezium or Kafka to run. Install with Docker, Helm or the UI (see the Docker install page).

OLake home page, October 2026.

What it writes: Iceberg tables. For updates, OLake Go has an Upsert mode with three delete formats: equality deletes and positional deletes (both Iceberg v2), and deletion vectors (Iceberg v3). The default (see the terminology page) is the first format your selected query engine supports, checking equality deletes, then positional deletes, then deletion vectors.

Different streams in one job can use different formats.

Deletion vectors were added in release 0.11.0. That release note lists them as a delete mode and says nothing wider about Iceberg v3 tables. The engine compatibility page lists Amazon Athena as not supporting deletion vectors, so check your engine first.

What's good

• CDC covers PostgreSQL, MySQL and its MariaDB flavor, MongoDB and SQL Server. The setup pages are Postgres, MySQL, MongoDB and SQL Server.
• In the Streams panel, every table starts as Upsert and you can switch a table to Append. Full refresh is always append, and a table found later defaults to Upsert unless every table is set to Append; see the terminology page above.
• The v0.5.0 release notes describe a two-phase commit for Iceberg writes from MongoDB, PostgreSQL, MySQL and SQL Server, which avoids duplicate writes. The v0.7.0 notes name the Iceberg table property that records it, olake_2pc.
• The catalogs compatibility page lists a wide set of Iceberg catalogs, including AWS Glue, JDBC, Hive Metastore, S3 Tables, Nessie, Polaris, Unity and Lakekeeper.
• The schema page documents schema evolution for widening type changes.
• OLake Fusion, a separate OLake product, handles compaction and Iceberg table maintenance.

Good to know

• Oracle, Db2 and S3 sources load by full refresh or incremental sync.
• Jobs run on a schedule you set: every minute, hourly, daily, weekly or a cron expression (see the job settings page). By default CDC captures recent changes, replicates them, then stops (see the terminology page), and an orchestrator such as Airflow can run jobs at frequent intervals for near real-time replication. Freshness follows the schedule you choose, so set it to match your target.
• MySQL BINARY columns written to Iceberg are tracked in an open issue in the OLake repository, reported on v0.8.2.

Bottom line: Pick OLake Go for scheduled copies from PostgreSQL, MySQL, MongoDB or SQL Server into Iceberg or Parquet on storage you run, with one tool to install, Apache 2.0 licensing and 11 catalog options to choose from.

5. Estuary: a hosted pipeline where you don't run the capture side​

At a glance: Hosted, with private and bring-your-own-cloud options. The platform code is under the Business Source License 1.1, which its own text says "is not an Open Source license."

Estuary home page, October 2026.

What it writes: Estuary's Iceberg connector writes to catalogs that implement the Iceberg REST API (a standard web interface for catalogs). The docs walk through AWS Glue, Snowflake Open Catalog and Dremio Cloud. A second connector appends Parquet files to Iceberg tables on an interval.

What's good

• Its docs list log-based capture connectors for PostgreSQL, MySQL, MariaDB, SQL Server, Oracle and MongoDB.
• Its docs list optional Glue table optimizers for compaction, snapshot retention and orphan file deletion.

Where it falls short

• The REST connector needs an Amazon EMR Serverless application running Spark, an S3 staging bucket and IAM roles in your AWS account.
• The docs say only REST catalogs on Amazon S3 are supported, and label the connector Beta for catalogs other than Glue. Nested types aren't supported, so arrays and objects arrive as strings.
• The optimizers are off by default, and without them the docs say to run regular maintenance yourself.
• Estuary's pricing page lists $0.50 per GB moved plus connector fees, read October 2026, so the bill grows with your data volume. Ask for an estimate on your own change volume before you commit.

What users say: An August 2026 G2 review, mirrored on AWS Marketplace, says "Some limited observability - would be nice to see more detailed logs".

6. Fivetran Managed Data Lake Service: if Fivetran already moves your data​

At a glance: Hosted by Fivetran, and the destination page lists the SaaS deployment model only. Fivetran's docs say it "always creates Apache Iceberg metadata" for these tables, and since July 2026 Delta Lake metadata is opt-in.

Fivetran documentation, October 2026.

What it writes: Iceberg tables on S3, Azure Data Lake Storage or Google Cloud Storage. The default catalog is the Fivetran Catalog, an Iceberg REST catalog built on Apache Polaris, with Glue and BigLake as options.

What's good

• Fivetran hosts the service, and the destination page asks you for no brokers, cluster or sink.
• Fivetran also sells connectors for databases and SaaS apps, so one vendor could cover both if your sources are on its list.

Where it falls short

• Fivetran bills by monthly active rows per connection, and its billing docs say deletes count as paid rows from January 1, 2026. Ask for an estimate on your own row counts before you commit.
• The docs say there's no support for Iceberg position deletes. Fivetran's catalog docs warn that editing Fivetran-managed tables from outside can corrupt them.
• Maintenance lists snapshot and unreferenced-file cleanup, but compaction isn't listed. A troubleshooting page says Glue compaction on these tables is reverted at the next sync.
• The destination page says Fivetran ingests data from "supported sources" and names no database connectors. Fivetran's PostgreSQL connector page documents capturing deletes through logical replication, but the MongoDB connector page doesn't mention this destination, so confirm your own source by name with Fivetran.

7. dlt: for Python teams who want pipelines as code​

At a glance: dlt is an open-source Python library, and dltHub is the paid platform on top of it. The Iceberg docs say dlt writes Iceberg tables through its filesystem destination, using the PyIceberg library.

dltHub home page, October 2026.

What it writes: Parquet only, to whatever catalog PyIceberg can load, "including REST and SQL catalogs." Merge supports upsert and insert-only. You bring your own catalog, since the docs describe no managed one.

What's good

• Pipelines live in your code and your repo, so you can review them like any other code.
• Its Postgres source reads a replication slot with the built-in pgoutput plugin, as the pg_replication docs explain.

Where it falls short

• Log-based CDC in the open-source library is PostgreSQL only. The docs describe no log-based CDC for MySQL or Oracle, and SQL Server uses Change Tracking under the commercial dltHub licence.
• The docs list limits: no partition evolution (changing how an existing table is split into folders), Parquet only, and schema evolution isn't supported with upsert on PyIceberg 0.10.0.
• You write, schedule and watch the code.
• dltHub's pricing FAQ says paid subscriptions include a licence for CDC and Iceberg support. The open-source Iceberg docs show no licence notice, so check which features need one before you rely on them.

What users say: In a July 2026 post on moving one daily MySQL sync from Fivetran to dltHub, the author wrote that the pipeline "does not reproduce Fivetran's soft-delete behavior for physical source deletes."

Left out of the list, and why​

Two tools did not meet the three rules in How we picked. The first is Amazon Data Firehose, which is not a current Kafka-free option.

In November 2024 AWS announced that Firehose could read PostgreSQL and MySQL and replicate changes to Iceberg tables, as a preview. AWS then added an update to that announcement post: "The preview period has ended on 09/30/2025 and its not possible to try this capability." We found no AWS page that offers database-to-Iceberg replication today.

AWS News Blog, Amazon Data Firehose database replication post, October 2026.

Firehose still writes Iceberg from other sources. Its docs say it supports Iceberg version 2 only and writes Parquet, and for self-managed tables "you manage all the table optimizations such as compaction, and snapshot expiration."

The second is Supermetal. Its announcement of April 1, 2026 describes a single Rust program that reads the database log and writes Iceberg with no Kafka, Spark or Flink. We read only that post, not documentation on catalogs, deletes and upkeep, so it didn't get a full entry.

Postgres without Debezium or Spark​

Of the options above, only Estuary's REST connector lists a Spark application as a prerequisite. Flink CDC's docs say some of its sources use Debezium inside, so ask each vendor if that matters to you.

All of them still read the same thing: Postgres's write-ahead log (WAL), through a replication slot, which is a bookmark that Postgres keeps for the reader. Several also need a publication, which is a list of tables whose changes Postgres will stream.

Estuary's docs warn that if a slot stops advancing, Postgres keeps WAL without limit by default. That risk follows you into every route.

Which one should you pick?​

FAQs​

Conclusion​

Ask whether you need what Kafka provides, then test one update and one delete before you commit.

Last reviewed October 2026. If a vendor spots a statement here that's out of date, tell us and we'll correct it.

There is no single best pick among data migration tools, because "migration" covers four different jobs. This post sorts twelve tools by job, with dated prices and what each one cannot do.

What data migration means​

AWS defines data migration as moving data from one computing environment or storage system to another, and lists storage, database and application migration among the types. In this post, "source" is where data starts and "target" is where it ends up.

Migration is a one-time move with an end date. Replication keeps a copy current for as long as you need it, which is a different job.

The last row is a different tool family: Flyway's docs describe its migrations as SQL scripts that capture incremental schema and data changes, so it's version control for your tables, not a way to move data between systems.

Homogeneous or heterogeneous​

Google's docs say a homogeneous migration moves between the same database technology, for example MySQL to Cloud SQL for MySQL. A heterogeneous one changes the technology, such as Oracle to Cloud SQL for PostgreSQL.

Heterogeneous moves are harder, because table definitions, data types and code all have to be converted. AWS lists Database Migration Service (DMS) Schema Conversion for that job.

Offline or online​

Offline copies a point-in-time snapshot, so changes made after it starts are not carried over, and you normally stop writes during the copy. The online (continuous) kind follows a full load with a flow of changes until you switch, as Google's docs describe.

Online usually reads the database's transaction log, where every change is recorded in order. That's change data capture (CDC).

How we picked​

Each tool had to move data out of a database or storage system, still be maintained, and publish documentation we could open. We compared job, sources and targets, ongoing changes and price from each vendor's own pages, checked in October 2026. This is a reading of vendor documents, not a lab test, and what vendors say about themselves is reported as their claim.

Schema-migration tools and backup products are left out.

We quote a user comment only when it names a concrete problem, so most entries have none.

Data migration tools at a glance​

Prices use different bases, so read the last column as a way in, not as a like-for-like cost.

Tool	Job	Ongoing changes?	Where data lands	Entry price or free route (October 2026)
AWS DMS	Database to database	Yes, log-based; AWS gives no latency guarantee	Many AWS targets, S3 files; not Iceberg	dms.t3.medium $0.0745 an hour
Azure Database Migration Service	SQL Server to Azure	Online mode on some targets	Azure SQL targets	Current price not established (classic page: Standard free)
Google Database Migration Service	Database to Google Cloud	Yes, continuous mode	Cloud SQL, AlloyDB	Same-engine native moves: no additional charge
Oracle GoldenGate	Database to database, many targets	Yes, one-way or two-way	Many; Iceberg in a separate product	GoldenGate Free for Oracle databases of 20 GB or smaller
Qlik Replicate	Mixed legacy and mainframe	Yes, log-based	Many; Iceberg via a Cloudera target or Qlik's cloud	Not published on Qlik's pricing page
AWS DataSync	Files and objects	Scheduled copies	S3, FSx, Elastic File System	$0.0125 per GB in Basic mode
OLake Go	Databases, S3 and Kafka into a lake	CDC for PostgreSQL, MySQL/MariaDB, MongoDB and SQL Server; full refresh or incremental for Oracle and Db2	Apache Iceberg or Parquet on your own storage; many engines read its Iceberg tables	Open source (Apache 2.0); your own infrastructure and operator time
Google Datastream	Into BigQuery or Iceberg	Yes, backfill then CDC	BigQuery, Cloud Storage, Iceberg tables in BigQuery (append-only)	Per-GiB rates; see its pricing page
Fivetran	Into a warehouse or lake	Yes, per connector	Warehouses and a managed lake service	Free plan to 500,000 rows
Airbyte	Into a warehouse or lake	CDC on scheduled syncs	Warehouses and Iceberg on S3 and GCS	Core free; Cloud Standard from $20 a month
Hevo	Into a warehouse	Log-based; streaming on request	Warehouses; a Snowflake Iceberg destination in early access	Free to 1M events; Starter from $299 a month
Skyvia	SaaS apps and databases	Log-based CDC for SQL Server only	Warehouses and databases	Free to 10k records; Basic $99, shown reduced to $79

The 12 best data migration tools​

Database to database​

1. AWS Database Migration Service: best for moving databases into AWS​

At a glance

• Job: One-time moves or ongoing replication between databases
• Price: Replication instance hours or Serverless DCU hours (a DCU is 2 GB of memory), plus storage, with no separate CDC fee; dms.t3.medium lists at $0.0745 an hour in us-east-1, on demand, Single-AZ (AWS DMS pricing, checked October 2026; price file published September 11, 2026)

AWS says a DMS task can run a full load first and then capture changes. The docs list sources such as Oracle, SQL Server, MySQL, MariaDB, PostgreSQL, MongoDB and Db2. It reads Oracle with LogMiner or a binary reader, MySQL binary logs, PostgreSQL logical slots and the MongoDB oplog.

AWS Database Migration Service product page, October 2026.

What's good

• AWS's targets list includes S3, Redshift, DynamoDB, Kafka and many database engines.

Where it falls short

• AWS's best practices page says DMS ongoing replication does not provide real-time replication and that AWS offers no SLA (service level agreement) for CDC latency. It adds that latency can spike to several minutes or longer when the source is busy.
• Apache Iceberg is not a target, though an AWS blog has DMS write S3 files and Glue jobs load them into Iceberg.

Ask AWS: its product page says "Zero data loss and data accuracy are maintained" through data validation. That is AWS's claim, and the validation limits further down show what it cannot check.

2. Azure Database Migration Service: best for SQL Server into Azure​

At a glance

• Job: Moves SQL Server databases to Azure SQL targets
• Price: Not established for the current service. The only pricing page we found is for Azure DMS (classic): a free Standard tier for offline moves and Premium 4-vCore at $0.37 an hour, free for the first 6 months (Central US, Microsoft's pricing page, October 2026)

Microsoft's overview lists three targets: Azure SQL Database (offline), Azure SQL Managed Instance and SQL Server on Azure Virtual Machines (both online and offline). It also lists schema migration, Azure CLI and PowerShell automation, and private endpoints. The pricing page says "classic" and does not say whether the portal service has the same rates, so treat those figures as history.

Azure Database Migration Service product page, October 2026.

What's good

• Microsoft's overview lists online moves for two of its three targets.
• Schema migration and command-line automation are listed as supported.

Where it falls short

• Microsoft's overview table does not list assessment, login migration or databases encrypted with Transparent Data Encryption for the portal version.
• Microsoft's retirement notice says DMS (classic) for SQL Server scenarios was not supported after 15 March 2026.
• That notice points users to the portal service and puts MySQL, PostgreSQL and MongoDB scenarios out of scope.

Check before you rely on it: the product page card in the screenshot says the service supports SQL Server, MySQL, PostgreSQL and MongoDB migrations. The Learn overview names Azure SQL targets only, so confirm your exact source and target pair on Microsoft's supported-scenarios page.

3. Google Database Migration Service: best for moving into Cloud SQL or AlloyDB​

At a glance

• Job: One-time or continuous moves into Google Cloud databases
• Price: No additional charge for native same-engine moves to Cloud SQL or AlloyDB for PostgreSQL; per GiB processed for different-engine moves (Google's pricing page, October 2026)

Google's overview lists same-engine moves to Cloud SQL for MySQL, Cloud SQL for PostgreSQL, AlloyDB and Cloud SQL for SQL Server. It also lists different-engine moves from Oracle or SQL Server to Cloud SQL for PostgreSQL or AlloyDB.

Google Database Migration Service product page, October 2026.

What's good

• Native same-engine moves to Cloud SQL or AlloyDB for PostgreSQL carry no additional charge, and the pricing page says per-GiB billing counts raw, uncompressed bytes.
• A continuous mode that follows the first copy with changes.

Where it falls short

• Destinations are Google Cloud databases only, and no lake or warehouse is listed.
• The pricing page gives the free backfill allowance two ways, 500 GiB in the summary and 50 GiB in the details, so we quote neither.

Ask Google: its product page says the service gives "highly accurate, high-fidelity migrations" and that you can run a validation first. Ask what the validation compares.

What users say: A guide on the observability vendor OneUptime's blog, written about moving Amazon Relational Database Service (RDS) PostgreSQL, warns that "DMS sometimes does not sync sequence values perfectly" (OneUptime blog, February 2026). Check sequences after any PostgreSQL cutover.

Google Cloud's Database Migration Service pricing page, October 2026.

4. Oracle GoldenGate: best for Oracle estates and long-running or two-way copies​

At a glance

• Job: Real-time copies between many systems, including one-way, two-way and multi-way setups
• Price: Oracle's Technology Global Price List (edition dated September 15, 2026, read October 2026) lists GoldenGate at $17,500 per Processor or $350 per Named User Plus, and counts the processors or users at both the capture and the apply database. This is list price, and we do not know what any buyer pays.

Oracle's FAQ says GoldenGate captures, transforms and delivers changes across systems in real time, and lists zero-downtime migrations among its uses. Its supported list includes Oracle, MySQL, PostgreSQL, SQL Server, Db2, MongoDB, Kafka, Snowflake and Apache Iceberg.

Oracle GoldenGate product page, October 2026.

What's good

• Oracle's FAQ lists Oracle among its supported sources and documents two-way setups, with advice to define conflict rules.
• GoldenGate Free is limited to Oracle databases of 20 GB or smaller. Oracle says it can be used in production but is not supported by Oracle Support (community forums only), and it cannot be used with fully licensed GoldenGate products.

Where it falls short

• Iceberg writing sits in a separate product, GoldenGate for Distributed Applications and Analytics, per Oracle's FAQ and Iceberg docs.
• Oracle's FAQ says it cannot capture from Salesforce, Teradata or TimesTen.

Ask Oracle: for a written quote that covers both the capture and the apply side, and for the support terms of the edition you would run.

5. Qlik Replicate: best for mixed legacy and mainframe sources​

At a glance

• Job: Log-based copies from many databases to many targets
• Price: No list price for Qlik Replicate on the pages we read. Qlik's pricing page describes its separate cloud subscription, Qlik Talend Cloud, as capacity bands by data volume and job runs, also without list prices (October 2026)

Qlik's product page lists Oracle, SQL Server, Db2, MySQL, PostgreSQL and mainframe sources. Qlik describes Replicate as client-managed software, so you install it yourself.

Qlik Replicate product page, October 2026.

What's good

• A Cloudera Iceberg target endpoint, added in the May 2026 release. Qlik's pricing page also lists Qlik Open Lakehouse for Apache Iceberg in the Standard edition of Qlik Talend Cloud, which is a different product from Replicate.

Where it falls short

• Prices are not published, and you run the software yourself.
• Replicate's own Iceberg route in the notes we read is the Cloudera target. The Iceberg lakehouse feature belongs to Qlik Talend Cloud.

Check before you rely on it: Qlik's page headline calls Replicate "Universal Data Replication Software". Confirm your exact source, target and versions with Qlik.

Files and objects​

6. AWS DataSync: best for moving files and objects into AWS storage​

At a glance

• Job: Online transfer of files and objects, with checks that the copy matches
• Price: Basic mode $0.0125 per GB; Enhanced mode $0.015 per GB plus $0.55 per task execution (US East (Ohio), AWS DataSync pricing, October 2026)

AWS describes DataSync as a service to move data from on-premises storage, other clouds and AWS storage to Amazon S3, Amazon Elastic File System and FSx. It validates data end to end. AWS's Basic mode example moves 50 TB of 16 MB files into an empty S3 bucket for $640 in DataSync fees plus $16.38 in S3 requests, $656.38 in all.

AWS DataSync home page, October 2026.

What's good

• Basic mode lists a flat per-GB fee, and AWS gives a worked example on the pricing page.

Where it falls short

• The pages we read name file and object storage only, with no database or change capture.
• S3 and other AWS charges come on top, and cross-region copies add transfer fees. The example assumes 16 MB files, and our reading of AWS's formula is that request charges grow with file count.

AWS DataSync pricing page, October 2026.

Into a lake​

7. OLake Go: best for copying databases into Iceberg or Parquet on storage you run​

At a glance

• Job: Copies databases, S3 files and Kafka topics into Apache Iceberg or Parquet files, with change capture for four database families
• Price: Open source under the Apache 2.0 licence (GitHub repository). There is no licence fee. You run it on your own infrastructure, so your cost is your own servers, storage and engineering time.

OLake Go reads PostgreSQL, MySQL and MariaDB, MongoDB and SQL Server with change capture after a full load, and reads Oracle and Db2 by full refresh or incremental copy. See the connector overview for every source.

It also reads S3 files and Kafka topics, with a single sync mode for Kafka (see the Kafka docs).

It writes Apache Iceberg tables through catalogs such as AWS Glue, Hive, a database used as the catalog or a catalog service over a web API, or Parquet files. The quickstart covers installing it.

OLake's home page, October 2026.

What's good

• Change capture for PostgreSQL, MySQL and MariaDB, MongoDB and SQL Server, after a full load.
• Output is Iceberg or Parquet files in storage you control, in open formats, with 11 Iceberg catalogs to choose from: AWS Glue, Hive Metastore, JDBC, S3 Tables and REST catalogs including Nessie, Polaris, Unity, Lakekeeper, BigLake and Snowflake Horizon.
• Other engines can query the Iceberg tables it writes: Athena, Spark, Flink, Trino, Dremio, DuckDB, Snowflake, BigQuery (through BigLake), Redshift and Databricks, each with the catalogs it works with. The compatibility page has the full table.
• Row-level deletes can be written as equality deletes, positional deletes or, since v0.11.0, Iceberg v3 deletion vectors. Deletion vectors are a delete mode, not general Iceberg v3 table writes, so check your query engine's column on the compatibility page.
• Iceberg partitioning is set per stream with transforms such as year, month, day, hour, bucket and truncate, and it installs with Docker, Helm or the UI (quickstart).

Good to know

• Scope: change capture covers PostgreSQL, MySQL/MariaDB, MongoDB and SQL Server, and each source page lists its setup prerequisites, for example the SQL Server docs. Oracle, Db2 and S3 load by full refresh or incremental copy.
• Snowflake, BigQuery and Redshift can query the Iceberg tables OLake Go writes in place (Snowflake reads tables from an external catalog as read-only).

Bottom line: pick OLake Go when PostgreSQL, MySQL, MongoDB or SQL Server data is heading into Iceberg or Parquet on a lake you run. Pick GoldenGate or Qlik Replicate for Oracle change capture, Datastream for BigQuery on Google Cloud, or Fivetran, Airbyte or Hevo to load a warehouse directly.

Recent fix: v0.11.0 fixed timestamps that the legacy Iceberg writer had cut to millisecond precision.

8. Google Cloud Datastream: best for BigQuery on Google Cloud​

At a glance

• Job: Backfill then change capture into BigQuery, Cloud Storage or Iceberg tables in BigQuery
• Price: Per GiB processed; rates are on Google's Datastream pricing page (October 2026)

Datastream is Google's serverless CDC and replication service. Its sources page lists MySQL, Oracle, SQL Server, PostgreSQL, MongoDB and Spanner.

Google Cloud Datastream product page, October 2026.

What's good

• Idle streams cost nothing, per Google's pricing page, and it supports a first backfill plus change capture.

Where it falls short

• Google says a "processed byte" can be 2 to 5 times larger than the actual data, so test before you budget.
• Google's Iceberg destination docs cover Apache Iceberg tables in BigQuery and say "Streaming to Apache Iceberg tables is supported only in the append-only write mode."
• Google documents it only as a Google-run service, with no self-hosted option.
• Google's Datastream page carried a banner on 8 October 2026 saying the SQL Server source is in preview, but the sources page shows no label. Check its status.

Append-only means rows are only added to the table. Google's page does not say how an updated or deleted source row shows up there, so check that before you treat the table as the current state of the source.

Ask Google: its page calls Datastream "Serverless and easy-to-use", which is a claim, not a test result.

Into a warehouse or business apps​

9. Fivetran: best for a vendor-run copy into a warehouse​

At a glance

• Job: Managed pipelines from databases, apps and files into warehouses and lakes
• Price: Monthly Active Rows (MAR, rows added or changed in a month) per connection; a Free plan up to 500,000 MAR; paid rates are in its Service Consumption Table, not on the pricing page (Standard from $495 per million MAR for the first million, list price per connection; Fivetran pricing page, October 2026)

Per its sync overview, Fivetran runs a first historical sync, then switches to incremental syncs. Its database connectors use the source's native change capture or its own methods.

Fivetran's home page, October 2026.

What's good

• A vendor runs it, and its docs connector page is titled "700+ Data Integration Connectors" (Fivetran's count, not ours).
• Its Managed Data Lake Service writes Apache Iceberg to S3, Azure Data Lake Storage and Google Cloud Storage, per its docs.

Where it falls short

• Fivetran's Managed Data Lake Service docs say it does not support position deletes for Iceberg tables and advise avoiding queries that generate them.
• A MAR bill follows how much your data changes, so estimate it on a trial before you commit.

10. Airbyte: best for a long connector list you can self-run​

At a glance

• Job: Syncs from many sources into warehouses, databases and lakes
• Price: Core is free to run yourself; Cloud Standard is $20 a month with 5 credits and $5 per extra credit, per Airbyte's 15 September 2026 release note (Airbyte pricing page, October 2026)

Airbyte's own pages say 600 or 700 plus connectors, depending on which page you read. Core is self-managed, and its repository licence is the Elastic License 2.0, which forbids offering it to others as a hosted service.

Airbyte's home page, October 2026.

What's good

• A self-run edition, and Iceberg destinations for S3 (per its S3 Data Lake docs) and GCS.

Where it falls short

• Its CDC docs say views are not supported and that TRUNCATE and table-structure changes do not appear in the logs it reads. Syncs run on a schedule.
• Airbyte's Cloud limits page says Standard syncs at most hourly, and Plus every 15 minutes.
• "Free" for Core covers the licence only. You still pay for the servers and the people who run it.

11. Hevo: best for no-code loads into a warehouse​

At a glance

• Job: Managed pipelines from SaaS apps, databases and files into warehouses
• Price: Events (each record inserted, updated or deleted); Free to 1M events a month; Starter from $299 a month for 5M events, or $265 billed annually (Hevo pricing, October 2026)

Hevo's home page claims 150 or more connectors. Its docs list log-based reading for MySQL, PostgreSQL, MongoDB, SQL Server and Oracle.

Hevo's home page, October 2026.

What's good

• A free plan and a 14-day trial.
• Warehouse destinations include Redshift, BigQuery, Snowflake and Databricks.

Where it falls short

• Its destinations docs say databases are not recommended as destinations, though it supports some, so it looks like a poor fit for database-to-database moves.
• Its docs say you must contact Hevo Sales to enable streaming pipelines. The only Iceberg destination we found is a Snowflake-managed one in early access.

Check before you rely on it: Hevo's home page shows customer claims such as "85% Reduction in platform costs". Those are Hevo's marketing figures, so ask for the method.

12. Skyvia: best for SaaS apps and small, scheduled moves​

At a glance

• Job: Import, export, replication and sync for cloud apps and databases
• Price: Records per month (a record counts even if no field changed); Free to 10k records a month; Basic $99, shown reduced to $79 (the page does not say which is the annual price) (Skyvia pricing, October 2026)

Skyvia is a cloud service from Devart, and its home page says "200+ Ready-to-Use Connectors" across cloud apps, file storage, databases and data warehouses. For SQL Server, its SQL Server replication page says it supports true CDC. For other sources it finds changes with timestamp or auto-increment columns.

Skyvia's home page, October 2026.

What's good

• A free plan, no-code setup, and an Agent mode for databases behind a firewall.
• It lists apps such as CRMs that the cloud providers' database tools do not.

Where it falls short

• Log-based CDC is documented for SQL Server only. Its replication docs say a new source field is not replicated until the task is updated.
• It is cloud only on the pages we read, and the free plan allows daily runs at most.

Others you'll see in other lists​

• Informatica was acquired by Salesforce, which announced completion on 18 November 2025.
• Debezium is the open-source engine that reads database logs, and you run it yourself.
• Talend Open Studio was retired on 31 January 2024, according to Qlik's page.

Which data migration tool should you pick?​

How an online database cutover runs​

Google's architecture guide splits an online database migration into six phases and uses the term "near-zero downtime" for the goal.

Phase 6, fallback, is a contingency for a switchover that goes wrong. Google says clients of the old source databases "need to be kept available and operational so that they can be turned on in a fallback".

Quiesce means pause writes. Google says a fallback might be required days or weeks after the switchover, so keep the source until you are sure you will not need to go back.

AWS's best practices page, linked above, adds two tool-level points. AWS DMS does not automatically create secondary indexes, foreign keys or user accounts on the target, so those are on you. AWS also recommends running a small test migration first.

Prove the copy matches​

AWS DMS has a data validation feature that compares each source row with its target row and reports mismatches. Ask every vendor for something like it.

AWS DMS documentation, data validation limitations, October 2026.

• Tables need a primary key or unique index, so a table without one cannot be checked.
• Validation adds queries on both databases and takes extra time beyond the migration itself.
• Rows that change constantly cannot be compared, and views are not supported.
• AWS says validation stops if it finds more than 10,000 failed or suspended records.
• A validation-only task checks rows without migrating data, for a check just before a cutover.

A small check you can try (an illustration, not a result)​

This is a made-up example. We have not run it on any of these tools.

• Make a test table with three rows: (1, "a"), (2, "b") and (3, "c"). Start the migration.
• While it runs, insert (4, "d"), update row 2 to "b2" and delete row 3.
• Switch over, then count rows and compare a checksum on both sides. Expect (1, "a"), (2, "b2") and (4, "d"), with no row 3 and no duplicates.
• For a lake target, check whether deletes arrive as removed rows or as extra change records.

Every Fivetran fact below comes from Fivetran's own pages, read between October 1 and October 7, 2026, with the page linked beside the claim. User quotes and the rows for other tools carry their own sources.

Where a number isn't published, we say "not published". We did not run Fivetran, so this is a read of its documents, not a hands-on test. Claims about ease, speed or reliability are Fivetran's claims, and we did not test them.

What is Fivetran?​

Fivetran describes its connectors as pre-built, and says they sync data from applications, databases, event streams and files to a data warehouse or data lake. A connector is a ready-made piece of software for one kind of source, such as a customer relationship management (CRM) tool like Salesforce, or a database like PostgreSQL. The pricing page calls them "fully managed". Taken at its word, that means Fivetran runs them, not you.

Fivetran home page, October 2026.

Two words will come up again and again. A source is where your data starts, such as a database or a business app. The destination is where Fivetran puts the copy, such as a data warehouse or a lake on cloud storage.

Per its transformations docs, Fivetran uses the extract, load, transform (ELT) model, so raw data stays available alongside transformed data. Fivetran loads the raw tables into a destination schema (a named folder inside the destination), and the transformations run in your destination.

How a Fivetran sync works​

A sync is one run that moves data from a source to a destination. Fivetran's sync overview gives the order of events, and it's short.

1. Initial sync. You have to run a historical sync before a connection is usable. The first one is the initial sync, and it copies all the data from the tables you selected.
2. Incremental sync. Once the first run succeeds, the connection switches to incremental mode. Only data that was modified or added gets extracted, processed and loaded on schedule.
3. Re-sync. Found a data integrity error? You can run a historical sync again. That's called a re-sync.

Fivetran's sync overview page, October 2026.

Fivetran uses cursors, markers of what it has already processed, so the next run can resume from that point. Its database docs say it also records the time of each row's last sync in a column called _fivetran_synced.

How often does it sync?​

Per the sync overview page, you can pick a fixed interval, a cron schedule (a standard way to write timed schedules, on Enterprise and Business Critical plans only), or manual runs through its API. Every six hours is the default, and you can't schedule syncs less often than once every 24 hours.

Database connectors skip that default. Per the database connector docs, they sync new and changed data every 15 minutes. The pricing page, covered below, lists 15-minute syncs on Standard and 1-minute syncs on Enterprise.

How does it catch database changes?​

So how does it spot changes in a database?

Fivetran uses the database's own change data capture (CDC) feature or a method of its own, depending on the database. CDC means reading the log where a database writes down every change, so you copy only what changed.

The database docs go database by database. The native routes are the binary log (MySQL's record of changes) for MySQL and MariaDB, logical replication (PostgreSQL's built-in way to stream changes) for PostgreSQL, and change streams (MongoDB's feed of changes) for MongoDB. For SQL Server, they are its Change Data Capture or Change Tracking features.

Teleport Sync is a separate, Fivetran-made method that doesn't read the change log. The database docs recommend it when you can't or don't want to give Fivetran access to your change logs. Their stated limit: if you update large parts of a table between syncs, Teleport Sync may be unable to find the changes, and the connection re-syncs the entire table.

A documented failure: when the change log runs out​

Here's where things can go sideways, and the database docs say so plainly. Change logs expire, either by time or when the storage set aside for them fills up. If Fivetran falls behind for longer than the log is kept, the progress point is gone.

Fivetran's docs say: "Expired change logs require a full source re-sync." For SQL databases, that page names schema changes in the source as the most common trigger for a full table re-sync. On a big table, plan for the extra load and the extra wait.

A worked example: one orders table​

Sometimes a tiny example beats a page of docs. The tables below are an illustration, not a test run: we built them from the columns Fivetran documents, and we did not run Fivetran.

Per Fivetran's PostgreSQL connector docs, with logical replication a DELETE in the source table updates the destination row with _fivetran_deleted = TRUE. The database docs say _fivetran_synced records when each row last synced.

Source orders table at the first sync (T0), then at the next sync (T1):

Destination orders table after the T1 sync:

Order 3 is still in the destination. It's just flagged.

So your queries have to filter it out. SELECT count(*) FROM orders returns 4 here, and adding WHERE _fivetran_deleted = false returns 3, which matches the source. Skip the filter and deleted orders show up in your reports.

Now the billing angle. Fivetran's usage-based pricing docs say a row is counted once per month, even if it syncs many times. And since January 1, 2026, deletes count toward paid MAR like any changed row.

If the T1 changes all land in the same month after the initial sync, rows 2, 3 and 4 count as active that month, so that is 3 MAR. Row 1 doesn't count, because it never changed.

Now picture the log window running out between T0 and T1. The changes could not be read, and per the database docs a full source re-sync is then needed. So plan for a full re-copy.

Fivetran connectors, by type​

How big is the catalog? Fivetran's connector directory says it moves data from 750+ sources and activates back into 200+ destinations. That 200+ figure counts activation targets, such as CRMs and marketing tools (see Activations below), not warehouses or lakes.

The connectors docs title and the pricing page both say 700+, so quote the page you used.

The docs sort connectors into six groups: Applications, Databases, Events, Files, Functions and Logs. Database connectors read changes from the source database, so they need setup on your side, such as log retention and permissions.

Source missing from the list? The docs describe a Connector SDK, which lets you write a custom connector in Python and run it on Fivetran's infrastructure. They also list a By Request Program for connectors not yet in the catalog.

High-Volume Agent (HVA) connectors are a database group of their own. Fivetran's HVA docs list Db2 for i, Oracle, SQL Server and SAP (business software). The pricing page lists "enterprise database connectors" from the Enterprise plan up.

Transformations and the dbt merger​

Raw tables are rarely what your analysts want to query. Fivetran's transformations page lists two options. One is pre-built data models that turn raw tables into analytics-ready ones, and the other is a Fivetran-hosted dbt integration, plus dbt Cloud and Coalesce connections.

(dbt, in case you're new to it, is a popular tool for writing SQL transformations.)

All these jobs run in your destination. Up to 5,000 model runs a month are free. One limit to flag: the same page says "Fivetran-hosted Transformations for dbt do not support Managed Data Lake Service destinations", a point we return to below.

On June 1, 2026, Fivetran announced the completion of its merger with dbt Labs. It was an all-stock deal first announced on October 13, 2025, and the combined company initially operates as Fivetran + dbt Labs.

Activations: sending data back out​

Most of this post is about data flowing in. Activations flips it: it sends data from the warehouse back out into business tools, such as a CRM. This is often called reverse ETL (ETL means extract, transform, load).

Fivetran's pricing page lists 200+ managed activation destinations. Activations bill on monthly active rows too, with their own Free-plan allowance.

Managed Data Lake Service and Apache Iceberg​

Not everyone wants a warehouse. With Managed Data Lake Service, Fivetran writes your data to cloud storage you own: Amazon S3, Azure Data Lake Storage or Google Cloud Storage. It writes Parquet files there and manages the table metadata and upkeep.

Apache Iceberg is an open table format. The short version: it lets several query engines read the same files as ordinary tables.

Fivetran's Managed Data Lake Service page, October 2026.

On the format, the docs say Fivetran always creates Iceberg metadata for these tables, and can optionally add Delta Lake metadata. The default catalog (the service that tracks your tables) is the Fivetran Catalog, built on Apache Polaris. Per the catalog docs, you can also connect AWS Glue and BigLake metastore for Iceberg tables, and Databricks Unity Catalog and OneLake for Delta Lake metadata.

The lake docs list 12 compatible query engines, including Amazon Athena, BigQuery, Snowflake, Databricks and DuckDB. So, per its docs, reading the tables from other tools is the intended use.

What to check before you pick the lake destination​

Fivetran says it writes the files, keeps the catalog and runs table upkeep, so you don't build that yourself. We did not test how well it does this. The trade is control: you own the storage bucket, but Fivetran manages the tables in it.

Fivetran's catalog docs are direct: "Do not modify these tables manually or by using any external catalog, as doing so may lead to data integrity issues." Read-only credentials are the default. So ask what your other tools can still do with these tables, using the documented limits below.

A missing upkeep task in the docs isn't proof the service lacks it. So treat the right-hand column as questions to put to Fivetran in a trial, using your own sync interval.

Deployment, security and compliance​

Where does your data actually get processed?

The deployment models page describes two options. With SaaS, "data processing is handled entirely within the Fivetran cloud". Hybrid is for teams that "need to keep their data local for security or compliance reasons but still want to benefit from Fivetran managed service".

The pricing page lists hybrid deployment as an Enterprise plan feature. We found no published source licence for the core service, so there is no open source version to download and run.

For a security questionnaire, Fivetran's security page lists System and Organization Controls (SOC) 1 and 2, plus International Organization for Standardization (ISO) 27001. It also lists a commitment to GDPR (EU privacy law) and CCPA (California privacy law). A business associate agreement signed by Fivetran covers HIPAA (US health privacy law).

The page says Health Information Trust Alliance (HITRUST) certification, a healthcare security framework, comes with the Business Critical plan.

What does Fivetran cost?​

Fivetran counts MAR per connection. That one detail drives the examples below.

A row counts once in a month however many times it changes. Some re-syncs are free, but re-synced rows that changed count toward paid MAR, per the usage-based pricing docs.

The pricing page lists four plans: Free, Standard, Enterprise and Business Critical.

One thing to flag: Fivetran publishes no single monthly price, and your bill follows usage. The pricing page prints no per-row rate for the paid plans, but Fivetran's Service Consumption Table does, in version 10, effective February 1, 2026.

Those are list prices, before any annual-contract discount.

Fivetran's pricing page, October 2026.

How a bill is worked out​

The table prints one formula, and it's simple enough. Monthly spend for a connection is the base spend, plus your MAR above the threshold, times the incremental spend per million MAR. Partial millions are prorated, and each connection is priced on its own curve.

For one Standard connection, the table's tiers are:

• Up to 1 million MAR: $5 base, plus $495 per million.
• From 1 million MAR: $500 base, plus $170 per extra million.
• From 4 million MAR: $1,010 base, plus $58 per extra million.
• From 16 million MAR: $19.70 per extra million.

Fivetran's Service Consumption Table, October 2026.

Let's put numbers on it. Here are three Standard-plan examples, with the arithmetic ours, from the rates in the screenshot. They are illustrations at list price, not quotes.

Sources: Fivetran Service Consumption Table, version 10, with the arithmetic ours. Checked October 2026.

The orders table above is far too small to bill like this, so take a separate, made-up workload. One connection has 109,000 distinct rows inserted, updated or deleted in a month, with no discount and no free re-syncs involved.

On Standard that is $5 + 0.109 x $495, or about $59 (the exact figure is $58.955). On Enterprise, at $661.67 per million, it is $5 + 0.109 x $661.67, or about $77.

Rates fall as volume grows, so cost per row drops with size. But each connection has its own curve, and you can't pool MAR across connections for a better rate.

Now two more made-up setups with the same 4 million changed rows in total. One connection costs $1,010. Four connections with 1 million MAR each cost 4 x $500, or $2,000.

There's more fine print: annual contracts, pay-as-you-go and the 2025 and 2026 billing changes each have dated rules.

Your warehouse also sends its own invoice. Fivetran's destination docs say your provider may charge for the compute used when Fivetran loads data, and that sync frequency and data volume drive that cost.

Limits to know before you buy​

• The bill depends on your change rates. The rates are published, but the meter counts distinct rows changed, per connection, so you need to know those rates first. The pricing page offers a pricing estimator, which we did not use, and your order form is what binds you.
• Re-copies cost time. For SQL databases, the docs name schema changes as the most common trigger for an automatic full table re-sync. An expired change log means a full source re-sync.
• No open source or self-run version. We found no published source licence. Even the Hybrid model is described as a Fivetran managed service.

What practitioners say​

These are short quotes from public pages, opened on October 1 and 7, 2026. Each is one person's view, and a few quotes can't tell you how common any of these experiences are. We cite none from Fivetran's own customer pages.

• Cost. A commenter on Hacker News, in the thread "A16Z-backed data firms Fivetran, dbt Labs to merge in all-stock deal" (October 2025), wrote "Fivetran is convenient but absurdly expensive."
• Sync problems. A former user wrote in the Hacker News thread "Fivetran to acquire Census" (May 2025) of "regular (probably once every couple of months) issues with our ETL getting out of sync". The same comment says Fivetran ran the full re-syncs for no charge.
• Support. A PeerSpot reviewer in November 2024 wrote "Vendor support is also slow to respond".

One gap: we found no public user threads on its Iceberg lake destination, so we have no peer view on it.

Who Fivetran suits, and who should look elsewhere​

So, should you pick it?

Fivetran is a reasonable choice when you have many SaaS and database sources and want someone else to run the connectors, and you have a budget for usage-based billing. That bill can swing with your change rates. Its pages also list things some other tools do not: the compliance items on its security page, the Oracle and SAP connectors, or one vendor for loading, dbt and reverse ETL. We did not audit those claims.

Look elsewhere if you need a fixed monthly bill, want open source code, or need a destination Fivetran doesn't list. For a lake, look elsewhere if your other tools need to write to the tables Fivetran manages. OLake Go writes Iceberg or Parquet to storage you choose, and several query engines read its tables (see the engine compatibility page).

Test it against your own needs​

A trial or a quote call is the best check. Put these questions to Fivetran, and write down the answers.

• Capture method. Which method does it use for each of your databases, and what must you switch on at the source?
• Recovery time. How long would a full re-sync of your largest table take, and what does it do to your source database?
• Freshness. A sync interval isn't a delivery promise, so ask how Fivetran measures the gap between a source change and a row you can query. The pricing page ties 1-minute syncs to Enterprise.
• Usage quote. Work out monthly active rows per connection from your own change rates, price them with the Service Consumption Table, and ask Fivetran to check the result.
• Lake rules. Run the lake table above past your query engine and transformation tool.
• Support. Which response times apply to your plan? One reviewer above found it slow, and we did not test support.
• Where it runs. Do rules force your data to stay in your network? Then Hybrid deployment is the one to look at.

Fivetran against five other options​

Maybe Fivetran isn't your tool. The table sets it beside five common options on one axis, how each bills, using each vendor's own pricing page as of September 30, 2026. For a fuller comparison, see the head-to-head posts below.

Option	How it bills	Source
Airbyte	Core is open source and self-managed, "always free" (you pay for servers and staff). Cloud bills in credits	airbyte.com/pricing
Hevo	Events: each record inserted, updated or deleted in the destination is 1 event. Free plan up to 1 million events a month	hevodata.com/pricing
OLake Go	No licence fee: open source under Apache 2.0. You pay for your own servers and storage	github.com/datazip-inc/olake
Matillion	Credits by task hour, not rows. Dollar prices not published	matillion.com/pricing
Estuary Flow	$0.50 per GB moved, plus connector instances	estuary.dev/pricing

Debezium, an open source change data capture project under the Apache License 2.0, has no vendor price, and the real cost is the servers and staff you run it with, per its license page.

Conclusion​

By its own description, Fivetran is a managed copy service, with dbt, reverse ETL and an Iceberg lake destination around it. Before you sign, run the checklist above against your largest database table and your lake tools. Then get one quote from another option, so you have a price to compare.

Want to check what you picked up? Try this quick quiz.

FAQs​