pgvector, "이미 Postgres 쓰니까"만으로 골라도 될까?

아니다. 규모·인덱스·목표 recall을 먼저 정하지 않으면 나중에 수치가 뒤집힌다.

  • PostgreSQL이 이미 중심 DB이고 벡터가 수백만 개 이하, 동시성이 높지 않다면 pgvector는 운영 복잡도를 줄이는 실사용 선택지다.jacar.es
  • 50M 벡터·768차원·99% recall 조건에서 pgvector+pgvectorscale은 471.57 QPS, Qdrant는 41.47 QPS로 보고됐다.ecorpit.com
  • 다만 같은 벤치마크의 p99 지연은 Postgres 74.60ms, Qdrant 38.71ms로 오히려 Qdrant가 낮았다.ecorpit.com
  • 순수 벡터 검색 성능·낮은 p99·강한 수평 확장이 핵심이면 전용 벡터DB 쪽 검토가 함께 필요하다.

가장 흔한 함정은 "Postgres 쓰고 있으니 pgvector 붙이면 끝"이라는 판단이다. 실제로는 인덱스 방식(HNSW/IVFFlat/StreamingDiskANN), 벡터 차원, 목표 recall, 하드웨어가 모두 결과에 직접 영향을 준다. 이 네 가지를 적지 않은 벤치마크는 비교 자료로 쓸 수 없다.

인덱스 종류에 따라 QPS·지연이 이렇게 달라지는데, 왜 다들 뭉뚱그려 말할까?

pgvectorscale의 StreamingDiskANN이 대규모에서 밀집형 벡터 검색을 끌어올린다는 요약이 많지만, 이건 특정 버전 조합에서 나온 결과다. 위 50M 벤치마크는 Postgres 16.8, pgvector 0.6.1, pgvectorscale 0.7.0, AWS r6id.4xlarge 환경에서 나온 수치로, 다른 버전·다른 인스턴스에서 그대로 재현된다는 보장은 없다.ecorpit.com 2025년 ANN-Benchmarks 요약에서도 pgvector(HNSW)가 상위권으로 언급되지만, "기본 선택은 HNSW"라는 정리 자체가 IVFFlat이나 DiskANN과 성능 격차가 있다는 뜻이기도 하다.jacar.es

1M 벡터, 1536차원에서는 실제로 뭐가 밀리나?

같은 규모에서 pgvector(HNSW)는 Qdrant보다 삽입 시간과 recall, 지연에서 모두 뒤처졌다. 1M 벡터·1536차원 비교에서 pgvector는 삽입 38분, Recall@10 0.94, p50 22ms, p99 87ms, RAM peak 3.1GB였고, Qdrant는 삽입 14분, Recall@10 0.98, p50 9ms, p99 34ms, RAM peak 4.8GB였다.redai.pl 반면 구성 초기화 시간은 pgvector 30분, Qdrant 1시간, Weaviate 3~4시간으로 pgvector가 오히려 짧았다.redai.pl 즉 "초기 세팅은 쉽지만 대규모·고recall에서는 대가가 있다"는 구조다.

"pgvector는 느리다"는 말, 어디까지 맞을까?

작은 규모에서는 맞지 않다. 오해를 바로잡을 필요가 있다. 2025년 2월 공개 자료에서 1M 벡터(64차원) 기준 적응형 접근은 P95 125161ms, 고정 설정은 141219ms였고, 500K 벡터에서는 각각 6065ms, 6670ms로 나왔다.mastra.ai 같은 자료는 1,000개 이상 데이터셋에서 recall이 대체로 100%였다고 적었다.mastra.ai 즉 낮은 차원·중소 규모에서는 pgvector가 충분히 안정적으로 동작한다. "pgvector는 무조건 느리다"는 단정은 규모와 차원을 빼놓은 요약일 뿐이다.

도입하면 실제로 뭘 더 챙겨야 할까?

2026년 기준으로 봐도 pgvector 자체보다 주변 조건 관리가 더 큰 비용이다. 버전(0.6.1 vs 0.7.0), 인덱스 종류, 하드웨어(r6id.4xlarge 등), 목표 recall을 벤치마크 문서에 함께 적어두지 않으면 6개월 후 다른 팀이 그 수치를 오해하고 재현하려다 헛수고를 하게 된다. 또한 하이브리드 검색·SQL 조인·권한/감사 로그·실험 결과 저장처럼 RAG 주변 데이터를 함께 다룰수록 한 DB로 묶는 pgvector의 체감 효용이 커진다는 점도 실무 자료들이 반복해서 짚는 부분이다.jacar.es

핵심 정리

  • pgvector는 수백만 벡터 이하·동시성 낮음·Postgres 중심 운영에서 운영 복잡도를 줄이는 선택지다.
  • 50M급 이상, 높은 recall·처리량이 필요하면 pgvectorscale 같은 확장 조합까지 검토해야 한다.
  • 1M 벡터·1536차원 비교에서 pgvector는 Qdrant보다 삽입·recall·지연 모두 밀렸지만 초기 세팅은 더 짧았다.
  • 벤치마크 수치를 인용할 땐 버전·인덱스 종류·차원·목표 recall·하드웨어를 반드시 같이 적어야 비교가 성립한다.
  • 순수 벡터 검색 성능과 낮은 p99, 대규모 동시성이 최우선이면 전용 벡터DB 쪽도 함께 검토하는 편이 안전하다.