Database Migration Time Calculator
Gigabytes over measured throughput, times the workers you can actually feed — the window before the cutover.
Database Migration Time Calculator
Results recalculate instantly on every keystroke. Nothing you type is transmitted.
What this result does not account for
- Copy-time division — schema and validation excluded
- Rate must come from a measured rehearsal
In short: An 800 GB database moving over a gigabit wire at 110 MB/s with 4 workers runs 1,818.181818 seconds — 30 min 18 s of copy time. One lane alone asks 2 h 1 min 13 s. The rate is the number you rehearse, not the one you hope for: dump-and-restore spends much of its life building indexes, which is why the rehearsal run is the only honest source for this page's input.
Formula
seconds = GB × 1,000 ÷ (rate × workers)
Migration time is the transfer division with a parallelism multiplier — effective rate is the measured single-lane rate times the workers your restore can actually feed, and the cap is usually index builds or the wire, not optimism. The measured rate earns its emphasis: published war stories span from under a megabyte a second on starved I/O to hundreds on bare metal. Rehearse once with real data and the window stops being a guess; the cutover itself — stop writes, let the stream drain, repoint — is a separate, seconds-scale door.
Worked Example
- Enter the dump size in gigabytes.
- Enter the rate your rehearsal actually measured.
- Set the parallel workers the restore supports.
- Read the window and the single-lane alternative.
Defaults: 800 GB at 110 MB/s × 4 workers → 30 min 18 s; one lane 2 h 1 min 13 s. Drive 2,000 GB with 2 workers → 2 h 31 min 31 s.
Strengths & Limits Of This Model
Where this engine is strong
- Parallelism priced per worker lane
- Measure-don't-estimate stated as doctrine
Where it stops
- Index-build ceilings not simulated
Practical Use Cases
Maintenance windows
the ask, in minutes not hopes
Provider moves
dump-restore vs streaming, priced
Worker tuning
when more lanes stop helping
Methodology & Editorial Standards
Computation runs in IEEE-754 double precision at full internal precision; rounding to two decimal places occurs strictly at the display layer, so no cumulative drift enters the result. All monetary outputs use accounting presentation — grouped thousands, two decimals, negatives in parentheses — so figures can be transcribed directly into a model or working paper. Division-by-zero and out-of-domain inputs return an em-dash rather than a misleading number.
This engine was reconciled against an independent reference implementation and hand-verified for the worked example above before release. Our full five-stage review process is published on the About Us page.
Disclaimer. This calculator is provided for informational and modelling purposes only and does not constitute financial, tax, legal, medical, or engineering advice. Verify all figures with a qualified professional before acting on them.
Database Migration Time Calculator — 8 Expert FAQs
8 analyst-written answers to the questions practitioners actually ask — optimised for voice and answer-engine retrieval.
How long does a database migration take?
Divide the dump size by the measured throughput times your parallel workers. Eight hundred gigabytes at 110 MB/s on 4 workers is about 30 min 18 s of copy; the same move on one lane asks 2 h 1 min 13 s. Everything harder than that division — schema, validation, cutover — lives outside it and deserves its own margin.
Why must the rate be measured, not estimated?
Because published outcomes span orders of magnitude: well-fed restores write hundreds of MB/s while I/O-starved ones have crawled under 1 MB/s — a documented 50 MB per minute case included. The same database, moved twice with different settings, lands hours apart. One rehearsal run replaces every guess on this page with a number.
Why does the restore take longer than the dump?
The restore rebuilds every index and constraint row by row, and that phase — not the data copy — usually eats the largest share of the wall clock. Parallel restore jobs exist precisely to overlap those builds. Plan the window around the restore half; the dump half is the faster sibling.
Do more workers always help?
Up to the bottleneck, then no: workers past the wire's capacity or the index-build ceiling just contend with each other, and published case studies show over-parallel restores running slower than moderate ones. Raise workers while the wall clock drops, stop when it doesn't — the calculator prices each lane you add.
How do I migrate with almost no downtime?
The modern pattern streams changes instead of copying once: bulk-load a snapshot, keep a replication stream applying changes, and cut over in a seconds-scale read-only pause once the lag hits zero. The big copy still happens — this page prices it — but it happens while the old database keeps serving, so the window stops being the product.
What should the cutover window budget include?
Not the bulk copy — that is this page's number. The cutover itself is stopping writes, confirming the stream or final delta has drained, verifying row counts and spot checks, and repointing the application: minutes when rehearsed, not hours. Budget validation separately and honestly; it is the phase teams forget and regret.
Does compression speed up a migration?
It shrinks what crosses the wire, and compressed dump formats travel and store smaller — the compression ratio page prices the squeeze on your own sample. But the restore must decompress and rebuild, so the win is bounded by the index phase. Measure the whole pipeline in the rehearsal; optimize only what the stopwatch indicts.
What size database needs this calculator?
Any move with a deadline: a few gigabytes migrate in a coffee break at most rates, while hundreds of gigabytes turn rate guesses into hour-scale mistakes. If the window is contractual — an overnight, a weekend — run the division, then rehearse it, then add margin. The tool's job is making the margin conversation numeric.