pgvector와 전용 벡터DB, 2026년 선택 기준

pgvector 0.8과 전용 벡터DB, 경계는 어디로 이동했나?

결론부터 말하면 경계는 사라지지 않았고 이동했다. 2026년 기준 pgvector는 "필터 조건이 섞인 ANN 검색"이라는, 전용 벡터DB로 넘어가던 대표적 이유 하나를 줄였다. 하지만 1억 벡터급 고동시성·엄격한 p99·수평 확장이 필요한 워크로드에서는 여전히 전용 시스템이 별도 검증 대상이다.

이 글의 핵심

• pgvector 0.8.0은 iterative index scans를 추가해 필터 선택도가 낮을 때 HNSW 후보 부족 문제를 완화했다출처: pgxn CHANGELOG.
• halfvec(FP16) 타입으로 저장공간·메모리 대역폭 절감 선택지가 생겼지만 recall·지연은 모델·설정별 재측정이 필요하다.
• 1억 벡터·필터 15~25% 조건의 한 벤치마크에서 Qdrant 1.10은 filtered Recall@10 0.97, pgvector 0.7은 0.91로 보고됐다출처: inductivee.
• 선택 기준은 데이터 규모 하나가 아니라 필터 선택도, 쓰기/검색 혼합률, 트랜잭션 결합도, 동기화 비용이다.

두 선택지는 애초에 같은 문제를 다른 방식으로 푼다. pgvector는 PostgreSQL 안에 벡터 컬럼과 인덱스를 얹어 트랜잭션·조인·권한·백업을 그대로 공유한다. Qdrant·Milvus 같은 전용 시스템은 벡터 인덱스와 샤딩·검색 노드 분리를 중심으로 설계됐고, 원문 데이터는 별도 저장소에 두고 동기화한다. 둘 다 "벡터 검색"이라는 기능을 제공하지만, 비교해야 할 항목은 QPS 하나가 아니라 아래 축들이다.

필터가 섞인 검색에서 두 선택지는 어떻게 다른가?

차이는 필터가 ANN 인덱스 앞인지 뒤인지에서 갈린다. pgvector를 포함한 근사 인덱스 계열은 필터가 ANN 검색 뒤에 적용될 수 있어, 필터 선택도가 낮으면 원하는 행보다 적은 결과가 반환되는 구조적 약점이 있다출처: tecnisys 문서. pgvector 0.8.0의 iterative scan은 hnsw.iterative_scan 또는 ivfflat.iterative_scan을 켜서 필요한 결과 수를 채울 때까지 인덱스를 추가 탐색하고, hnsw.max_scan_tuples·ivfflat.max_probes로 추가 탐색량에 상한을 둔다.

반면 전용 벡터DB는 메타데이터 필터를 인덱스 구조 안에 통합해 설계하는 경우가 많다. 앞서 언급한 벤치마크에서 Qdrant 1.10.0은 필터 선택도 15~25% 조건에서 filtered Recall@10 0.97을 기록했고, pgvector 0.7.0 HNSW는 0.91을 기록했다. 다만 이 수치는 ef_construction=128, m=16이라는 특정 설정과 768차원 임베딩 조건에 한정된다. 인덱스 설정, 필터 컬럼의 인덱스 여부, iterative scan 활성화 여부가 바뀌면 격차는 달라질 수 있어 "항상 그렇다"로 일반화할 수 없다.

쓰기 처리량과 지연시간은 어느 쪽이 유리한가?

벤치마크 조건에서는 전용 시스템이 삽입률과 p99에서 앞섰다. 같은 1억 벡터 비교에서 Qdrant는 삽입 42,000 vectors/s, p50 3.2ms, p99 18.4ms를 기록한 반면 pgvector 0.7 HNSW는 삽입 12,400 vectors/s, p50 9.1ms, p99 58.3ms로 보고됐다. p99가 3배 이상 벌어졌다는 점은 꼬리 지연에 민감한 워크로드에서 중요한 신호다.

그러나 배포 형태를 달리한 또 다른 재현형 벤치마크는 정반대 방향의 수치를 보여준다. 로컬 Docker의 pgvector는 ingest 1,943.7 rows/s, semantic p50 5.71ms, peak QPS 1,212.3을 기록했고, 관리형 Qdrant는 1,825.2 rows/s, p50 14.30ms, peak QPS 80.4로 더 느리게 보고됐다출처: Imran-ml 저장소. 이 저장소는 pgvector가 호스트에서 네트워크 지연 없이 실행된 반면 Qdrant는 클라우드 계층으로 측정됐다고 명시한다. 즉 두 수치 세트 모두 "제품 자체의 우열"이 아니라 하드웨어·네트워크·동시성 조건의 산물로 읽어야 한다.

운영 비용과 TCO는 어떻게 갈리는가?

표면 비용만 보면 pgvector가 낮게 산정된다. 1억 벡터 기준 inductivee 벤치마크는 월 비용을 pgvector 약 180달러, Qdrant 자체 구축 약 280달러, Pinecone Serverless 약 650달러로 제시했다출처: inductivee. 하지만 pgvector 수치에는 RDS의 운영·백업·트랜잭션 데이터베이스 비용이 포함돼 있고, Qdrant 수치는 EC2 비용만 반영했다. 같은 서비스 범위를 비교한 것이 아니므로 이 세 수치를 나란히 놓고 "더 싸다"는 결론을 내리는 것은 조건을 생략한 해석이다.

운영 관점에서 빠뜨리기 쉬운 항목은 인덱스 재생성 시간, 장애 복구 절차, 데이터 중복 동기화 비용이다. pgvector를 쓰면 원문·메타데이터·벡터가 한 트랜잭션 수명주기 안에 있어 별도 동기화 계층이 없지만, 전용 벡터DB를 쓰면 원본 데이터 변경 시 벡터 스토어로의 동기화 파이프라인을 운영팀이 별도로 유지해야 한다.

