Point data leaves a cluster in two ways with QQL, and a third way with Qdrant itself. Pick the path that matches the job.
| Job | Tool | What moves |
|---|---|---|
| Back up one collection to a reviewable file, or carry it to another cluster by hand | Dump and restore | Schema plus points as a .qql script |
| Copy schema plus points to another cluster or collection, reshape shards or quantization in flight, then cut traffic over | Cluster migration | Schema plus points over scroll and upsert |
| Move an existing REST integration to QQL, or see what an SDK call looks like as a statement | Convert REST JSON | One request (or a captured session) as QQL |
| Disaster recovery on identical versions, or an identical-version clone | Qdrant native snapshot | Raw segment files, byte for byte |
Rules of thumb:
- Use dump when you want a file you can read, diff, edit, and replay with
qql run. Use migrate when you want the tool to drive both ends and verify counts for you. - Use convert when the starting point is an existing application rather than a data copy:
qql recordcaptures what it sends,qql convertturns that into QQL. - Use a native snapshot when the source and target run the same minor version, keep the same shard count, and need the fastest possible restore. Snapshots cannot change versions, shard counts, or quantization. Migrate can.
- Never replay a dump or run a migration against a collection that is still receiving writes unless you have a plan for write drift. Multi-hour copies without change capture miss late writes.
Related references: CLI, Multitenancy.