Vector database migrations that keep your search quality intact.
Zero-downtime migrations between Pinecone, PGVector, Weaviate, Qdrant, Chroma, and Milvus. Embedding re-index, dual-write cutover, retrieval-quality regression tests. £8K audit + fixed migration price.
What is vector database migration?
A vector database migration is the process of moving a production vector index (embeddings + metadata + retrieval logic) from one vector database to another without losing search quality or breaking downstream RAG pipelines. In 2026, the most common paths are Pinecone → PGVector (cost + open-source), Pinecone → Qdrant (self-host + better filtering), Weaviate → Chroma (simplicity + Python-native), and any-of-the-above → Milvus (enterprise scale). Empyreal Infotech runs a fixed £8K, 5-day audit that maps your current schema, benchmarks retrieval quality on your real queries, models the target-database schema, and writes six ADRs including the cutover strategy. Migration itself ships against a fixed quote, uses dual-write for zero downtime, and includes retrieval-quality regression tests so you can prove search hasn't degraded before you finalise the cutover.
What you get, every engagement.
Every major vector DB
Pinecone, PGVector (Postgres), Weaviate, Qdrant, Chroma, Milvus, LanceDB. Migrations in both directions between any pair. We don't advocate for one — the audit picks the target based on your traffic, cost, and self-host requirements.
Retrieval-quality regression tests
Every migration ships with a retrieval-quality eval harness: your real queries, top-k results from old vs new DB, cosine-similarity + recall@k measured, threshold gates in CI. You literally cannot ship the cutover if search quality regressed.
Zero-downtime dual-write cutover
Dual-write pattern: new writes go to both DBs during migration. Reads switched to the new DB by traffic percentage (canary at 5% → 25% → 100%). Rollback path stays live for 30 days post-cutover. Your users see nothing.
Embedding + metadata preservation
Full re-index of every embedding with the same model + dimensions the old DB used, or opportunistic re-embed if you want to upgrade to a newer embedding model as part of the migration. All metadata (namespaces, tenants, custom filters) preserved.
The vector database migration engagement, week by week.
- 01
Inventory the current index (size, embedding model, metadata, query patterns). Benchmark retrieval quality on 200-500 real production queries. Model the target-DB schema. Write six ADRs including the cutover strategy and rollback plan.
Audit week (£8K). Inventory the current index (size, embedding model, metadata, query patterns). Benchmark retrieval quality on 200-500 real production queries. Model the target-DB schema. Write six ADRs including the cutover strategy and rollback plan.
- 02
Provision the target DB, write the schema, wire the dual-write middleware, ship the migration script for the initial backfill. Retrieval-quality regression harness deployed to CI.
Schema + tooling. Provision the target DB, write the schema, wire the dual-write middleware, ship the migration script for the initial backfill. Retrieval-quality regression harness deployed to CI.
- 03
Backfill runs (typically 2-24 hours for indexes under 10M vectors). Retrieval-quality eval runs. Any regression flagged before cutover starts.
Backfill + validation. Backfill runs (typically 2-24 hours for indexes under 10M vectors). Retrieval-quality eval runs. Any regression flagged before cutover starts.
- 04
Traffic-percentage cutover: 5% → 25% → 100% over 5-7 days with per-canary quality checks. Rollback path stays live for 30 days.
Canary + cutover. Traffic-percentage cutover: 5% → 25% → 100% over 5-7 days with per-canary quality checks. Rollback path stays live for 30 days.
- 05
Old DB kept as read-only fallback for 30 days. At day 30, dual-write disabled, old DB export archived, subscription cancelled. Full runbook + video handover for your team.
Retire old DB. Old DB kept as read-only fallback for 30 days. At day 30, dual-write disabled, old DB export archived, subscription cancelled. Full runbook + video handover for your team.
Questions we get about vector database migration, with real answers.
Depends. Pinecone is legitimately best-in-class for managed serverless vector search — pick it if you want zero ops and are okay with SaaS pricing at scale. Migrate off it if: your index is growing faster than Pinecone's pricing tiers make sense, you need self-hosting (compliance / regulated data), you want SQL joins against your vectors (PGVector wins), or you need advanced filtering that Pinecone can't do efficiently (Qdrant wins). The audit will make the call for your specific traffic.
Yes, at scale under ~50M vectors with sensible index tuning (HNSW, appropriate ef_construction + m parameters). PGVector 0.8+ has hybrid search, quantisation, and query planner improvements that put it on par with dedicated vector DBs for most B2B SaaS workloads. Where it's not enough: multi-tenant workloads with 500M+ vectors, sub-10ms latency requirements at high QPS. Then Milvus or Qdrant.
Dual-write pattern. New writes go to both the old and new DB during the migration window. Reads switch over gradually — 5% traffic first, then 25%, then 100% — with retrieval-quality checks at each canary. Rollback is a single feature-flag flip. Every 2026 migration we've shipped had zero user-facing downtime.
It hasn't on any 2026 migration, because the eval harness catches it before cutover. If it did on a future migration: the rollback path stays live for 30 days, we roll back within an hour of detecting the regression, re-index with the fix, re-run the eval, cut over again. That's what the fixed price protects you from.
Yes — this is often the right time to do it. If you're on an older embedding model (text-embedding-ada-002, older Cohere embeddings) and want to move to text-embedding-3-large, Voyage-3, or newer Cohere models, we can re-embed the entire corpus as part of the backfill. The audit measures whether the quality improvement is worth the re-embed cost.
£8K audit week + fixed migration quote. 2026 migrations landed £18K-£55K for indexes under 20M vectors, £55K-£140K for multi-tenant indexes over 100M vectors. Retainer for ongoing tuning + query-planner reviews is £3K/month.
Yes — every direction between the 6 major vector DBs. Weaviate → PGVector is common when teams outgrow Weaviate Cloud pricing. Chroma → Qdrant is common when teams move from prototype to production. Every migration follows the same audit → dual-write → canary → cutover pattern.
Yes — the dual-write middleware and backfill scripts run inside your infra by default. Nothing about the migration process requires the vector data to touch our systems. All the code we write becomes yours on commit.
Send a 5-line brief. That's it.
5 lines: current vector DB, rough vector count, embedding model, whether self-hosting is required, and what's driving the migration (cost / features / lock-in). Mohit replies inside 24 hours with a target-DB recommendation + audit slot.