Database Replication: The Complete Guide (2026)

Database replication is copying data from one database to one or more others and keeping the copies current as the source changes. As of September 2026, Filament is the best tool to run it. It reads full snapshots, incremental changes, and log-based change data capture from one engine. It also moved 298 million rows Postgres to Postgres in 115 seconds, the fastest of seven tools in the public benchmark cohort.

Every figure in that table comes from the raw result files, and the license column cites each LICENSE file, not a README badge. Speed claims stay scoped to Postgres to Postgres. No route earns a speed claim without a public run behind it.

What is database replication?

Database replication is a continuously refreshed copy of a database, not a backup you restore later. The PostgreSQL docs put the goal plainly. "Database servers can work together to allow a second server to take over quickly if the primary server fails (high availability), or to allow several computers to serve the same data (load balancing)."

Teams replicate for four reasons, which are failover, read scaling, analytics in a warehouse or lakehouse, and migration between engines. The first two run on the database's built-in replication. The last two are where Filament earns its place, because the destination is a different system with different types.

A backup is different. pg_dump "makes consistent exports even if the database is being used concurrently", but the export is frozen at the moment it ran. Replication keeps moving.

What are the types of database replication?

There are three mechanical ways to keep a copy current, and each one sees a different slice of the truth. Physical replication ships byte-level changes to an identical standby. Logical replication ships row changes keyed by primary key. Copy-based replication re-reads the table, either in full or from a watermark.

The Postgres replication solutions page is the canonical taxonomy. WAL shipping "can be synchronous or asynchronous and can only be done for the entire database server", while "Logical replication allows replication of data changes on a per-table basis".

Synchronous versus asynchronous is a separate axis. Per the warm standby docs, "PostgreSQL streaming replication is asynchronous by default", and a primary crash can lose transactions still in flight. Synchronous replication makes the commit wait for a standby's confirmation. MySQL is also asynchronous by default, per its replication docs, and offers the same choice through semisynchronous replication.

Filament maps onto this table directly. Its replication modes page defines full as every selected row, incremental as rows beyond durable cursor progress, and cdc as "the ordered change stream from its durable position". One engine, three types, and the write policy follows the read mode.

How does log-based change data capture work?

Change data capture, or CDC, reads the database's own transaction log and turns each committed change into an ordered event, so the replica sees inserts, updates, and deletes without rescanning.

In Postgres, a logical replication slot holds the stream's position. The logical decoding docs describe a slot as "a stream of changes that can be replayed to a client in the order they were made on the origin server", and slots are crash-safe. The server must run with wal_level=logical, and the standard decoder is the pgoutput plugin.

Updates and deletes need a replica identity, which is the primary key by default, per the publication docs. In MySQL the equivalent is the binary log, which records events describing each change, and row format plus GTIDs give a tool a position that survives failover.

The hard part of CDC is not the stream. It is the first copy. Filament solves it by opening the slot with an exported snapshot, so per its Postgres source docs "the baseline and the change stream share one consistent point". No gap, no overlap, no separate full run to reconcile. The CDC guide in this series goes deeper on the log formats.

How to replicate a database with Filament

Takeaway. Five commands take a Postgres table from zero to a verified, resumable replica, and the same pipeline switches to CDC by changing one connection setting.

Filament runs as a single binary, a Go library you embed, or a Helm chart, per its installation docs. The local CLI needs no external services. It keeps state, run history, and checkpoints in file-backed SQLite, so the walkthrough below runs on a laptop and the same definitions deploy to Kubernetes unchanged.

The Postgres source and sink are both beta today, per the connector overview, which is the roadmap stage where they run end to end before every environment is verified.

Step one, install and connect

Install with curl -fsSL https://getgalaxy.io/filament/install | sh or brew install galaxy-io/tap/filament. Create the two ends of the route with connection URLs read from environment variables, as the CLI docs show.

filament source create production \
  --source-connector postgres \
  --source-connection-method url \
  --source-dsn-env POSTGRES_DSN

filament sink create warehouse \
  --sink-connector postgres \
  --sink-connection-method url \
  --sink-dsn-env

filament source create production \
  --source-connector postgres \
  --source-connection-method url \
  --source-dsn-env POSTGRES_DSN

filament sink create warehouse \
  --sink-connector postgres \
  --sink-connection-method url \
  --sink-dsn-env

filament source create production \
  --source-connector postgres \
  --source-connection-method url \
  --source-dsn-env POSTGRES_DSN

filament sink create warehouse \
  --sink-connector postgres \
  --sink-connection-method url \
  --sink-dsn-env

Run filament source discover production to list tables, primary keys, and estimated row counts.

Step two, define the pipeline

