PGVector에 대한 반론

• Postgres 확장 pgvector는 벡터 유사도 검색을 지원하지만, 데모 수준과 실제 운영 환경 간의 격차가 큼
• IVFFlat과 HNSW 인덱스 모두 장단점이 뚜렷하며, 특히 HNSW는 인덱스 생성 시 수 GB 단위의 메모리 사용과 긴 빌드 시간이 문제
• 실시간 검색 및 인덱스 갱신은 구조적으로 어렵고, 지속적인 삽입·갱신 시 락 경합과 성능 저하 발생
• 필터링 전략(Pre/Post) 과 쿼리 플래너의 한계로 인해 검색 정확도와 속도 간의 불안정한 균형이 나타남
• 전용 벡터 데이터베이스(Pinecone, Weaviate 등) 가 제공하는 기능을 수동으로 구현해야 하며, 결과적으로 운영 복잡성과 비용 증가로 이어짐

pgvector의 한계 개요

• pgvector는 Postgres에 벡터 유사도 검색 기능을 추가하는 확장이며, 단순한 데모에서는 잘 작동하지만 운영 환경에서는 확장성 문제가 발생
• 많은 블로그 글이 설치와 간단한 쿼리 예시만 다루며, 운영 시 발생하는 성능·메모리·인덱스 관리 문제는 거의 언급하지 않음

인덱스 선택의 문제

• pgvector는 IVFFlat과 HNSW 두 가지 인덱스 유형을 제공
  • IVFFlat: 클러스터 기반 구조로, 인덱스 생성 속도는 빠르지만 클러스터 수 설정이 성능과 정확도에 큰 영향을 미침
    • 클러스터 재분배가 불가능해 정기적인 인덱스 재구축 필요
  • HNSW: 다층 그래프 구조로 정확도와 일관된 성능을 제공하지만, 인덱스 생성 시 메모리 사용량이 매우 높고 속도가 느림
• 수백만 개 벡터 인덱스 생성 시 10GB 이상 RAM 사용 가능성이 있으며, 이는 운영 DB의 안정성에 직접적인 위협

실시간 검색의 어려움

• 새 데이터 삽입 후 즉시 검색 가능해야 하지만, 인덱스 갱신 구조상 실시간 반영이 어려움
  • IVFFlat: 새 벡터가 기존 클러스터에 추가되며, 시간이 지날수록 클러스터 불균형 발생 → 주기적 재빌드 필요
  • HNSW: 삽입 시 그래프 갱신으로 락 경합 및 메모리 부하 발생
• 인덱스 재구축 중에는 데이터 일관성 유지와 서비스 지속성 확보가 어려움
• 운영 환경에서는 스테이징 테이블, 이중 인덱스, 오프라인 빌드, eventual consistency 등 다양한 우회 전략이 필요

필터링과 쿼리 플래너의 한계

• status, user_id, category 등 메타데이터 필터링과 벡터 검색을 결합할 때 Pre-filter vs Post-filter 선택이 성능에 큰 영향
  • Pre-filter는 선택적 필터에 유리하지만, 데이터가 많을 경우 느림
  • Post-filter는 빠르지만 필터 후 결과 누락 가능성 존재
• Postgres의 쿼리 플래너는 벡터 유사도 비용 모델을 이해하지 못함, 통계 정보가 부정확해 비효율적 실행 계획 생성
• 결과적으로 CTE, 파티셔닝, 쿼리 재작성 등 임시 방편적 해결책이 필요하며, 이는 규모 확장 시 비효율적

전용 벡터 데이터베이스와의 비교

• Pinecone, Weaviate, OpenSearch k-NN 등은 필터링 전략 자동 선택, 하이브리드 검색, 실시간 인덱싱, 수평 확장을 기본 제공
• pgvector에서는 이러한 기능을 직접 구현해야 하며, 이는 운영 복잡성과 유지보수 부담으로 이어짐
• Timescale의 pgvectorscale은 StreamingDiskANN, 증분 인덱스 빌드, 필터링 개선 등을 제공하지만,
  • AWS RDS에서는 미지원이며, 추가 확장 설치 및 관리 부담 존재

비용과 운영 고려

• 전용 벡터 DB는 유료 서비스이지만, Postgres 인프라 과다 프로비저닝·인덱스 관리·엔지니어링 시간을 고려하면 실질적으로 더 저렴할 수 있음
• 예시로 Turbopuffer는 월 $64부터 시작하며, 운영 단순성과 확장성을 제공

결론 및 권장 사항

• pgvector는 기술적으로 훌륭하지만 운영 환경에서는 제약이 많음
• 운영 시스템 구축 시 고려해야 할 핵심 사항
  1. 인덱스 관리의 복잡성과 높은 메모리 요구
  2. 쿼리 플래너의 한계로 인한 필터링 비효율
  3. 실시간 인덱싱의 비용과 품질 저하
  4. 블로그 자료의 과도한 단순화
  5. 전용 벡터 DB의 존재 이유와 그 효율성
• 결론적으로, Postgres 통합의 단순함보다 운영 복잡성이 더 크며, 대부분의 팀은 전용 벡터 데이터베이스 사용이 현실적 선택