Migration and Recovery Options

Qdrant gives you three mechanisms for moving or recovering data, each suited to a different scenario. The right choice depends on what you’re migrating from, whether you need to change the shard count, and whether you’re on Qdrant Cloud.

Quick guide:

  • Use the Qdrant Migration Tool when moving data from other vector search engines (for example, from Pinecone, Weaviate, or Chroma) to Qdrant, when you need to change shard counts, or migrate a subset of data.
  • Use Snapshots when moving a Qdrant collection between environments (for example, self-hosted to Cloud) and you want to skip re-indexing by transferring the existing index.
  • Use Cloud Backups for full cluster failure recovery or reverting a cluster to a previous state. This is the fastest restore option when you’re on Qdrant Cloud.

Qdrant Migration Tool

The Qdrant Migration Tool streams points from a source database directly to a target Qdrant cluster over the network. Because data arrives as individual upserts, Qdrant builds the HNSW index from scratch. This is the slowest option for indexing but the most flexible in terms of source system and target shape.

When to use it: Migrating from any of the supported sources, including other Qdrant clusters; changing the number of shards; or migrating a filtered subset of vectors.

See the Data Migration tutorial for step-by-step instructions.

Snapshots

Snapshots are tar archives of a collection’s data and its pre-built index. Restoring a snapshot to a new cluster skips the indexing phase entirely, which can save hours on large collections.

When to use it: Moving a Qdrant collection between environments (for example, self-hosted to Cloud, or Managed Cloud to Private Cloud). Snapshots also let you restore collections to a known-good state after accidental deletion, data corruption, or a failed data update.

The target cluster still needs approximately two times the collection’s disk size during the restore window, because the snapshot file and the restored collection exist simultaneously on disk until the restore is complete.

The target cluster must match the source cluster’s minor version, or be at most one minor version higher. For example, you can restore a 1.17.1 snapshot to a 1.18.1 cluster, but not a 1.16.0 snapshot.

See Snapshots for API reference and storage options, or the Backup & Restore Qdrant with Snapshots for a walkthrough.

Cloud Backups

Cloud Backups work at the disk level: the storage volumes your Qdrant cluster runs on are snapshotted, without Qdrant reading or transferring any data. This makes it the fastest option.

When to use it: Recovering from a full cluster failure, or reverting a cluster to a known-good state after a bad deployment or data corruption. The restore is constrained to the same cloud provider, same region, same Qdrant version, and same cluster shape.

See Backing up Qdrant Cloud Clusters for setup and restore instructions.

Comparison

The following tables compare the three options across key dimensions to help you choose the right approach for your migration or recovery needs.

Overview & Use Case

A high-level look at what each option does, the scenario it’s designed for, and the granularity at which it operates.

Migration ToolSnapshotsCloud Backups
DescriptionStreams collection data to targetCaptures collection data/stateBacks up volumes using CSI snapshots
When to useMigrations from other systems, shard changesCollection migrations, recoveryFull failure recovery, cluster reversion
ScopePer collection (optional filter)Per collection or shardEntire volume

Performance & Cost

How each option handles indexing on the target, data transfer speed, network cost, and load placed on the source cluster.

Migration ToolSnapshotsCloud Backups
Indexing on targetFull re-index (slow)None (index transfers with data)None (direct disk clone)
SpeedModerateFastVery fast
Network costMedium (potential cloud egress from streamed data)High (potential cloud egress)High / None (stays within region)
Impact on sourceMedium-High (CPU/IO intensive)Moderate (CPU/IO)Minimal (handled by storage)

Operations & Mechanics

How much effort each option requires, which APIs or tools you’ll use, and where data lands during the operation.

Migration ToolSnapshotsCloud Backups
Operational effortModerate (CLI setup)High (per-node API scripting)Low (automated, cluster-wide)
API / toolingCLI ToolQdrant REST APICloud infrastructure
Source availabilityMust be online throughoutOnline during snapshot creation only; not required for upload or restoreNot required
Snapshot locationN/AExternal (S3 or compatible)Cloud infrastructure
Restore targetAny existing clusterAny existing clusterRestore within same region

Infrastructure Limits

Constraints on source system, target cloud, cluster shape, and Qdrant version compatibility.

Migration ToolSnapshotsCloud Backups
FlexibilityHighModerateLow
Source systemSupported SourcesQdrant clusterQdrant on compatible cloud infra
Target cloudAnyAnySame cloud provider only
Target cluster shapeFlexibleModerate: same shard countStrict: same config & node count
Target Qdrant versionAnySame or newerExact same version

Resource Requirements

Disk and RAM headroom needed on the target cluster, and how each option handles an interrupted operation.

Migration ToolSnapshotsCloud Backups
Target disk headroom2× source2× source≥ source size
Target RAM headroom2× sourceSame as sourceSame as source
Resilience to interruptionCheckpoint resumeAtomic restoreAtomic clone

“Source” refers to actual collection usage, not provisioned capacity. Check your current usage in the Web UI or via the API.

Was this page useful?

Thank you for your feedback! 🙏

We are sorry to hear that. 😔 You can edit this page on GitHub, or create a GitHub issue.