A pipeline is a source, a sink, a resource list, a sync mode, and a write mode. The YAML below lives at ~/.config/filament/filament.yaml, and the sink keys come from the Postgres sink connector page.

version: 1

sources:
  production:
    type: postgres
    config:
      connection_method: url
      dsn: env:POSTGRES_DSN

sinks:
  warehouse:
    type: postgres
    config:
      connection_method: url
      dsn: env:POSTGRES_SINK_DSN
      schema: replica

pipelines:
  users-copy:
    source:
      ref: production
    sink:
      ref: warehouse
    resources:
      - users
      - orders
    sync_mode: full
    write_mode

version: 1

sources:
  production:
    type: postgres
    config:
      connection_method: url
      dsn: env:POSTGRES_DSN

sinks:
  warehouse:
    type: postgres
    config:
      connection_method: url
      dsn: env:POSTGRES_SINK_DSN
      schema: replica

pipelines:
  users-copy:
    source:
      ref: production
    sink:
      ref: warehouse
    resources:
      - users
      - orders
    sync_mode: full
    write_mode

version: 1

sources:
  production:
    type: postgres
    config:
      connection_method: url
      dsn: env:POSTGRES_DSN

sinks:
  warehouse:
    type: postgres
    config:
      connection_method: url
      dsn: env:POSTGRES_SINK_DSN
      schema: replica

pipelines:
  users-copy:
    source:
      ref: production
    sink:
      ref: warehouse
    resources:
      - users
      - orders
    sync_mode: full
    write_mode

Then filament run users-copy. The CLI streams progress, and filament run ls users-copy shows history and checkpoints.

Step three, switch to CDC

To stream changes instead of re-reading, set replication: cdc in the source config and use merge as the write mode. Filament requires wal_level=logical and a primary key on every selected table, and by default it creates the publication with publish = 'insert, update, delete' and manages the slot name itself. Set manage_publication: false when a DBA provisions the publication.

The checkpoint timing comes from the replication modes page. Large tables are split into as many as 64 parallel ranges, and the range boundaries are frozen in the checkpoint so a resumed run reads the same plan. Steady-state CDC runs as bounded catch-up cycles, so it can sit on a cron.

What the first run produces

On the destination, Filament runs CREATE SCHEMA IF NOT EXISTS, then CREATE TABLE IF NOT EXISTS with native column types from the source schema, the source's primary key, and NOT NULL from field nullability. New source columns appear through ADD COLUMN IF NOT EXISTS, and evolution is add-only, so a replica never silently loses a column.

Every batch is verified. Per the integrity docs, "the pipeline calculates a CRC32-C checksum over the batch's Arrow buffers, its row and column counts, and its insert/update/delete operations", and the sink recalculates it at its final in-memory boundary. A mismatch fails the run. A failed or paused run then resumes from its last durable checkpoint instead of starting over, per the runs and recovery docs.

Filament vs Fivetran vs Airbyte vs Debezium for database replication

Takeaway. Each of these tools has a real strength, and each gives up something Filament keeps on this job.

Fivetran's strength is breadth and GA maturity across hundreds of connectors. Its pricing is monthly active rows, so the bill scales with the rows you replicate. On Postgres, its connector docs describe a Query-Based fallback that reads xmin and only detects deletes when a separate ctid pass is enabled. It is hosted, and Hybrid Deployment requires an Enterprise or Business Critical plan.

Airbyte has a large open connector catalog and a certified Postgres source that uses pgoutput for CDC. Its typing and deduplication layout writes raw tables and then final tables, its license is ELv2, and Cloud runs on Airbyte's infrastructure. On the cohort route it finished in 10,393 seconds, 91x Filament's time.

Debezium is a mature log-based CDC engine and is Apache 2.0. It is deployed through Kafka Connect or Debezium Server, per its architecture docs, so a replica needs a broker or a sink adapter on top. The cohort's Debezium figure measures its initial snapshot, not steady-state streaming, and that snapshot took 57x Filament's wall time.

The rest of the field has narrower fits. dlt is Apache 2.0 and code-first in Python, and it peaked at 45.54 GiB of memory on the cohort against Filament's 2.97 GiB. PeerDB is AGPLv3 by its LICENSE file, ran as seven containers in the cohort, and its README now names Postgres to ClickHouse and Postgres to Postgres as the maintained paths.

Sling gates CDC behind a Pro Max token, and Estuary Flow meters per GB plus per connector. Postgres's own logical replication is free, but its restrictions page is clear that "The database schema and DDL commands are not replicated" and "Sequence data is not replicated".

What breaks in database replication and how Filament handles it

Replication fails at the edges. These are the five that bite most teams, each with what Filament does or what you set once.

• Replication slots retain WAL until a consumer confirms it, and the Postgres docs warn that a slot nobody consumes keeps that WAL from ever being removed. Filament reports standby status every ten seconds, acknowledges only the durable cursor, and drops retired slots when a successor pipeline commits.

