Move database data
3 minute read · SQL Client
Move the data you actually need, in a format the receiving tool can use. Start by naming the source, destination and scope so you do not confuse a development copy with a live database.
- Export a useful, bounded copy
- Import without confusing the target
- Keep exported data private
- Choose export options for the receiving tool
Export a useful, bounded copy
Choose the intended connection and tables, then select SQL, CSV or JSON according to how the result will be used. SQL can include structure and content; CSV/JSON suit selected data workflows. Review available options for DROP statements, auto-increment handling, BLOB encoding and batches before starting.
For large exports, use the supported concurrency and low-memory options and inspect per-table/worker progress. Compression, delimiter, BOM and filename tokens affect how another tool reads the result. A password-protected .vtxp export uses its own encryption path; keep the password separately from the file.
Start with a small fictional table. Open or import the output into a disposable database to verify encoding, column names and row count before relying on a large backup. Creating a file is not proof that every intended table was exported.
Import without confusing the target
- Choose an isolated destination and confirm its host/database name.
- Inspect the input format and whether it contains schema or destructive DROP statements.
- Start the supported import worker/CLI path and watch its progress.
- Read errors and cancellation state; a partially completed import is not a successful complete restore.
- Query the destination and verify both the data and the app behavior that uses it.
Do not test an unfamiliar import against the database you are currently developing or operating. An import can commit some work before a later statement fails; cancellation should not be assumed to roll everything back.
Keep exported data private
Exports and query results can contain secrets and personal information even when the saved connection password remains encrypted. Choose an authorized destination and sharing method. Record the engine/version and relevant export options when compatibility matters. For schema context, see structure and diagrams.
Choose export options for the receiving tool
| Need | Useful choice |
|---|---|
| Recreate tables and example data | SQL with reviewed structure/content options. |
| Open selected rows in a spreadsheet | CSV with a delimiter, encoding and optional BOM accepted by that application. |
| Inspect data in another program | JSON with a shape the receiving program can read. |
| Move a large dataset | Review compression, batch size, concurrency and low-memory settings; watch per-table progress. |
| Protect an export at rest | Use the offered password-protected .vtxp path and store its password separately. |
BLOB handling, DROP statements and auto-increment options affect restorability. Record those choices with the export. When an import is interrupted, inspect which tables and rows arrived before repeating the file. A fresh disposable destination is usually a clearer validation target than importing twice into an unknown partial state.
Related guides: connections, schema inspection.