pgvectorscale·Lantern·ParadeDB, 벡터DB 전환을 얼마나 늦출 수 있나

50M 벡터·768차원·99% recall 조건에서 PostgreSQL+pgvectorscale은 471.57 QPS로 Qdrant(41.47 QPS)를 크게 앞섰지만, 인덱스 빌드는 약 11.1시간으로 Qdrant의 3.3시간보다 3배 이상 걸렸다. 2026년 기준 pgvectorscale·Lantern·ParadeDB는 벡터·검색을 Postgres 데이터타입/기능으로 흡수해 중간 규모까지는 전용 벡터DB 전환을 미룰 근거를 만들지만, 규모·recall·재인덱싱 주기가 동시에 타이트해지는 지점부터는 근거가 약해진다.

RDB 확장만으로 벡터 검색을 얼마나 버틸 수 있나?

결론부터: 수백만~수천만 벡터 구간까지는 pgvectorscale·Lantern·ParadeDB로 recall·QPS를 충분히 확보할 수 있다. 다만 50M 벡터급에서 고 recall과 짧은 인덱스 재빌드를 동시에 요구하면 전용 벡터DB와의 격차가 다시 벌어진다. 이 글은 이 세 확장이 각각 "Postgres의 어느 부분을 흡수했고, 어느 부분은 아직 넘겨받지 못했는지"만 뜯는다.

• pgvectorscale은 pgvector에 DiskANN 계열 인덱스를 얹어 대용량 구간의 QPS를 끌어올리는 데 집중한다.
• Lantern과 ParadeDB는 벡터DB 대체가 아니라 각각 인덱스 빌드 속도, 검색(FTS) 흡수 쪽 대안에 가깝다.
• 50M 벡터·768차원 실측에서 Postgres 계열은 QPS 우위, 인덱스 빌드 시간 열세라는 대칭적 트레이드오프가 반복 관찰된다.
• 판단 기준은 벡터 개수 자체가 아니라 "recall·p95·재인덱싱 주기"가 동시에 타이트한가다.

pgvectorscale은 pgvector의 무엇을 바꿔 규모를 늘리나?

pgvectorscale은 pgvector의 인덱스 계층을 DiskANN 기반 구조로 교체·보강해 디스크 상주 대용량 벡터에서의 검색 성능을 끌어올린다.pgvectorscale 저장소 저장소 설명에 따르면 이는 "pgvector의 성능·규모 한계를 보완하는 확장"으로 자리매김하며, 같은 저장소는 50M Cohere embeddings·768차원 조건에서 자체적으로 p95 지연 28배 낮음, 처리량 16배 높음, self-host 비용 75% 절감을 주장한다. 다만 이 수치는 벤더/프로젝트 자체 요약이므로 실사용 판단에는 "제시된 수치"로 구분해 다루는 편이 안전하다.

Lantern은 인덱스 구축에서 어떤 선택을 하나?

Lantern은 HNSW 인덱스 생성 속도를 핵심 지표로 내세운다. 공식 블로그의 Sift 데이터셋 비교에서는 Lantern 8분 30초, pgvector 46분, Pinecone(p2x2 1 pod) 9분이 제시됐고,Lantern 블로그 Wiki 데이터셋에서는 Lantern 44분, Pinecone 30분, pgvector 2시간이라는 값이 나왔다. 같은 글의 다른 요약 표에서는 Sift 기준 pgvector 12분 30초 대 Lantern 7분, Wiki 기준 pgvector 36분 대 Lantern 43분처럼 순위가 뒤집히는 값도 함께 제시돼, 측정 조건에 따라 결과가 갈릴 수 있음을 보여준다.

ParadeDB는 왜 벡터보다 검색을 먼저 흡수했나?

ParadeDB의 공개 벤치마크는 벡터 검색이 아니라 전문검색(FTS) 성격이 강하다. "두 번째 시스템 없이 search"라는 메시지 아래, ParadeDB 0.24.1과 Elasticsearch 8.17을 동일 컨테이너·4 pinned CPU·8GB 메모리 조건에서 비교한 결과 p50 6.34ms 대 8.42ms, p95 14.22ms 대 19.48ms, 처리량 138 QPS 대 103 QPS가 나왔다.ParadeDB 이는 Hacker News 데이터셋 28M rows 조건이며, 벡터DB 대체라기보다 "별도 검색 스토어 도입을 늦추는" 대안으로 읽는 편이 소재에 맞는다.

숫자로 보면 Postgres 계열과 전용 벡터DB는 어디서 갈리나?

측정 환경은 Postgres 16.8, pgvector 0.6.1, pgvectorscale 0.7.0, AWS r6id.4xlarge이며 2025년 4월 실행분이다. MariaDB의 2026 비교 요약에서도 pgvectorscale은 470~570 QPS 그룹, OpenSearch/Qdrant/Milvus는 90~150 QPS 그룹으로 나뉘었고, 인덱스 빌드는 Qdrant 15분 이내, pgvectorscale이 다음 순위, pgvector류가 2.5~3시간으로 묶였다.

QPS를 얻는 대신 무엇을 내주나?

QPS 우위는 인덱스 빌드 시간과 p95 지연에서의 열세로 상쇄된다. 위 실측에서 Postgres+pgvectorscale은 처리량에서 10배 이상 앞섰지만 인덱스 빌드는 3배 이상 느렸고, p95는 Qdrant보다 약 1.6배 길었다. 즉 "쿼리당 처리량"을 우선하면 Postgres 계열이 유리하지만, "테일 지연"과 "재인덱싱 주기"를 우선하면 전용 벡터DB가 유리한 구간이 남는다. 하나를 얻으면 다른 하나가 줄어드는 구조이지 어느 한쪽이 전면 우위인 관계는 아니다.

언제 확장으로 버티고 언제 넘어가야 하나?

데이터가 자주 갱신되지 않고, p95 지연 SLA가 느슨하며, 운영 인력이 Postgres 스택에 이미 익숙한 경우에는 pgvectorscale·Lantern·ParadeDB로 버티는 편이 합리적이다. 반대로 벡터가 50M을 넘고, 인덱스를 자주 재구축해야 하며, p95 지연이 SLA의 핵심 지표라면 전용 벡터DB 전환 압력이 커진다. 규모 하나만으로 판단하지 않고 "재인덱싱 빈도×recall 요구×p95 허용치"를 함께 놓고 봐야 한다.

핵심 정리

• pgvectorscale은 DiskANN 기반 인덱스로 pgvector의 대용량 QPS 한계를 보완하지만, 인덱스 빌드 시간은 여전히 전용 벡터DB보다 길다.
• 50M 벡터·768차원·99% recall 조건(Postgres 16.8/pgvector 0.6.1/pgvectorscale 0.7.0, r6id.4xlarge, 2025년 4월)에서 QPS는 Postgres 471.57 대 Qdrant 41.47, 인덱스 빌드는 11.1시간 대 3.3시간이었다.
• Lantern은 인덱스 구축 속도, ParadeDB는 전문검색(FTS) 흡수 쪽에 가까워 둘 다 "벡터DB 대체"보다 "다른 시스템 도입을 늦추는 보조 사례"로 보는 편이 정확하다.
• 전환 판단 기준은 벡터 개수 자체가 아니라 재인덱싱 빈도·recall 요구·p95 SLA가 동시에 타이트한지 여부다.
• 2026년 기준으로도 이 트레이드오프 구조 자체는 그대로 남아 있다.

더 알아보기

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