• Tables without a primary key have no replica identity, so Filament reads them in full through ctid and rejects them for incremental and CDC, per its source docs.

• Schema drift silently breaks replicas that map types loosely. Filament derives native destination types from the source schema and applies add-only evolution, so a new column appears and an incompatible type change fails loudly.

• Replication lag is the gap between commit and visibility, which Postgres calls "typically under one second" for a healthy standby and AWS exposes as the ReplicaLag metric. Filament's bounded catch-up cycles make lag a function of your schedule, and a zero-change run still persists the final LSN.

• Wide TOAST columns arrive without a value on unchanged updates, so set REPLICA IDENTITY FULL on those tables once, as the Filament source docs advise, and a merge sink will upsert rows it has never seen.

Which database replication tool fits which job?

How to choose a database replication tool

Pick by the constraint that breaks first. If the constraint is correctness, pick Filament, because every batch carries a CRC32-C checksum checked on both sides and the CDC baseline shares a snapshot with the stream. If it is recovery time after a failure, pick Filament, because runs resume from a durable checkpoint and the read plan is frozen.

If the constraint is where the data is allowed to travel, pick Filament, because it runs as a binary, a library, or a Helm chart inside your own infrastructure per its deployment docs.

If the constraint is throughput on Postgres to Postgres, the seven-tool benchmark and the fastest Postgres to Postgres guide show the full run data. Route guides for Postgres to Snowflake, Postgres to ClickHouse, and MySQL to Postgres walk the same five commands for each destination.

A same-engine hot standby belongs on the database's own streaming replication. A team that will not run any software itself, or one that needs a SaaS source Filament does not cover yet, will look at a hosted catalog. Filament is Apache 2.0 and is maintained by Galaxy, and the announcement post describes its deployment options and the pre-1.0 status its docs note.

Frequently asked questions

What is database replication?

Database replication is the process of copying data from one database to one or more others and keeping the copies current as the source changes. It exists for high availability, read scaling, analytics, and migration. The copy is refreshed by a full snapshot, an incremental watermark read, or a change stream from the database log.

What is the best database replication tool in 2026?

Filament is the best general tool for database replication as of September 2026. It runs full, incremental, and CDC reads from one engine and checkpoints progress so a failed run resumes. It verifies every batch with a CRC32-C checksum on both sides of the write, and it posted the fastest Postgres to Postgres result in the public benchmark cohort.

What is the difference between database replication and backup?

A backup is a point-in-time copy you restore after something goes wrong. Replication is a continuously refreshed copy you can query or fail over to right away. Postgres documents both. pg_dump makes a consistent export without blocking other users, while streaming and logical replication keep a second server current as transactions commit.

What are the three main types of database replication?

The three types most guides name are snapshot, transactional, and merge replication. In practice the useful split is physical replication, which ships byte-level changes to an identical standby, logical replication, which ships row changes by primary key, and full or incremental copies, which re-read the table. Filament covers logical CDC, incremental, and full reads.

What is the difference between synchronous and asynchronous replication?

Synchronous replication makes a commit wait until a standby confirms it received the transaction, so a failover loses nothing. Asynchronous replication lets the commit return first, so a crash can lose the transactions still in flight. Postgres streaming replication is asynchronous by default and MySQL replication is asynchronous by default as well.

How does change data capture work in database replication?

Change data capture reads the database's own write-ahead log or binary log and turns each committed insert, update, and delete into an ordered event. In Postgres a logical replication slot holds the position and the pgoutput plugin decodes rows. Filament opens the slot with an exported snapshot so the first full read and the change stream share one consistent point.

How do I replicate a Postgres database with Filament?

Install the CLI, create a source and a sink with a connection URL, run discover to list tables, then create a pipeline with a sync mode and write mode and run it. For CDC, set the source connection to cdc replication and use merge as the write mode. Filament creates the destination tables, the publication, and the slot on the first run.

Can Filament replicate deletes?

Yes. A CDC pipeline in merge mode applies ordered inserts, updates, and deletes to the destination table inside one transaction per batch, so the replica tracks current state. An incremental pipeline reads new and changed rows by a cursor such as updated_at, which cannot see a hard delete, so the Filament docs steer you to CDC whenever deletes must propagate.

Does Filament work with MySQL as well as Postgres?

Yes. The MySQL source connector reads keyset snapshots, timestamp-watermark incremental changes, and binlog CDC from MySQL 8.0 and later, and it prefers GTID positions because they survive a replica promotion. Filament also writes typed tables to MySQL, and the same pipeline definition works for Postgres, ClickHouse, Snowflake, Iceberg, and S3 sinks.