2025년 pgvector vs Qdrant vs Milvus 상세 성능 비교

테스트 환경 및 버전

비교 대상 버전

테스트 사양

하드웨어:

• CPU: 16 코어
• RAM: 64GB
• 스토리지: NVMe SSD 1TB
• OS: Linux (io_uring 지원)

데이터셋:

• 벡터 차원: 1536 (OpenAI text-embedding-3-small)
• 벡터 수: 1M, 10M, 50M, 100M
• 메타데이터: JSON (5-10개 필드)

1. 데이터 삽입 성능 상세 비교

삽입 속도 벤치마크

핵심 인사이트:

배치 삽입 권장 사항

최적 배치 크기 비교 (1536차원 기준):

삽입 방식 비교:

PostgreSQL 18 비동기 I/O 효과

삽입 성능 개선:

PostgreSQL 18 설정 권장사항:

2. 검색 성능 비교

검색 속도 벤치마크

100K 벡터, Top-10 검색:

1M 벡터, Top-10 검색:

핵심 인사이트

pgvector (PostgreSQL 18):

• ✅ 처리량 최강: 100K 벡터에서 471 QPS (11.4배 우수)
• ✅ 비동기 I/O: 클라우드 환경에서 2-3배 개선
• ⚠️ 대규모 약점: 1M+ 벡터에서 지연시간 증가

Qdrant 1.15:

• ✅ p99 최우수: 38.71ms → 18.4ms (48% 개선)
• ✅ 일관성: 지연시간 분산 최소화
• ✅ 대규모 안정: 1M+ 벡터에서도 우수한 성능

Milvus 2.6:

• ✅ 균형: 처리량과 지연시간 모두 우수
• ✅ 확장성: 100M+ 벡터까지 선형 확장
• ✅ RaBitQ: 4배 QPS 향상 (메모리 72% 절약)

인덱스 파라미터 튜닝 효과

HNSW 파라미터 영향 (1M 벡터):

권장 설정:

• 일반: m=16, ef_construction=64 (균형)
• 정확도 우선: m=32, ef_construction=128
• 속도 우선: m=8, ef_construction=64

3. 필터링 성능 비교

Qdrant의 Filterable HNSW

특별한 인덱스 구조:

Qdrant는 필터링을 위한 전용 인덱스를 제공한다:

• Pre-filtering vs Post-filtering 자동 선택: 카디널리티 분석으로 최적 방법 자동 선택
• 특수 링크 구조: 필터링된 데이터 포인트 간 연결 유지
• 검색 정확도 보장: 필터 적용 후에도 recall 유지

필터 조건 예시:

Qdrant는 JSON 기반 DSL로 복잡한 필터를 직관적으로 표현한다:

Milvus 2.6 JSON Path Index

100배 빠른 필터링:

Milvus 2.6의 JSON Path Index는 혁신적인 성능 개선을 가져왔다:

• 99% 지연시간 감소: 복잡한 JSON 필터링에서 획기적 개선
• 자동 경로 발견: 스키마 변경 시 자동으로 새 필드 인덱싱
• 동적 필드 지원: 사전 정의 없이 JSON 필드 쿼리 가능

JSON Path 필터 표현식:

Milvus 2.6은 SQL-like 표현식으로 JSON 필드를 직접 쿼리한다:

필터링 성능 비교

벤치마크 (1M 벡터, 10% 필터링):

필터링 기능 비교

4. 고급 검색 기능 비교

Qdrant의 고급 검색 기능

Similarity Search를 넘어서:

검색 방식 설명:

Milvus 2.6의 고급 기능

Hybrid Search 혁신:

Hybrid Search 구성:

Milvus 2.6은 Dense + Sparse 검색을 네이티브로 지원한다:

RRF (Reciprocal Rank Fusion) 방식:

• 두 검색 결과를 순위 기반으로 결합
• 점수 정규화 없이 자동 융합
• Elasticsearch 대비 4배 빠른 성능

pgvector의 SQL 기반 고급 검색

PostgreSQL 생태계 활용:

고급 검색 패턴:

pgvector는 PostgreSQL의 강력한 SQL 기능을 모두 활용할 수 있다:

장점:

• SQL 표준 문법으로 복잡한 쿼리 작성
• 여러 확장(PostGIS, TimescaleDB)과 자유롭게 결합
• 트랜잭션 내에서 벡터 검색 + 비즈니스 로직 통합

5. 2025년 주요 업데이트 영향

PostgreSQL 18의 비동기 I/O 혁명

io_uring 통합의 임팩트:

PostgreSQL 18은 Linux의 io_uring을 완전히 통합하여 I/O 성능을 혁신적으로 개선했다.

성능 개선 수치:

플랫폼별 최적 설정:

pgvector에 미치는 영향:

1. Bitmap Heap Scan: HNSW 인덱스 후 실제 데이터 접근 시 2-3배 빠름
2. Sequential Scan: 인덱스 없는 벡터 테이블 스캔 3배 개선
3. VACUUM: 벡터 테이블 유지보수 속도 향상

Milvus 2.6의 게임 체인저

Storage Format V2:

RaBitQ 1-bit 압축:

Hot-Cold Tiered Storage 전략:

비용 효과:

Qdrant 1.15의 성능 개선

Sparse Vector 16배 향상:

Hybrid Search의 핵심인 sparse vector 성능이 획기적으로 개선되었다.

Mutable Map Index 특징:

BM25 Local Inference 장점:

Qdrant 1.15는 자체 BM25 처리로 외부 의존성을 제거했다:

6. 확장성 비교

수평 확장 능력

멀티 테넌시

Milvus 2.6의 혁신:

멀티 테넌시 구성 방식:

수직 확장 효율성

메모리 사용량 (100M 벡터, 1536차원):

7. 운영 복잡도 비교

설치 및 설정

설치 단계 비교:

관리형 서비스 옵션:

모니터링 및 유지보수

비용 분석 (월간, 100M 벡터 기준)

AWS 기준 추정:

비용 최적화 팁:

pgvector:

• ✅ Aurora Serverless로 자동 스케일링
• ✅ RDS Read Replica로 읽기 분산

Qdrant:

• ✅ Qdrant Cloud 사용 (관리형)
• ✅ 온디맨드 인스턴스 → Spot 인스턴스

Milvus:

• ✅ RaBitQ 압축으로 메모리 72% 절감
• ✅ Hot-Cold Tiered Storage로 스토리지 50% 절감
• ✅ Zilliz Cloud 사용 (관리형)

8. 실전 시나리오별 권장사항

시나리오 1: 대용량 트래픽 웹 서비스

요구사항:

• 일 1억+ 검색 쿼리
• p99 < 100ms
• 복잡한 SQL 조인 필요
• 기존 PostgreSQL 인프라

추천: 🥇 pgvector (PostgreSQL 18)

이유:

• ✅ 처리량 최강 (471 QPS, 11.4배 우수)
• ✅ 비동기 I/O로 클라우드 환경 최적화
• ✅ 기존 인프라 활용으로 운영 비용 절감
• ✅ SQL 조인/집계로 복잡한 쿼리 간편

권장 인프라 구성:

시나리오 2: 실시간 응답 중요 서비스

요구사항:

• p99 < 50ms (엄격)
• 복잡한 메타데이터 필터링
• 실시간 업데이트 빈번
• 안정적인 지연시간

추천: 🥇 Qdrant 1.15

이유:

• ✅ p99 최우수 (18.4ms, 48% 개선)
• ✅ 지연시간 분산 최소화 (일관성)
• ✅ Filterable HNSW로 정확한 필터링
• ✅ 실시간 인덱싱 지원

권장 인프라 구성:

시나리오 3: 대규모 엔터프라이즈 AI 플랫폼

요구사항:

• 100억+ 벡터
• 100,000개 독립 컬렉션 (멀티 테넌시)
• 멀티모달 검색 (텍스트/이미지/오디오)
• 비용 최적화 필수

추천: 🥇 Milvus 2.6

이유:

• ✅ 확장성 최강 (100억+ 벡터, 100K 컬렉션)
• ✅ RaBitQ로 메모리 72% 절감
• ✅ Hot-Cold Storage로 스토리지 50% 절감
• ✅ 멀티모달 네이티브 지원
• ✅ Storage Format V2로 100배 성능 향상

권장 인프라 구성:

