Skip to main content
Menu

DynamoDB to Cosmos DB

No-downtime migration from DynamoDB to Azure Cosmos DB

Use Dsync to move from DynamoDB to Cosmos DB for NoSQL while production keeps running. Realize the benefits of Cosmos DB and the Azure ecosystem in minutes rather than months.

Book a free assessmentTry Dsync

What actually changes between DynamoDB and Cosmos DB for NoSQL

The two databases look alike from a distance — key-value access, JSON-shaped items, partitioned storage — and differ in the places that hurt during a migration. DynamoDB exports are either a full table scan, which is slow and consumes read capacity at production scale, or a point-in-time export to S3 that gives you a snapshot with no way to catch up afterwards. DynamoDB Streams close that gap but retain only 24 hours of changes, so the initial copy has to finish inside that window or the migration silently loses writes.

On the Cosmos DB side the decision that cannot be undone is the partition key. It is immutable once a container exists, it determines both the 20 GB logical-partition ceiling and how request units are spread across physical partitions, and the natural DynamoDB key is not always the right choice — high-cardinality tenant workloads often want a hierarchical key instead. Throughput has to be provisioned ahead of the copy so Cosmos DB creates partitions before ingestion rather than during it, and the item model changes shape: items are converted to JSON documents, and the 400 KB item limit becomes a 2 MB document limit.

Dsync handles the time problem by being fast: a parallel, checkpointed scan moves tens of terabytes in 24 hours, so the copy finishes well inside the stream's retention and the changes made during it are then applied from the stream. It leaves the design decisions to you, with the data to make them. Progress, lag and per-table state are visible in the CLI and web UI while it runs, verification compares both sides continuously, and the cutover is a connection change once they match. The white paper linked below examines the DynamoDB path in more depth.

Why DynamoDB to Cosmos DB is harder than it looks

The usual approach

  • Table scans for export are slow and expensive at production scale
  • Streams-based DIY needs orchestration against the initial snapshot
  • Provisioned capacity makes a big copy either slow or costly
  • No straightforward way to prove the two sides match before cutting over
  • DynamoDB Streams keep 24 hours of changes, so a copy that runs longer than a day loses writes

With Dsync

  • The table stays live and serving traffic for the whole migration
  • A parallel, resumable scan moves the initial copy at a load level and write rate you set
  • The copy moves tens of terabytes in 24 hours, well inside the stream's retention, then applies the writes made during it
  • Items are mapped to Cosmos DB for NoSQL documents with the partition key chosen up front, not discovered later
  • Both sides are compared before cutover, and reversing direction is the back-out

How the migration runs

dsync $DYNAMO $COSMOS
  1. 01

    Parallelized, resumable initial copy

    • 10–100× faster than scripts
    • Resumes from checkpoint
    • Bounded source impact
  2. 02

    Real-time incremental sync and CDC

    • 1000+ ops/sec on active workloads
    • Automatic resume after interruption
    • Seamless handover from the copy
  3. 03

    Verified cutover

    • No downtime out of the box
    • Embedded integrity checks
    • Back out by reversing direction

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.

Proof

“Don’t even attempt to do your own thing. Just use Dsync.”
Engineering Site LeadRox.com

DynamoDB to Cosmos DB migration questions

Does the DynamoDB table stay online during the migration?

Yes. The initial copy is a parallel scan at a read rate you set, and DynamoDB Streams record every write made while it runs, which Dsync applies once the copy is done. The application keeps using DynamoDB until cutover, which is a connection change on your side.

How is the 24-hour retention of DynamoDB Streams handled?

By finishing the copy well inside it. Dsync's parallel scan moves tens of terabytes in 24 hours, so for most tables the initial copy is done in hours, and the writes recorded in the stream during that time are applied afterwards. The stream has to be enabled before the copy starts; for exceptionally large tables we size the load level on the assessment call so the copy fits the window.

How do DynamoDB items map to Cosmos DB documents?

Items are converted to JSON documents, and the Cosmos DB partition key is chosen by you up front — usually the DynamoDB partition key, sometimes a hierarchical key for multi-tenant tables. The mapping is reviewed on the assessment call, because the partition key cannot be changed after the container is created.

Will the copy consume our provisioned read capacity?

Only as much as you allow. Dsync's load level sets the number of reader threads, and a write rate limit on Cosmos DB throttles the DynamoDB scan through back-pressure, so the copy can run at a rate that leaves headroom for production or, for on-demand tables, at whatever rate the cost allows. The one limit is the stream's 24-hour retention: the copy has to finish inside it, which at tens of terabytes a day leaves room to throttle for most tables.

Do we have to pre-provision throughput on Cosmos DB?

We recommend it. Provisioning request units before the copy makes Cosmos DB create physical partitions ahead of ingestion instead of splitting them under load, which is faster and avoids throttling during the copy. It can be scaled back down once the migration is complete.

What does verification and back-out look like?

Verification is a flag. A quick mode compares document counts per table, and a full mode reads every item and compares hashes, so you choose the level of evidence before you cut over. If you need to return to DynamoDB afterwards, the same command with the reverse flag starts a change-data-capture flow from Cosmos DB back to DynamoDB, which is why we suggest keeping the table for a defined period rather than deleting it on day one.

More on DynamoDB and Cosmos DB

Free migration assessment

Tell us your table layout and target, and we will map the path.

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