pgvector에서 Qdrant로 마이그레이션 — 1.2억 벡터인데 다운타임 어디까지 줄일 수 있나요

1.2억 정도면 Qdrant로의 전환 가치 충분합니다. 비슷한 규모(8천만)에서 마이그레이션한 경험으로 정리합니다.

패턴 — dual-write + shadow read 권장

snapshot 기반은 1.2억이면 dump만 4시간, import도 6시간 정도 걸립니다. 그동안 WAL catch-up이 따라가지 못해서 결국 쓰기 정지 윈도가 1~2시간 필요합니다. 다운타임 거의 0으로 가려면 dual-write가 답입니다.

// 1단계 — application-level dual write
async function upsertVector(id, vec, meta) {
  await pg.query('INSERT INTO vectors ...')
  // shadow write — 실패해도 main flow 안 막음
  qdrant.upsert({ collection: 'docs', points: [{ id, vector: vec, payload: meta }] })
    .catch(e => log.warn('shadow write failed', e))
}

일관성 검증 — sampling 100K로 양쪽에 같은 query 날려서 top-10 overlap 측정. 95% 이상 일치 + 1주 안정이면 cutover. 그동안 read는 PG가 source of truth.

노드 수 — Qdrant는 RAM 효율이 pgvector 대비 약 60% 좋습니다. 1.2억 1024차원 = 약 480GB → 3-node 클러스터(192GB 각) 또는 quantization으로 single-node 256GB도 가능. shard replication factor 2 권장.

quantization 고려 — Scalar Quantization(int8) 적용 시 메모리 1/4, recall 손실 2~3%. 실측 후 결정.

1.5억 규모로 옮긴 적 있는데 한 가지 추가하면, payload 필터 패턴이 다릅니다. pgvector는 SQL WHERE로 자유롭지만 Qdrant는 payload 필터에 인덱스 등록한 키만 빠릅니다.

예를 들어 tenant_id, region 같은 자주 쓰는 필터는 미리 payload index 만들어야 query 100ms → 8ms 됩니다. 안 만들면 풀스캔이라 pgvector보다 느려질 수도 있어요.

// 컬렉션 만들 때
client.createPayloadIndex({
  collection_name: 'docs',
  field_name: 'tenant_id',
  field_schema: 'keyword',
})

그리고 hybrid search(BM25 + vector) 하실 거면 Qdrant 1.10+의 sparse vector 지원 확인하세요.