시나리오 4: Hybrid Search 중심 서비스

요구사항:

• Dense (의미) + Sparse (키워드) 검색
• BM25 랭킹 필수
• 실시간 인덱싱
• 낮은 운영 복잡도

추천: 🥇 Milvus 2.6 > 🥈 Qdrant 1.15 > 🥉 pgvector

비교:

시나리오 5: 스타트업 MVP / 프로토타입

요구사항:

• 빠른 개발 속도
• 낮은 학습 곡선
• 기존 스택 활용
• 비용 최소화

추천: 🥇 pgvector (PostgreSQL 18)

이유:

• ✅ 설치 5분, 학습 1시간
• ✅ SQL 익숙하면 바로 사용 가능
• ✅ 기존 PostgreSQL 인프라 활용
• ✅ RDS/Supabase로 관리형 서비스
• ✅ 월 $50-500 (프리티어/소규모)

권장 인프라 구성:

9. 마이그레이션 전략

pgvector → Qdrant

마이그레이션 시점 판단:

마이그레이션 프로세스:

권장 배치 크기: 1,000개/배치 (안정성과 속도 균형)

Qdrant → Milvus

마이그레이션 시점 판단:

마이그레이션 프로세스:

권장 배치 크기: 3,000-5,000개/배치 (Milvus 최적화)

10. 결론 및 요약

2025년 현재 상황

각 벡터 데이터베이스는 뚜렷한 강점을 가지며, 단일 "최고" 솔루션은 없다:

빠른 선택 가이드

Q1: 벡터 수는?
  ├─ < 1M     → pgvector
  ├─ 1M-100M  → Qdrant
  └─ > 100M   → Milvus

Q2: 기존 PostgreSQL 사용?
  ├─ Yes → pgvector (통합 용이)
  └─ No  → Q3로

Q3: p99 지연시간 요구사항?
  ├─ < 50ms   → Qdrant
  ├─ < 100ms  → pgvector or Qdrant
  └─ < 200ms  → 모두 가능

Q4: 비용 최적화 중요?
  ├─ Yes → Milvus 2.6 (RaBitQ, Tiered Storage)
  └─ No  → 성능 우선 고려

Q5: 운영 복잡도 허용?
  ├─ 낮음 → pgvector
  ├─ 중간 → Qdrant
  └─ 높음 → Milvus

2025년 트렌드 예측

pgvector:

• PostgreSQL 18 비동기 I/O로 경쟁력 대폭 향상
• PostgreSQL 19에서 추가 최적화 예상
• Supabase 등 관리형 서비스 확대

Qdrant:

• Sparse vector 성능 지속 개선
• Cloud-native 기능 강화
• 엣지 배포 최적화

Milvus:

• GPU 가속 확대
• Streaming 처리 강화
• 자동 튜닝 AI 도입

마지막 조언

"Right tool for the right job"

벡터 데이터베이스 선택은 기술 스택, 팀 역량, 비용, 확장성 요구사항을 종합적으로 고려해야 한다. 다음 질문에 답하면 최적 선택을 찾을 수 있다:

1. 현재 인프라: PostgreSQL 사용 중? → pgvector 우선 검토
2. 벡터 규모: 1M 미만? → pgvector, 100M 이상? → Milvus
3. 지연시간: p99 < 50ms 필수? → Qdrant
4. 비용: 메모리/스토리지 최적화 중요? → Milvus 2.6
5. 팀 역량: SQL 익숙? → pgvector, 분산 시스템 경험? → Milvus

프로토타입부터 시작하라: 실제 워크로드로 벤치마크한 후 결정하는 것이 가장 안전하다.

참고 자료

공식 문서

• pgvector GitHub
• PostgreSQL 18 Release Notes
• Qdrant Documentation
• Milvus 2.6 Release

성능 벤치마크

• Qdrant Benchmarks
• TigerData: pgvector vs Qdrant
• Zilliz: Milvus vs Qdrant

관련 기술

• pgvector-PostgreSQL-Vector-Database-Extension: pgvector 상세 가이드
• RAG+Groq: RAG 시스템 구축
• Hybrid Search: Dense + Sparse 검색 전략
• pgvector 활용 벡터베이스 구현: 실전 프로젝트