Need to migrate from one database to another without downtime?

Photo by freestocks on Unsplash.

Need to migrate from one database to another without downtime?

Dual writes are one approach that deserves more attention.

Most database migrations fall into one of a few buckets:

• Export and import

• Replication between two databases

• Services specifically built to synchronize data

All of those approaches can work well. But sometimes you need both databases active while gradually migrating traffic from one to the other.

That’s where dual writes become interesting.

The idea is exactly what it sounds like. Every write is sent to both databases.

Insert a row? Write it twice.

Update a record? Update it twice.

Delete something? Yup, delete it twice.

The goal is to keep the old and new databases synchronized while both are active.

The most common approach is implementing dual writes directly in the application.

Instead of maintaining one database connection pool, the application maintains two and executes write operations against both systems.

In some cases, infrastructure can help as well.

For example, Envoy supports request mirroring patterns that can be useful when migrating certain technologies, such as Redis.

The implementation will vary, but the concept remains the same: each write is performed twice.

The hard part is not writing twice, but rather handling partial success.

What happens when Database A succeeds, but Database B fails?

Now the two databases disagree.

Do you retry? Can the operation be safely retried?

Can you roll back the successful write?

Do you have locking or reconciliation mechanisms?

This is where dual writes become significantly more complex than they initially sound.

Writing twice is easy. Maintaining correctness is the hard part.

Dual writes tend to work best when:

• Updates occur frequently

• Eventual consistency is acceptable

• Reconciliation processes exist

• Future updates naturally correct drift

They become much harder in systems that require strict consistency guarantees for every operation.

Despite the complexity, dual writes enable a powerful migration approach.

You can:

• Introduce a new database platform or table

• Keep it synchronized with the old platform

• Gradually migrate read traffic

• Eventually retire the old database

All without requiring a large downtime window.

Like most migration strategies, dual writes are a tradeoff.

They add complexity.

But they also enable something extremely valuable: migrating between database platforms while the system remains live.

When downtime is not an option, dual writes can be one of the most powerful migration techniques available.

Originally posted on #Bengineering.

If this hit home, share the original with someone who needs it: Need to migrate from one database to another without downtime?

• Glue Services: Part Two — Data Synchronization
  A useful companion on keeping old and new systems aligned during gradual platform change.

• When modernizing legacy systems, don’t be afraid to build glue services
  Edge translation and isolation patterns pair well with migration-focused architecture decisions.

• YOLO Is a Terrible Strategy for Validating Production Changes
  Operational changes get safer when validation and rollout discipline are part of the design.

• Coding agents can’t see your architecture diagrams—fix that
  Systems thinking improves when design context stays readable, versioned, and close to the code.

• In-Flight Request Tracking: Lessons from Card Payments and HTTP/2
  A deeper look at uncertainty, timeouts, and correctness when distributed requests do not complete cleanly.

• Are Atomic Operations Faster and Better Than a Mutex? It Depends
  A practical reminder that simpler-looking performance choices still need correctness tradeoff analysis.