Know the Time Before You Run the Migration
Database migrations get riskier as your tables grow. A simple ALTER that only adds a column usually holds locks briefly and can process tens of thousands of rows per second. Migrations that transform or copy existing data, on the other hand, put much more pressure on transaction logs and disk I/O, so throughput drops sharply. Rebuilding indexes or rewriting an entire table is the most expensive case of all, with heavy lock contention and resource usage — which is exactly why estimating the time upfront, and deciding whether you need a downtime window, matters so much.
This calculator estimates total time from your row count, the throughput profile of your migration type, and how many parallel workers you'll run. Real production environments add variables — server specs, network latency, lock contention with other queries — so the result includes a 10% safety buffer on top of the raw math. If the estimate crosses an hour, it's safer to schedule the run for low-traffic hours or prepare a maintenance notice in advance.
For large tables that can't tolerate downtime at all, look into online schema change tools like gh-ost or pt-online-schema-change. They copy data into a shadow table and swap it in atomically, keeping the original table live and minimizing service disruption.
Frequently Asked Questions
Increasing parallel workers, or rebuilding indexes after the migration instead of during it, can significantly cut batch processing time.
Online schema change tools like gh-ost and pt-online-schema-change let you migrate large tables while the service keeps running.
Yes. Server specs, lock contention, and network conditions can push the real migration time past the estimate, so plan extra buffer.