A workload-driven comparison of AWS DMS, Debezium, Fivetran, and pgloader. Choose a data migration tool by the job it does: one-time bulk loads, ongoing CDC replication, or managed ELT.
Most "best data migration tools" lists are written by vendors ranking their own product first. They compare tools on feature checkboxes, not on the job you need done. That framing leads teams to reach for a managed CDC platform when a single command-line invocation would have finished the job in an afternoon, or to script pg_dump loops when they really need continuous replication.
The useful question is not "which tool is best" but "which tool fits this workload." A one-time bulk copy from an old MySQL box into PostgreSQL has almost nothing in common with keeping a warehouse in sync with a production database that takes thousands of writes per second. This post compares four tools that each own a different corner of that space: AWS DMS, Debezium, Fivetran, and pgloader, plus a note on where Airbyte fits. Fivetran is not strictly a migration tool; it earns its place here because teams scoping a "migration" into a warehouse very often discover that what they need is ongoing sync, and that is Fivetran's job.
The Four Migration Workloads That Actually Matter
Before comparing tools, name the workload. In our migration engagements, nearly every project collapses into one of four shapes, and the tool follows from the shape.
One-time bulk migration. You are moving a database once, then decommissioning the source. Cutover is a scheduled event, not a continuous process. What you care about is throughput, type fidelity, and how much of the schema (indexes, constraints, sequences) the tool recreates for you. Lag after cutover is irrelevant because there is no "after."
Ongoing CDC replication. The source stays live and you need every insert, update, and delete reflected downstream with low latency, indefinitely. This is the hardest workload. Change Data Capture reads a database's transaction log (the WAL in PostgreSQL, the binlog in MySQL, the redo log in Oracle) and emits each row-level change as an event, rather than repeatedly querying tables. Reading the log instead of polling keeps source-side overhead low and ordering correct. It is one of the core pipeline shapes we lay out in ETL pipeline patterns in 2026.
Managed SaaS ELT. You want operational databases and SaaS apps (Salesforce, Stripe, Postgres) landing in Snowflake, BigQuery, or Redshift, and you do not want to run or babysit the pipeline. You are trading money for the elimination of connector maintenance and schema-drift handling. For the difference between transforming before versus after the load, see ETL vs ELT.
Single-command Postgres loads. A narrow but extremely common case: you are migrating into PostgreSQL specifically, often from MySQL, SQLite, or MS SQL Server, and you want type casting, encoding fixes, and schema creation handled in one shot without standing up infrastructure.
AWS DMS: The Default for Lift-and-Shift Into AWS
AWS Database Migration Service is a managed service for migrating and replicating databases, supporting both one-time full loads and ongoing CDC. It runs the migration on AWS-managed capacity, handles the source-to-target plumbing, and supports heterogeneous moves (for example MySQL to PostgreSQL) when paired with DMS Schema Conversion or the older AWS Schema Conversion Tool. Sources include Oracle, SQL Server, MySQL, PostgreSQL, MongoDB, Db2, and more; targets span Aurora, RDS, Redshift, S3, DynamoDB, and others, per the AWS DMS sources documentation.
DMS offers three replication modes: full load, CDC, and full load plus CDC. The combined mode is the workhorse for zero-downtime cutover: it bulk-copies existing rows, then tails the source transaction log to keep the target current until you flip traffic. AWS DMS Serverless removes the replication-instance sizing decision: it provisions and scales capacity automatically and bills per hour in DMS Capacity Units, where one DCU equals 2 GB of RAM, in increments from 1 to 384 DCUs. That pay-for-use model suits bursty migrations where a fixed instance would sit idle or get overwhelmed.
Two caveats. DMS Serverless does not support setting custom CDC start points, per the Serverless limitations docs, so replay-from-a-specific-LSN recovery scenarios still want a provisioned instance. And AWS is explicit that DMS CDC is not real-time: there is no SLA on replication latency, and it "can increase to several minutes or longer" depending on source load, network, instance size, and target ingestion. CDC also has hard source-side requirements: tables generally need primary keys for updates and deletes to replicate correctly, and the source must be configured for log retention and the right logical replication settings. DMS is strongest as a lift-and-shift engine into AWS targets. It is weaker as a long-term streaming backbone where you want changes flowing into Kafka and consumed by many systems. For the heterogeneous MySQL-to-Postgres case specifically, weigh DMS against pgloader and Debezium in our MySQL to PostgreSQL migration guide.
Debezium: CDC as a Streaming Primitive
Debezium is an open-source CDC platform, licensed under Apache License 2.0, that reads database transaction logs and emits row-level change events, typically onto Apache Kafka via Kafka Connect. It supports MySQL, PostgreSQL, MongoDB, SQL Server, Oracle, MariaDB, Vitess, and others, as listed in the Debezium connectors documentation. Development is active; the 3.6 line is current as of August 2026.
The reason to choose Debezium over DMS for replication is architectural. Debezium does not move data from point A to point B; it turns your database's change log into a durable, replayable event stream that any number of consumers can read independently. One change event can fan out to a warehouse, a search index, and a cache invalidator at once, each consumer tracking its own offset. That fan-out is awkward to model in a point-to-point migration service. Because the stream lives in Kafka, you also get replay: a downstream system can be rebuilt from the retained log without touching the source database again.
The tradeoff is operational weight. Debezium means running Kafka and Kafka Connect (or a managed equivalent), monitoring connector offsets, handling schema changes through a schema registry, and reasoning about exactly-once versus at-least-once delivery in your consumers. For a one-time copy this is wildly over-engineered. For a durable, multi-consumer replication backbone it is the right primitive, and the Apache 2.0 license means no per-row metering on the data itself. For the operational detail, see our Debezium production CDC patterns guide.
DMS or Debezium for ongoing CDC
This is where teams get stuck, so here are the discriminators we use:
- Latency. DMS publishes no latency SLA and lag of minutes is normal under load. Debezium lag is bounded by your Kafka Connect sizing and is typically sub-second to a few seconds; you own the tuning.
- Consumers. One target, especially an AWS target: DMS. Several consumers, or any consumer that needs to replay history: Debezium.
- Recovery. Need to restart from a specific LSN or SCN after an incident: provisioned DMS or Debezium, not DMS Serverless.
- Cost at 24/7. A small provisioned DMS instance is cheaper and simpler than a Kafka plus Connect cluster if you do not already run Kafka. If you do, Debezium is a connector on infrastructure you already pay for.
- Ownership. DMS is AWS's to operate. Debezium is yours, or your managed-Kafka vendor's.
Fivetran and Airbyte: Paying to Not Run the Pipeline
Fivetran is a proprietary, fully managed ELT platform that extracts from 750+ sources and loads into cloud warehouses and lakes, handling schema drift and connector maintenance for you. Its defining characteristic is the pricing model. Fivetran bills on Monthly Active Rows (MAR), the count of distinct rows added, updated, or deleted in a given month, as described in its usage-based pricing docs. A row is counted once per calendar month no matter how many times it changes, so a small status table whose same rows flip constantly is cheap. What drives the bill is the number of distinct rows touched per month: append-only event and log tables, and bulk jobs that re-stamp updated_at on every row. Before committing, profile how many distinct rows change per month per table, and look hard at any nightly job that touches a whole table.
What you buy with Fivetran is the elimination of pipeline operations. Connectors are maintained by the vendor, API schema changes are absorbed upstream, and you do not page anyone at 2am when a source adds a column. That is worth money for teams whose engineers should be building product, not patching connectors. The cost is reduced control, data egress to a third party, and a bill that scales with data change rather than with a fixed budget. See our What is Fivetran primer for the platform model in depth.
Airbyte is the obvious alternative: a source-available ELT platform with 600+ connectors and both self-hosted and cloud options. The platform and connectors are under the Elastic License 2.0, which is not an OSI-approved open source license; only the Airbyte protocol and CDK are MIT, per Airbyte's license docs. Self-hosting Airbyte trades a vendor bill for infrastructure and maintenance you own, which appeals to teams with capacity to run it and a need to avoid MAR-style metering or keep data in their own environment. It is not free in the operational sense, just free in licensing. The What is Airbyte page covers the deployment options.
pgloader: One Command, Postgres-Only, Done by Lunch
pgloader is an open-source data-loading tool, released under The PostgreSQL License, that migrates from MySQL, SQLite, MS SQL Server, and several file formats into PostgreSQL in a single command, creating the target schema, casting types, and loading data in one pass. Its scope is deliberately narrow: the target is always PostgreSQL. Within that scope it is the fastest path from "I have a MySQL dump" to "it runs on Postgres," documented in the pgloader introduction.
pgloader does the tedious parts of a heterogeneous migration automatically. It maps source types to sensible PostgreSQL types, handles encoding conversion, recreates indexes and constraints after the bulk load (which is faster than loading with them live), and continues past individual row errors while logging them rather than aborting the whole run. A migration that would be a multi-step mysqldump, sed-the-DDL, manually-fix-types ordeal becomes a single invocation against a small config file. For the full walkthrough, see pgloader: migrating databases to PostgreSQL in a single command.
It is built for one-time and repeatable bulk loads, not continuous CDC; there is no transaction-log tailing keeping the target live after the load finishes. On very large databases, tune batch rows, prefetch rows, and workers in the load file, and split the run by table rather than loading everything in one process. And because the target is Postgres only, it is irrelevant to any migration that does not end there. For Postgres-bound bulk work, though, nothing else on this list competes on time-to-done. (The same single-command philosophy does not extend to search engines; moving from Elasticsearch to OpenSearch is its own problem, covered in our OpenSearch data migration guide.)
The Comparison Table
| Tool | Type | CDC support | Managed / Self-hosted | Sources / Targets | Pricing model | Best for |
|---|---|---|---|---|---|---|
| AWS DMS | Managed migration & replication service | Yes (full load, CDC, full+CDC; no latency SLA) | Managed (provisioned or Serverless) | Oracle, SQL Server, MySQL, PostgreSQL, MongoDB, Db2 and more; Aurora, RDS, Redshift, S3, DynamoDB targets | Hourly; Serverless billed per DCU-hour (1 DCU = 2 GB RAM) | Lift-and-shift and zero-downtime cutover into AWS targets |
| Debezium | Open-source CDC platform on Kafka Connect | Yes (log-based, core purpose) | Self-hosted (or via managed Kafka providers) | MySQL, PostgreSQL, MongoDB, SQL Server, Oracle, MariaDB, Vitess and more to Kafka | Free (Apache License 2.0); you pay for Kafka infrastructure | Durable, multi-consumer streaming replication and fan-out |
| Fivetran | Proprietary managed ELT | Yes (for supported DB sources) | Managed SaaS | 750+ sources to Snowflake, BigQuery, Redshift, lakes | Usage-based on Monthly Active Rows (MAR) | Hands-off SaaS-and-DB-to-warehouse ELT |
| Airbyte | Source-available ELT | Yes (for supported DB sources) | Self-hosted or Cloud | 600+ connectors to warehouses, lakes, DBs | ELv2 (platform + connectors); Cloud is usage-based | Owning the ELT stack to avoid MAR metering or keep data in-house |
| pgloader | Open-source bulk loader | No | Self-hosted CLI | MySQL, SQLite, MS SQL, files to PostgreSQL | Free (The PostgreSQL License) | One-time / repeatable bulk loads into PostgreSQL |
What to remember
- Fivetran MAR counts a row once per month however often it changes. Wide, append-heavy tables and whole-table re-stamps drive the bill, not chatty rows.
- DMS has no CDC latency SLA, and DMS Serverless cannot restart from a custom LSN. If either matters, use a provisioned instance or Debezium.
- pgloader is unbeatable for one-shot loads into PostgreSQL and irrelevant for everything else.
Most stalled migrations we are called into picked the tool before they defined the workload. If you are weighing these options for a live system, our data migration practice does this workload-to-tooling matching, including the parts that surface only at cutover: sequences, blob columns, custom types.