비교 수치 요약

출처: inductivee 벤치마크, 조건은 768차원 Ada-002, 1억 벡터, 필터 선택도 15~25%, ef_construction=128, m=16.

pgvector에서 전용 벡터DB로 옮기면 실제로 드는 비용은 무엇인가?

전환 비용은 인프라 비용보다 재측정·재설계 비용이 크다. 먼저 임베딩 차원과 모델이 같아도 인덱스 파라미터(m, ef_construction, ef_search)와 필터 선택도가 다르면 recall·지연이 재현되지 않으므로, 전용 DB로 옮긴 뒤 동일한 필터 조건으로 다시 벤치마크해야 한다. 둘째, 원문·권한·테넌트 데이터가 PostgreSQL에 남아 있다면 벡터 스토어와의 동기화 파이프라인을 새로 구축해야 하고, 이 과정에서 삽입·갱신 지연이 추가된다. 셋째, 백업·복제·장애조치 체계가 PostgreSQL 기준으로 짜여 있었다면 전용 DB의 복제·스냅샷 방식에 맞춰 운영 절차를 다시 써야 한다. 반대 방향, 즉 전용 DB에서 pgvector로 옮길 때도 halfvec 적용 여부와 iterative scan 상한값(hnsw.max_scan_tuples) 설정을 새로 튜닝해야 기존 recall 수준을 맞출 수 있다. 어느 방향이든 "타입만 바꾸면 된다"는 전제는 성립하지 않는다.

결국 무엇을 기준으로 골라야 하는가?

규모 하나로 결정할 문제가 아니다. PostgreSQL에 원문·권한·테넌트·상태 데이터가 이미 있고, 벡터 검색이 트랜잭션과 강하게 결합되며, 벡터 수가 수십만~수천만 범위라면 pgvector를 별도 동기화 계층 없이 쓰는 이점이 크다. 반대로 대규모 병렬 검색, 높은 삽입률, 엄격한 p99, 여러 노드로의 수평 확장이 핵심 요구사항이면 Qdrant·Milvus 같은 전용 시스템을 별도로 평가해야 한다출처: inductivee.

"벡터가 데이터타입으로 흡수됐다"는 표현도 범위를 좁혀 써야 정확하다. pgvector는 벡터를 컬럼 타입과 인덱스로 다루게 해줄 뿐, 전용 벡터DB의 분산 검색·독립 확장·관리형 운영 기능을 대체하지는 않는다. 2026년 기준 실제 경계는 "pgvector냐 전용 DB냐"가 아니라 "트랜잭션 데이터와 벡터를 같은 수명주기로 운영할 것인가, 벡터 검색 계층을 독립적으로 확장할 것인가"다.

핵심 정리

• pgvector 0.8의 iterative scan은 필터 선택도가 낮은 상황의 recall 부족을 완화하지만, 필터가 ANN 검색 뒤에 적용될 수 있다는 구조 자체는 바뀌지 않았다.
• 1억 벡터·필터 15~25% 조건의 한 벤치마크에서 Qdrant는 삽입률·p99·recall 모두에서 pgvector 0.7을 앞섰지만, 배포 조건이 다른 또 다른 벤치마크는 반대 결과를 보였다.
• 비용 비교는 산정 범위(운영·백업 포함 여부)가 다르면 그대로 비교할 수 없다.
• 선택 기준은 벡터 개수가 아니라 필터 선택도, 쓰기/검색 혼합률, 트랜잭션 결합도, 동기화 비용이다.
• 전환은 어느 방향이든 인덱스 파라미터 재튜닝과 동기화 파이프라인 재구축을 동반한다.

자주 묻는 질문

pgvector의 halfvec은 언제 쓰는 게 안전한가?

halfvec은 FP16 기반이라 저장공간과 메모리 대역폭을 줄이지만, 실제 recall 손실 폭은 임베딩 모델과 인덱스 설정에 따라 달라진다. 도입 전에는 운영 중인 모델·차원·인덱스 파라미터로 recall·지연을 직접 재측정하는 절차가 필요하다.

iterative scan을 켜면 항상 recall이 개선되는가?

필터 선택도가 낮은 쿼리에서는 개선되지만, hnsw.max_scan_tuples나 ivfflat.max_probes 상한을 낮게 잡으면 여전히 후보 부족이 남을 수 있다. 상한을 올리면 지연시간이 늘어나므로 recall과 지연 사이의 트레이드오프로 다뤄야 한다.

벤치마크 수치가 서로 다른 이유는 무엇인가?

네트워크 지연, 하드웨어 사양, 동시성 조건이 벤치마크마다 다르기 때문이다. 한 저장소는 pgvector를 호스트 로컬에서, Qdrant를 클라우드 계층에서 측정해 비교 자체가 공정하지 않았다고 명시했다. 따라서 공개 벤치마크 수치는 참고 범위로만 쓰고, 운영 환경과 같은 조건으로 재측정하는 것이 안전하다.

전용 벡터DB로 넘어가기 전에 먼저 점검할 항목은 무엇인가?

필터 컬럼의 인덱스 여부, 동시 사용자 수와 insert/update 비율, p95·p99 지연 목표, 백업·장애조치 요구 수준을 먼저 정리해야 한다. 이 항목들이 명확하지 않으면 전용 DB로 옮긴 뒤에도 같은 재측정 작업을 반복하게 된다.

더 알아보기

데이터베이스 선택의 실체: 워크로드로 읽는 판단 기준 — 이 주제의 종합 가이드