Classic Bulk Load Migration

A Classic Bulk Load Migration is the simplest way of . In this approach, you stop application traffic to the source database and migrate data to the target cluster using during a significant downtime window. Application traffic is then cut over to the target after schema finalization and data verification.

• All source data is migrated to the target .

• This approach does not utilize .

• is manual, but in most cases it’s simple, as the source database is preserved and write traffic begins on the target all at once. If you wish to roll back before the target has received any writes that are not present on the source database, nothing needs to be done. If you wish to roll back after the target has received writes that are not present on the source database, you must manually replicate these new rows on the source.

This approach is best for small databases (<100 GB), internal tools, dev/staging environments, and production environments that can handle business disruption. It’s a simple approach that guarantees full data consistency and is easy to execute with limited resources, but it can only be performed if your system can handle significant downtime.

This page describes an example scenario. While the commands provided can be copy-and-pasted, they may need to be altered or reconsidered to suit the needs of your specific environment.

Example scenario

You have a small (50 GB) database that provides the data store for a web application. You want to migrate the entirety of this database to a new CockroachDB cluster. You schedule a maintenance window for Saturday from 2 AM to 6 AM, and announce it to your users several weeks in advance.

The application runs on a Kubernetes cluster.

Estimated system downtime: 4 hours.

Step-by-step walkthroughs

The following walkthroughs demonstrate how to use the MOLT tools to perform this migration for each supported source database:

For CockroachDB-to-CockroachDB migrations, contact your account team for guidance.

See also