LanceDB는 10만 개의 OpenAI 임베딩을 pgvector보다 22배 빠르게 로드한 반면, pgvector는 8개의 동시 클라이언트로부터 들어오는 동일한 워크로드에 대해 1.8배 더 빠르게 응답했습니다. 단일 스레드 지연 시간과 저장 효율성 측면의 격차 또한 LanceDB에 유리하게 나타났으며, 이를 통해 개발자들은 데이터에 기반하여 벡터 저장소를 선택할 수 있는 근거를 얻었습니다.

지금 벤치마크가 중요한 이유

벡터 검색은 연구실을 넘어 추천 엔진 및 검색 증강 생성(RAG)과 같은 프로덕션 서비스로 이동했습니다. 대부분의 팀은 이미 PostgreSQL을 운영하고 있으므로, pgvector 확장은 새로운 인프라 구축 없이 유사도 검색을 제공할 수 있다는 장점이 있습니다. 반면 LanceDB와 같은 전용 저장소는 더 낮은 지연 시간과 저렴한 저장 비용을 내세웁니다. 팀은 "기존 환경에 추가할 것인가"와 "목적에 맞게 설계된 엔진을 실행할 것인가" 사이에서 선택해야 하며, 이 결정은 데이터셋이 커지고 요청률이 높아짐에 따라 비용과 성능에 직접적인 영향을 미칩니다.

테스트 설정 방식

두 시스템 모두 OpenAI 임베딩 모델로 생성된 1,536차원의 동일한 벡터 10만 개를 인덱싱했습니다. 우리는 데이터 주입(ingestion) 속도, 디스크 사용량, 단일 스레드 쿼리 지연 시간 및 8개의 동시 클라이언트를 이용한 처리량(throughput)을 측정했습니다.

직접 비교 결과

  • 데이터 주입 속도 – LanceDB가 22배 앞섰습니다.
  • 디스크 점유 공간 – LanceDB는 pgvector가 사용한 공간의 약 1/3 수준으로 벡터를 저장했습니다.
  • 단일 스레드 지연 시간 – LanceDB에서 쿼리가 약 2배 더 빠르게 실행되었습니다.
  • 동시성 확장성 – 8개의 병렬 클라이언트 환경에서 pgvector가 LanceDB보다 1.8배 높은 처리량을 제공했습니다.

차이의 아키텍처적 원인

LanceDB는 애플리케이션을 호스팅하는 Python 프로세스 내부에서 실행되는 임베디드 라이브러리입니다. 모든 작업이 프로세스 내에서 이루어지므로 데이터가 네트워크 경계를 넘지 않으며, 최소한의 오버헤드로 인덱스를 업데이트합니다. 이러한 설계는 단일 작업 워크로드에서는 탁월하지만, 여러 Python 스레드가 Global Interpreter Lock(GIL)을 두고 경쟁할 때 한계에 부딪힙니다. GIL은 Python 바이트코드의 진정한 병렬 실행을 차단하기 때문입니다.

pgvector는 서버 측에서 PostgreSQL을 확장합니다. 각 클라이언트 연결은 별도의 서버 프로세스를 실행하므로 GIL을 완전히 우회합니다. PostgreSQL 플래너가 유사도 검색을 수행하는 방법을 결정하며, 서버는 동시 요청을 처리하기 위해 여러 프로세스를 생성할 수 있습니다. 이러한 격리 구조 덕분에 부하가 걸린 상황에서도 더 나은 확장성을 보여줍니다.

필터링 및 쿼리 계획의 특이점

실제 RAG 파이프라인은 벡터 유사도와 전통적인 필터(예: WHERE user_id = 42)를 결합하는 경우가 많습니다. LanceDB는 실행 시마다 예측 가능한 방식으로 동작하는 프리필터(prefilter)를 적용합니다. 반면 pgvector는 PostgreSQL의 쿼리 플래너에 의존하는데, 이는 통계 정보에 따라 빠른 인덱스 스캔을 선택하거나 더 느린 전체 스캔(exact scan)으로 전환될 수 있습니다. pgvector 테이블에 데이터를 대량으로 로드한 후 ANALYZE를 실행하면 해당 통계 정보가 갱신됩니다. 이를 수행하지 않으면 재현율(recall)이 거의 0에 가깝게 떨어져 검색 기능이 사실상 마비될 수 있습니다.

각 옵션이 적합한 경우

pgvector를 선택해야 하는 경우

  • 이미 PostgreSQL을 사용 중이며 새로운 서비스를 추가하고 싶지 않은 경우.
  • 많은 수의 동시 사용자 또는 API 호출이 예상되는 경우.
  • ACID 보장과 익숙한 DBA 도구가 중요한 경우.

LanceDB를 선택해야 하는 경우

  • 워크플로우가 새로운 임베딩을 빈번하게 주입하는 ML 파이프라인인 경우.
  • 단일 요청 에이전트(예: 챗봇)를 위해 가장 빠른 쓰기 경로와 낮은 지연 시간이 필요한 경우.
  • 디스크 비용이 중요하며 단일 스레드 성능의 한계를 감수할 수 있는 경우.

요약: 순수 데이터 주입 속도, 최소한의 저장 공간, 단일 요청 지연 시간이 가장 중요하다면 LanceDB가 승자입니다. 반면, 동시에 많은 사용자를 지원해야 하고 기존 PostgreSQL 환경을 활용해야 한다면, 동시성 측면에서 우위에 있는 pgvector가 더 안전한 선택입니다. 이 벤치마크 수치를 활용하여 귀하의 제품에 가장 중요한 지표에 맞는 저장소를 선택하십시오.