Skip to documentation
OriginChainDB Docs
Ask the docs

OriginChainDB / Guides

Move data with Migrate

Review your data, copy it into OriginChainDB, and use live sync for a supported PostgreSQL or MySQL source before switching your application over.

Choose a source

Open your instance, then Platform → Migrations → Data migration. Supported sources include PostgreSQL and CockroachDB, MySQL and MariaDB, SQL Server, MongoDB, and S3-compatible object-storage files in CSV, TSV, JSONL or JSON-array format, including gzip-compressed data.

For MongoDB, include the database name in the connection string; both mongodb:// and mongodb+srv:// forms are accepted. A one-time copy reads selected source data. Live migration also needs source replication access: PostgreSQL creates a replication slot and publication while sync runs. Neither workflow changes your source rows.

Review the plan before approving

  1. Source: provide the source connection and destination namespace. Choose whether to allow masked samples for type detection. With samples off, analysis reads the structure only.
  2. Review: choose the objects to include, inspect destination names and field types, review primary keys, and resolve conversion or naming warnings.
  3. Enhance: review full-text fields and graph mappings. Full-text fields can be added to tables with composite primary keys. Edge-table mappings turn each source row into an edge. Foreign keys to unique non-primary columns can also become relationships for PostgreSQL, CockroachDB, MySQL and SQL Server, when the destination target has a single-column primary key. Check the proposed mapping before approving.
  4. Approve: confirm the reviewed plan. Previously approved plans keep their original definitions; start a new migration to use changes to planning behavior.
  5. Move: follow copied and set-aside counts, inspect problems and review the verification result.

Optional source settings include treating MySQL zero dates as empty values and a SQL Server certificate-trust option. Review their effect before enabling them; these are choices for the source connection, not required defaults.

Check data without copying it

Use Check data to find values that do not fit the plan before a move. The check does not write to the destination. It is also available after a failed or cancelled move. When masked samples are disabled, reported reasons identify the column and problem without showing values.

Understand a partial result

The default “If a value can’t be moved” choice sets that row aside and continues. You can instead choose Stop the table. A table with set-aside rows is partial, not Verified. Review the recorded reasons and counts rather than treating a completed copy as proof that every row arrived.

After fixing source values, manually retry set-aside rows for supported PostgreSQL, CockroachDB, MySQL and SQL Server tables with usable primary keys. Retry adds missing rows without overwriting existing records. It is not automatic and is unavailable for MongoDB and file sources.

Optionally embed selected rows

With a tested saved embedder, select the text columns in the order to combine them and the conditions for rows to embed. All selected source rows still move; only matching rows are embedded. Set the required maximum number of rows to embed and review the provider’s data handling. See saved embedders and embedding runs.

Keep copying changes until switchover

  1. For a supported PostgreSQL or MySQL source, choose the live migration option offered by the console. Meet its replication prerequisites before starting; ordinary read access alone may be insufficient.
  2. Allow the initial copy to finish, then watch Estimated lag, Changes applied and Last applied. A busy MySQL source can accumulate lag. A disconnected or stalled stream needs attention even if the initial copy completed.
  3. Pause application writes to the source before choosing Switch over. Follow the confirmation shown by the console and keep writes paused while it finishes applying changes and recounting the tables.
  4. Review every recounted table result and any set-aside rows. Only then point your application at OriginChainDB and verify its reads and writes.

Stop syncing ends synchronization and keeps copied destination rows. Starting sync again requires a new live migration. If source cleanup is pending, follow the displayed instructions until the replication slot is released; do not assume that cancelling the copy has cleaned up the source. Live sync is a migration workflow, not permanent bidirectional replication.

Follow the workflow

Watch the migration workflow overview. The video may predate newer source options; use this guide and the current console for availability. The migration FAQ explains common row and mapping questions.