Skip to content

Qdrant vector store migration plan for the self-host GPU host migration #4329

Description

@JSONbored

Part of #4325.

Context

When --profile qdrant is active, RAG retrieval reads from Qdrant instead of the built-in pgvector/sqlite-vec path. Qdrant ships a native snapshot API, which should be preferred over re-embedding everything from scratch on the new host (re-embedding the full corpus is strictly more expensive and slower than restoring a snapshot).

Requirements

  • Use Qdrant's own snapshot/restore mechanism (collection snapshot → transfer → restore on the new host), not a from-scratch reindex, as the primary path.
  • Verify collection point-count and a small sample of vector IDs match between source and restored collection.
  • Decide, and write down, whether a from-scratch reindex (the rag-index-repo job, src/review/rag.ts) is an acceptable fallback if snapshot restore has problems — don't leave this as an unstated assumption.

Deliverables

  • Snapshot taken from the current host's Qdrant instance and restored on the new host
  • Point-count parity confirmed between source and destination collections
  • Sampled vector-ID spot check confirms restored vectors match source (not just counts)
  • Fallback decision (reindex vs. snapshot-only) documented

Expected outcome

The new host's Qdrant is byte-for-byte equivalent to the current host's at time of snapshot, with a documented, deliberate answer for what happens if it isn't.

Effort

S

Metadata

Metadata

Assignees

Labels

maintainer-onlyOwner-only work — yields no Gittensor points.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions