RAG 실전 ⑤ — 벡터 DB: 천만 벡터까지는 pgvector면 충분하다

벡터 DB 선택은 벤치마크 1등 찾기가 아니라 "내 필터, 내 규모, 내 운영 조직"의 문제다. 결론부터: ~1천만 벡터까지는 pgvector, 그 위부터 디스크 인덱스·전용 엔진 검토.

pgvector 시작 설정값 — 그대로 복사

공식 README 기준: HNSW m=16, ef_construction=64, ef_search=40에서 시작. recall 0.98~0.99가 필요하면 ef_search를 100~250으로. Supabase 실측: 100만 OpenAI 1536차원 벡터를 8코어/32GB에서 m=24/ef_construction=56으로 빌드하면 accuracy@10 0.99, HNSW가 IVFFlat 대비 동일 정확도에서 6배 이상의 QPS, 동일 컴퓨트의 Qdrant보다 높은 처리량. 메모리 감각: 1536차원 float32 기준 100만 벡터 ≈ 6GB RAM(halfvec로 절반, 이진 양자화로 1/32). 수천만 대역은 pgvectorscale(StreamingDiskANN) — 5천만 벡터에서 Pinecone 대비 p95 1/28, 비용 75% 절감 주장.

"벡터 DB는 잘못된 추상화"라는 논거

TigerData의 주장: 임베딩은 독립 데이터가 아니라 원본에서 파생된 데이터인데, 별도 벡터 DB에 넣는 순간 원본과의 동기화 책임이 사람에게 넘어온다 — "지웠어야 할 인덱스에 4개월간 월 $2,000을 내던" 팀 사례. 문서 수정·삭제가 잦은 사내 위키 RAG일수록 "원본과 같은 DB에서 인덱스처럼 자동 동기화"(pgai Vectorizer류)가 강해지는 논리다. 한국 사례로 우아한형제들의 벡터 검색 선정기: 2단계 실증 끝에 MongoDB Atlas·OpenSearch를 제치고 RDS+pgvector를 택했다 — 결정 요인은 벤치마크가 아니라 "배달 가능 지역"이라는 동적 필터와 사내 운영조직의 지원 여부. 부하 테스트에서 Atlas·OpenSearch는 500 에러로 무너지고 RDS는 p95 100ms 미만.

프로덕션 recall을 죽이는 건 ANN이 아니라 필터다

Qdrant의 필터링 가이드가 정리한 함정: post-filter는 선택도 높은 필터에서 결과가 소멸하고(top-k 뽑고 걸렀더니 0건), naive pre-filter는 후보가 작아지면 HNSW 그래프가 끊겨 전수 스캔이 된다. 멀티테넌트 tenant_id 필터, 날짜 필터에서 "결과 0건" 장애의 단골 원인. 선정 체크리스트에 filter-aware 인덱스(Qdrant filterable HNSW, pgvector 0.8+의 iterative scan, pgvectorscale 라벨 필터) 여부를 반드시 넣어라.

2026년의 스케일 지형

• 이진 양자화가 전 진영 표준 — Elastic BBQ: 1024차원 1.38억 벡터의 메모리 535GB→19GB(32배), 3배 oversampling+리스코어로 recall 90%+ 유지. pgvector bit 타입, Milvus RaBitQ 동일 방향.
• 오브젝트 스토리지 네이티브 — turbopuffer(웜 p50 14ms, 비용 1/10 주장, Anthropic·Notion 고객), Milvus 3.0(2026-07, 레이크 네이티브). "벡터 DB에 복사해 넣는" 시대에서 "레이크 위에 인덱스만 얹는" 시대로.
• 상시-웜 관리형 vs 콜드 감수 — Pinecone 서버리스($0.33/GB/월 + 읽기 과금) vs 오브젝트 스토리지 콜드 수백 ms — 트래픽 패턴으로 결정.

한 줄 요약: 벤더 벤치마크에는 당신의 필터가 없다 — 자기 데이터·자기 필터 비율로 직접 벤치마크하고, 동기화 책임을 누가 지는지부터 물어라.

— RAG 실전 시리즈 ⑤ / 다음 글: 검색 품질 — 하이브리드 + 리랭커가 먼저다