Skip to main content
Menu

Product

One command moves a production database

Dsync runs a parallelized initial copy, transitions into change data capture without a gap, verifies integrity as it goes, and hands you a cutover with no downtime. It runs in your own infrastructure and persists nothing outside it.

How it works

Three phases, one command

dsync $SOURCE $DESTINATION
  1. 01

    Parallelized, resumable initial copy

    • 10–100× faster than DIY scripts or general-purpose ETL
    • Resumes from its last checkpoint instead of starting over
    • Progress, throughput and lag from the CLI or the web UI
  2. 02

    Real-time incremental sync and CDC

    • Sustains 1000+ operations per second on active workloads
    • Takes over from the initial copy without a gap or a freeze
    • Reconnects and resumes on its own after an interruption
  3. 03

    Verified cutover

    • Integrity checks run as the data moves, not once at the end
    • Evidence the two sides match before you commit
    • Back out by reversing direction, not by restoring a backup

Architecture

Dsync is a single binary. It connects directly to the source and the destination and moves data between them — there is no broker, no staging bucket and no SaaS tier in the data path. That is the whole architecture, and it is deliberate: every hop you add is another place data can be lost, retained, or subpoenaed.

Internally it runs two coordinated pipelines. The initial-copy pipeline partitions the source and reads partitions in parallel, checkpointing as it goes so an interruption resumes rather than restarts. The change-data-capture pipeline tails the source's native change stream from a position recorded before the copy began, so nothing that happened during the copy is lost. When the copy finishes, CDC is already caught up and the two sides converge.

Verification runs alongside both, comparing source and destination continuously rather than once at the end. Because the pipelines are symmetric, reversing source and destination is a supported operation — which is what makes the back-out a reversal instead of a restore.

dsync --progress --logfile dsync.log $SOURCE $DESTINATION

The quickstart in full, including a public read-only demo instance to try it against, is in the documentation.

10–100×
Faster than DIY scripts and SaaS ETL
100 TB
HBase to MongoDB in under 48 hours
1000+
Operations per second sustained during CDC
Zero
Downtime cutover

Benchmarks

We published our methodology and results against Fivetran, Airbyte and Estuary rather than asking you to take the numbers on trust.

Read the benchmark

Methodology, the datasets used, where each tool was faster or slower, and the cases where we lost. Reproducible against your own data.

Read the results

100 TB in under 48 hours

How we moved 100 TB and 100+ billion records from HBase to MongoDB while the source kept serving production traffic.

Read the write-up

See it running

What a migration actually looks like

Not a mockup. The command line, the web UI and the integrity check, from a real run.

The dsync command-line interface during a migration, showing per-collection progress and throughput.
Command line — progress, throughput and lag per namespace, live.
The dsync web interface showing a running migration with source, destination and status.
Web UI — the same run, for people who are not in a terminal.
The dsync data integrity check comparing record counts and contents between source and destination.
Integrity check — evidence the two sides agree, before you cut over.

Supported systems

Connectors are source and sink unless noted, so a path usually works in both directions. If what you need is not here, ask — the adapter framework covers proprietary and niche systems.

Built for production, not for a demo

  • Runs anywhere — a VM, your laptop, or your Kubernetes cluster
  • No SaaS tier in the data path and no Kafka to operate
  • Resumable at any stage, during initial sync or during CDC
  • Credentials stay in your secret store and never transit ours
  • No transient data persisted anywhere outside your control
  • Structured logs that fit the monitoring you already run

Pricing

Open Source

Great for small projects and testing

  • Free forever
  • Best-effort community support
  • Commercial support add-on

Enterprise

Best for enterprises and mission-critical use cases

  • Annual or monthly agreement
  • Commercial support
  • Roadmap prioritisation
  • Customization

What teams say after the cutover

  • Adiom provided key capabilities that helped Zendesk accelerate the redistribution of accounts across our data centers with minimal downtime. Working with them felt like having them as part of the team, and it was clear they were invested in our success.”
    Principal Software DeveloperZendesk
  • “The Adiom components, particularly dsync, worked extremely well for us and gave us all the peace of mind to confidently proceed with the cutover.”
    VP Product and Data PlatformCatalina Marketing
  • “We utilized dsync to handle the migration of two production databases from Cosmos DB to MongoDB. The tool was incredibly efficient, allowing us to bypass the manual overhead of writing custom migration logic. It delivered exactly what was promised: speed, reliability, and risk elimination. I highly recommend it to any team looking to streamline their data synchronization.”
    Senior EngineerMultinational retail and finance company
  • “Don’t even attempt to do your own thing. Just use Dsync.
    Engineering Site LeadRox.com

1 / 4

Frequently asked questions

What makes dsync special?

Dsync is built specifically for moving production data between databases, not for general-purpose ETL. It runs as a single command, parallelises and resumes the initial copy, transitions seamlessly into change data capture, and verifies integrity as it goes. It persists no transient data, so your data stays with you.

How does dsync compare to Fivetran, Airbyte, and other SaaS ETL tools?

Those tools are built for analytics pipelines into a warehouse, and price by rows moved. Dsync is built for operational cutover between live databases, runs inside your own infrastructure, and is optimized for throughput and resumability rather than for scheduled batch loads.

How does dsync compare to Kafka or Debezium?

Kafka and Debezium are components you assemble into a migration. Orchestrating the initial snapshot against the change stream, handling resumption, and verifying the result is weeks to months of work you own. Dsync is that system, already built.

Why not just write my own custom code for migration?

Teams usually can. What they underestimate is the long tail: resumability after a failure mid-copy, throughput on a 100GB+ dataset, keeping CDC in step with the snapshot, and proving the result matches. That is where the months go.

Is Dsync open source?

Yes. Dsync is open source and free to use, with best-effort community support. Commercial support is available as an add-on.

Does Adiom offer commercial support?

Yes. Dsync Enterprise adds commercial support, roadmap prioritisation and customization, on an annual or monthly agreement, and is available on the Azure Marketplace.

More on what Dsync does

Talk to an engineer

Tell us the source, the target and the deadline. You will get a straight answer about what the migration involves.

We reply within one business day. Your details are handled per our privacy policy.