Summary
2025년 현재 주요 벡터 데이터베이스인 pgvector (PostgreSQL 18), Qdrant 1.15, Milvus 2.6의 상세 성능 비교다. PostgreSQL 18의 비동기 I/O는 pgvector의 처리량을 11.4배 향상시켰고, Milvus 2.6은 72% 메모리 절약과 4배 QPS 향상을 달성했으며, Qdrant 1.15는 sparse vector 성능을 16배 개선했다. 각 DB는 뚜렷한 강점을 가지며, 사용 사례에 따라 최적 선택이 달라진다.
테스트 환경 및 버전
비교 대상 버전
| 데이터베이스 | 버전 | 출시일 | 주요 개선 |
|---|---|---|---|
| pgvector | 0.7.0 + PostgreSQL 18 | 2024년 9월 | 비동기 I/O, SIMD 최적화 |
| Qdrant | 1.15.0 | 2025년 8월 | Sparse vector 16배 개선 |
| Milvus | 2.6.0 | 2025년 6월 | 72% 메모리 절약, BM25 |
테스트 사양
하드웨어:
- 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. 데이터 삽입 성능 상세 비교
삽입 속도 벤치마크
| 데이터베이스 | 1M 벡터 | 10M 벡터 | 50M 벡터 | 100M 벡터 |
|---|---|---|---|---|
| Milvus 2.6 | 12.02초 (삽입) + 0.60초 (인덱싱) | ~2분 | ~11분 | ~20분 (예상) |
| Qdrant 1.15 | 41.27초 (삽입) | ~7분 | 3.3시간 (인덱스 구축) | ~6.6시간 (예상) |
| pgvector (PG18) | ~1분 | ~10분 | 11.1시간 (인덱스 구축) | ~22시간 (예상) |
핵심 인사이트:
| 항목 | 1위 | 특징 |
|---|---|---|
| 초기 삽입 | 🥇 Milvus | 분산 아키텍처로 병렬 처리 |
| 인덱싱 속도 | 🥇 Milvus | Streaming Node의 실시간 인덱싱 |
| 중규모 (10M) | 🥇 Milvus | 안정적인 확장성 |
| 대규모 (50M+) | 🥇 Milvus | 엔터프라이즈급 최적화 |
배치 삽입 권장 사항
최적 배치 크기 비교 (1536차원 기준):
| 데이터베이스 | 권장 배치 크기 | 최적 범위 | 주요 고려사항 |
|---|---|---|---|
| Milvus 2.6 | 5,000개 | 3,000-7,000 | Storage Format V2로 98% 파일 감소 |
| Qdrant 1.15 | 3,000개 | 1,000-5,000 | 배치 upsert로 성능 최적화 |
| pgvector (PG18) | 1,000개 | 500-2,000 | COPY 명령어 사용 시 가장 빠름 |
삽입 방식 비교:
| 특성 | Milvus | Qdrant | pgvector |
|---|---|---|---|
| 삽입 방식 | 스트리밍 노드 | 배치 upsert | COPY 또는 INSERT |
| 메모리 효율 | 🥇 우수 (V2) | 🥈 양호 | 🥉 제한적 |
| 동시 삽입 | ✅ 지원 | ✅ 지원 | ⚠️ 제한적 |
PostgreSQL 18 비동기 I/O 효과
삽입 성능 개선:
| 작업 | PostgreSQL 17 | PostgreSQL 18 | 개선율 |
|---|---|---|---|
| Sequential Scan | 100 MB/s | 300 MB/s | 3배 ↑ |
| Bitmap Heap Scan | 50 MB/s | 125 MB/s | 2.5배 ↑ |
| COPY 명령어 | 80K rows/s | 200K rows/s | 2.5배 ↑ |
PostgreSQL 18 설정 권장사항:
| 설정 항목 | 권장값 | 기준 | 용도 |
|---|---|---|---|
| io_method | io_uring | Linux 5.1+ | 비동기 I/O 최적화 |
| shared_buffers | 16GB | RAM의 25% | 공유 메모리 버퍼 |
| work_mem | 256MB | 배치 작업 | 정렬/해시 작업 |
| maintenance_work_mem | 4GB | 인덱스 구축 | 유지보수 작업 |
| max_parallel_workers | 8 | CPU 코어 수 | 병렬 처리 |
2. 검색 성능 비교
검색 속도 벤치마크
100K 벡터, Top-10 검색:
| 메트릭 | pgvector (PG18) | Qdrant 1.15 | Milvus 2.6 |
|---|---|---|---|
| 평균 지연시간 | 12.5ms | 8.3ms | 10.1ms |
| p50 지연시간 | 10.2ms | 7.1ms | 8.5ms |
| p99 지연시간 | 38.7ms | 18.4ms | 32.6ms |
| 처리량 (QPS) | 471 | 287 | 358 |
1M 벡터, Top-10 검색:
| 메트릭 | pgvector (PG18) | Qdrant 1.15 | Milvus 2.6 |
|---|---|---|---|
| 평균 지연시간 | 45ms | 28ms | 35ms |
| p99 지연시간 | 120ms | 75ms | 95ms |
| 처리량 (QPS) | 185 | 312 | 245 |
핵심 인사이트
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 벡터):
| 설정 | 검색 시간 | Recall@10 | 메모리 사용 |
|---|---|---|---|
| m=8, ef_construction=64 | 15ms | 0.92 | 2.1GB |
| m=16, ef_construction=64 | 25ms | 0.96 | 3.8GB |
| m=32, ef_construction=128 | 42ms | 0.98 | 7.2GB |
| m=64, ef_construction=256 | 78ms | 0.99 | 14.5GB |
권장 설정:
- 일반:
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로 복잡한 필터를 직관적으로 표현한다:
| 필터 유형 | 조건 예시 | 설명 |
|---|---|---|
| 완전 일치 | category = “electronics” | 특정 값과 정확히 일치 |
| 범위 검색 | price >= 100 AND price ⇐ 1000 | 수치 범위 필터링 |
| 불린 필터 | in_stock = True | 참/거짓 조건 |
| 다중 조건 | must=[조건1, 조건2, 조건3] | AND 연산으로 결합 |
Milvus 2.6 JSON Path Index
100배 빠른 필터링:
Milvus 2.6의 JSON Path Index는 혁신적인 성능 개선을 가져왔다:
- 99% 지연시간 감소: 복잡한 JSON 필터링에서 획기적 개선
- 자동 경로 발견: 스키마 변경 시 자동으로 새 필드 인덱싱
- 동적 필드 지원: 사전 정의 없이 JSON 필드 쿼리 가능
JSON Path 필터 표현식:
Milvus 2.6은 SQL-like 표현식으로 JSON 필드를 직접 쿼리한다:
| 필터 유형 | 표현식 예시 | 특징 |
|---|---|---|
| 중첩 필드 접근 | metadata[“category”] | JSON 경로로 직접 접근 |
| 복합 조건 | category == “electronics” AND price > 100 | SQL-like 문법 |
| 자동 인덱싱 | 스키마 변경 시 자동 발견 | 사전 정의 불필요 |
필터링 성능 비교
벤치마크 (1M 벡터, 10% 필터링):
| 필터링 유형 | Qdrant 1.15 | Milvus 2.6 | pgvector (PG18) |
|---|---|---|---|
| 단일 메타데이터 | 12ms | 15ms | 18ms |
| 범위 검색 | 18ms | 22ms | 14ms |
| 복합 조건 (3개) | 15ms | 28ms | 25ms |
| JSON 중첩 필드 | 25ms | 18ms | 35ms |
| 지리적 검색 | 32ms | 45ms | 12ms (PostGIS) |
필터링 기능 비교
| 필터링 유형 | Qdrant | Milvus | pgvector |
|---|---|---|---|
| 메타데이터 필터 | 🥇 최우수 (전용 인덱스) | 🥈 우수 (JSON Path Index) | 🥉 양호 (SQL WHERE) |
| 범위 검색 | 🥈 우수 | 🥈 우수 | 🥇 최우수 (B-tree) |
| 복합 조건 | 🥇 최우수 (DSL 최적화) | 🥉 양호 | 🥇 최우수 (SQL 활용) |
| 지리적 검색 | 🥈 지원 | 🥉 제한적 | 🥇 완전 지원 (PostGIS) |
| 시계열 필터 | 🥉 수동 구현 | 🥉 수동 구현 | 🥇 완전 지원 (TimescaleDB) |
4. 고급 검색 기능 비교
Qdrant의 고급 검색 기능
Similarity Search를 넘어서:
| 기능 | 설명 | 사용 케이스 |
|---|---|---|
| Dissimilarity Search | 가장 다른 항목 찾기 | 이상치 탐지, 다양성 확보 |
| Diversity Search | 다양성을 고려한 검색 | 추천 시스템 (필터 버블 방지) |
| Discovery Functions | 새로운 패턴 발견 | 탐색적 검색, 트렌드 분석 |
| Multi-vector Search | 여러 벡터 동시 검색 | 멀티모달 검색 |
| Context Search | 양/음 예제 기반 검색 | 세밀한 검색 조정 |
검색 방식 설명:
| 검색 유형 | 핵심 아이디어 | 구현 방법 |
|---|---|---|
| Dissimilarity | 가장 다른 항목 찾기 | 낮은 유사도 임계값 설정 |
| Discovery | 양/음 예제 기반 탐색 | positive/negative 벡터로 방향 조정 |
| Context | 세밀한 검색 조정 | 선호/비선호 예제로 검색 개선 |
Milvus 2.6의 고급 기능
Hybrid Search 혁신:
| 기능 | 성능 | 설명 |
|---|---|---|
| BM25 + Vector | Elasticsearch 대비 4배 빠름 | 텍스트 + 의미 검색 통합 |
| Multi-modal Search | 교차 검색 지원 | 텍스트/이미지/오디오 통합 |
| Time-aware Search | 시간 가중 검색 | 최신 콘텐츠 우선 순위 |
| Range Search | 유사도 임계값 | 특정 유사도 이상 모두 반환 |
| Grouping Search | 그룹별 정리 | 카테고리별 결과 제한 |
Hybrid Search 구성:
Milvus 2.6은 Dense + Sparse 검색을 네이티브로 지원한다:
| 검색 단계 | 유형 | 역할 | 결과 수 |
|---|---|---|---|
| 1단계 | Dense Search | 의미적 유사성 (벡터) | Top 20 |
| 2단계 | Sparse Search | 키워드 매칭 (BM25) | Top 20 |
| 3단계 | RRF Reranker | 결과 융합 및 재정렬 | Top 10 |
RRF (Reciprocal Rank Fusion) 방식:
- 두 검색 결과를 순위 기반으로 결합
- 점수 정규화 없이 자동 융합
- Elasticsearch 대비 4배 빠른 성능
pgvector의 SQL 기반 고급 검색
PostgreSQL 생태계 활용:
| 기능 | 설명 | 확장 |
|---|---|---|
| Hybrid Search | FTS + 벡터 | PostgreSQL FTS |
| Geospatial Search | 위치 기반 검색 | PostGIS |
| Time-series Search | 시계열 검색 | TimescaleDB |
| Full-text Search | 다국어 FTS | PostgreSQL FTS |
| Analytical Search | 집계 + 벡터 | SQL 윈도우 함수 |
고급 검색 패턴:
pgvector는 PostgreSQL의 강력한 SQL 기능을 모두 활용할 수 있다:
| 검색 패턴 | 조합 | 활용 예시 |
|---|---|---|
| 지리적 검색 | PostGIS + pgvector | 5km 이내 + 유사도 > 0.7 |
| 시계열 분석 | TimescaleDB + pgvector | 최근 7일 + 시간대별 집계 |
| 관계형 조인 | JOIN + pgvector | 사용자 프로필 + 선호도 벡터 |
| 윈도우 함수 | RANK() + pgvector | 카테고리별 Top-N 추천 |
장점:
- SQL 표준 문법으로 복잡한 쿼리 작성
- 여러 확장(PostGIS, TimescaleDB)과 자유롭게 결합
- 트랜잭션 내에서 벡터 검색 + 비즈니스 로직 통합
5. 2025년 주요 업데이트 영향
PostgreSQL 18의 비동기 I/O 혁명
io_uring 통합의 임팩트:
PostgreSQL 18은 Linux의 io_uring을 완전히 통합하여 I/O 성능을 혁신적으로 개선했다.
성능 개선 수치:
| 작업 | 기존 (PG 17) | PG 18 (AIO) | 개선율 |
|---|---|---|---|
| Sequential Scan | 100 MB/s | 300 MB/s | 3배 ↑ |
| Bitmap Heap Scan | 50 MB/s | 125 MB/s | 2.5배 ↑ |
| VACUUM | 20 MB/s | 60 MB/s | 3배 ↑ |
| Index Scan | 15K rows/s | 35K rows/s | 2.3배 ↑ |
플랫폼별 최적 설정:
| 플랫폼 | io_method 설정 | 특징 |
|---|---|---|
| Linux 5.1+ | io_uring | 최고 성능, io_uring 커널 지원 |
| 다른 플랫폼 | worker | 기본값, 모든 플랫폼 호환 |
| macOS/Windows | worker | io_uring 미지원 시 자동 대체 |
pgvector에 미치는 영향:
- Bitmap Heap Scan: HNSW 인덱스 후 실제 데이터 접근 시 2-3배 빠름
- Sequential Scan: 인덱스 없는 벡터 테이블 스캔 3배 개선
- VACUUM: 벡터 테이블 유지보수 속도 향상
Milvus 2.6의 게임 체인저
Storage Format V2:
| 개선 항목 | 효과 |
|---|---|
| 성능 | 100배 향상 (특정 워크로드) |
| 파일 수 | 98% 감소 (관리 용이) |
| 스토리지 효율 | 압축률 향상 |
RaBitQ 1-bit 압축:
| 메트릭 | 기존 | RaBitQ | 개선 |
|---|---|---|---|
| 메모리 | 10GB | 2.8GB | 72% 절감 |
| QPS | 1000 | 4000 | 4배 향상 |
| Recall@10 | 0.98 | 0.96 | -2% (허용) |
Hot-Cold Tiered Storage 전략:
| 데이터 유형 | 스토리지 | 보관 기간 | 액세스 패턴 |
|---|---|---|---|
| Hot Data | SSD (NVMe) | 최근 30일 | 빈번한 검색 |
| Cold Data | S3 (Object) | 30일 이상 | 가끔 검색 |
| Archive | Glacier | 90일 이상 | 거의 없음 |
비용 효과:
| 항목 | 기존 | Milvus 2.6 | 절감율 |
|---|---|---|---|
| 스토리지 비용 | $1,000/월 | $500/월 | 50% ↓ |
| 메모리 비용 | $2,800/월 | $784/월 | 72% ↓ |
| 컴퓨팅 비용 | $4,000/월 | $1,000/월 | 75% ↓ |
Qdrant 1.15의 성능 개선
Sparse Vector 16배 향상:
Hybrid Search의 핵심인 sparse vector 성능이 획기적으로 개선되었다.
| 작업 | Qdrant 1.14 | Qdrant 1.15 | 개선율 |
|---|---|---|---|
| Sparse 인덱싱 | 320ms | 20ms | 16배 ↑ |
| Sparse 검색 | 45ms | 8ms | 5.6배 ↑ |
| Hybrid Search | 95ms | 28ms | 3.4배 ↑ |
Mutable Map Index 특징:
| 특성 | 설명 | 장점 |
|---|---|---|
| 실시간 업데이트 | 인덱스 재구축 없이 즉시 반영 | 빈번한 업데이트 가능 |
| 메모리 상주 | 인덱스를 RAM에 보관 | 빠른 액세스 |
| 동적 구조 | 맵 기반 유연한 구조 | 스키마 변경 용이 |
BM25 Local Inference 장점:
Qdrant 1.15는 자체 BM25 처리로 외부 의존성을 제거했다:
| 개선 항목 | 효과 |
|---|---|
| 지연시간 | 외부 호출 불필요로 50% 감소 |
| 운영 복잡도 | 별도 검색 엔진 불필요 |
| 데이터 일관성 | 단일 DB에서 처리로 동기화 문제 없음 |
| 비용 | Elasticsearch 등 추가 서비스 불필요 |
6. 확장성 비교
수평 확장 능력
| 데이터베이스 | 최대 벡터 수 | 클러스터링 | 샤딩 | 복제 |
|---|---|---|---|---|
| Milvus 2.6 | 100억+ | ✅ 네이티브 | ✅ 자동 | ✅ 다중 복제본 |
| Qdrant 1.15 | 10억+ | ✅ 네이티브 | ✅ 수동 | ✅ 다중 복제본 |
| pgvector (PG18) | 수백만 | ⚠️ 제한적 (Citus 필요) | ⚠️ 수동 (Citus/Patroni) | ✅ Streaming Replication |
멀티 테넌시
Milvus 2.6의 혁신:
| 메트릭 | Milvus 2.5 | Milvus 2.6 | 개선 |
|---|---|---|---|
| 최대 컬렉션 | 10,000 | 100,000 | 10배 ↑ |
| 컬렉션 생성 | 2초 | 0.2초 | 10배 ↑ |
| 메타데이터 오버헤드 | 100KB | 10KB | 90% ↓ |
멀티 테넌시 구성 방식:
| 방식 | 설명 | 장점 | 단점 |
|---|---|---|---|
| 컬렉션 분리 | 테넌트마다 독립 컬렉션 | 완전한 격리, 관리 용이 | Milvus만 대규모 지원 |
| 파티션 분리 | 하나의 컬렉션, 테넌트별 파티션 | 메타데이터 오버헤드 적음 | 제한적 격리 |
| 필터 기반 | metadata[“tenant_id”] 필터링 | 단순한 구조 | 격리 불가 |
수직 확장 효율성
메모리 사용량 (100M 벡터, 1536차원):
| 데이터베이스 | 최소 RAM | 권장 RAM | RaBitQ/압축 적용 시 |
|---|---|---|---|
| Milvus 2.6 | 180GB | 256GB | 50GB (72% 절감) |
| Qdrant 1.15 | 200GB | 320GB | - |
| pgvector (PG18) | 240GB | 384GB | - |
7. 운영 복잡도 비교
설치 및 설정
| 단계 | pgvector | Qdrant | Milvus |
|---|---|---|---|
| 설치 시간 | 5분 | 10분 | 30분+ |
| 설정 복잡도 | 🟢 낮음 | 🟡 중간 | 🔴 높음 |
| 의존성 | PostgreSQL만 | Docker | Etcd, MinIO, Pulsar 등 |
| 클라우드 배포 | 🟢 간단 | 🟢 간단 | 🟡 복잡 |
설치 단계 비교:
| 데이터베이스 | 설치 방법 | 주요 단계 수 | 의존성 |
|---|---|---|---|
| pgvector | brew/apt + make | 3단계 | PostgreSQL만 |
| Qdrant | Docker 단일 컨테이너 | 2단계 | Docker만 |
| Milvus | Kubernetes Helm | 10+ 단계 | Etcd, MinIO, Pulsar |
관리형 서비스 옵션:
| 데이터베이스 | 관리형 서비스 | 특징 |
|---|---|---|
| pgvector | AWS RDS, Supabase, Neon | PostgreSQL 호환 서비스 모두 사용 가능 |
| Qdrant | Qdrant Cloud | 공식 관리형, 자동 스케일링 |
| Milvus | Zilliz Cloud | 공식 관리형, 엔터프라이즈 기능 |
모니터링 및 유지보수
| 항목 | pgvector | Qdrant | Milvus |
|---|---|---|---|
| 모니터링 도구 | pgAdmin, pg_stat | Qdrant UI, Prometheus | Milvus UI, Grafana |
| 백업 | pg_dump | Qdrant Snapshot | Milvus Backup |
| 업그레이드 | pg_upgrade | In-place | Rolling Update |
| 학습 곡선 | 🟢 낮음 (SQL 익숙) | 🟡 중간 (새 API) | 🔴 높음 (분산 시스템) |
비용 분석 (월간, 100M 벡터 기준)
AWS 기준 추정:
| 항목 | pgvector (RDS) | Qdrant (ECS) | Milvus (EKS) |
|---|---|---|---|
| 컴퓨팅 | $2,000 (r6i.8xlarge) | $2,500 (8xlarge 2대) | $4,000 (클러스터 5노드) |
| 스토리지 | $500 (1TB EBS) | $600 (1.2TB EBS) | $250 (S3 Tiered) |
| 운영 인력 | 0.5 FTE ($5,000) | 1 FTE ($10,000) | 2 FTE ($20,000) |
| 월 합계 | $7,500 | $13,100 | $24,250 |
비용 최적화 팁:
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 조인/집계로 복잡한 쿼리 간편
권장 인프라 구성:
| 구성 요소 | 스펙 | 역할 |
|---|---|---|
| Primary DB | r6i.8xlarge (256GB RAM) | 쓰기 + 읽기 |
| Read Replicas | r6i.4xlarge × 5대 | 읽기 분산 |
| Connection Pool | PgBouncer | 연결 관리 |
| 예상 비용 | $7,500/월 | AWS 기준 |
시나리오 2: 실시간 응답 중요 서비스
요구사항:
- p99 < 50ms (엄격)
- 복잡한 메타데이터 필터링
- 실시간 업데이트 빈번
- 안정적인 지연시간
추천: 🥇 Qdrant 1.15
이유:
- ✅ p99 최우수 (18.4ms, 48% 개선)
- ✅ 지연시간 분산 최소화 (일관성)
- ✅ Filterable HNSW로 정확한 필터링
- ✅ 실시간 인덱싱 지원
권장 인프라 구성:
| 구성 요소 | 스펙 | 역할 |
|---|---|---|
| Cluster Nodes | c6i.4xlarge × 3 | 클러스터 구성 |
| 복제본 | 3개 replica | 고가용성 보장 |
| 모니터링 | Prometheus + Grafana | 성능 추적 |
| 예상 비용 | $13,100/월 | AWS 기준 |
시나리오 3: 대규모 엔터프라이즈 AI 플랫폼
요구사항:
- 100억+ 벡터
- 100,000개 독립 컬렉션 (멀티 테넌시)
- 멀티모달 검색 (텍스트/이미지/오디오)
- 비용 최적화 필수
추천: 🥇 Milvus 2.6
이유:
- ✅ 확장성 최강 (100억+ 벡터, 100K 컬렉션)
- ✅ RaBitQ로 메모리 72% 절감
- ✅ Hot-Cold Storage로 스토리지 50% 절감
- ✅ 멀티모달 네이티브 지원
- ✅ Storage Format V2로 100배 성능 향상
권장 인프라 구성:
| 구성 요소 | 스펙 | 역할 |
|---|---|---|
| Query Nodes | c6i.8xlarge × 5 | 검색 처리 |
| Data Nodes | r6i.4xlarge × 3 | 데이터 저장 |
| Cold Storage | S3 (Tiered) | 비용 최적화 |
| 압축 | RaBitQ 활성화 | 메모리 72% 절감 |
| 예상 비용 | $15,000/월 | AWS EKS 기준 (최적화 후) |
시나리오 4: Hybrid Search 중심 서비스
요구사항:
- Dense (의미) + Sparse (키워드) 검색
- BM25 랭킹 필수
- 실시간 인덱싱
- 낮은 운영 복잡도
추천: 🥇 Milvus 2.6 > 🥈 Qdrant 1.15 > 🥉 pgvector
비교:
| 항목 | Milvus 2.6 | Qdrant 1.15 | pgvector |
|---|---|---|---|
| BM25 성능 | 🥇 Elasticsearch 대비 4배 | 🥈 Local Inference | 🥉 FTS (양호) |
| Sparse 성능 | 🥈 우수 | 🥇 16배 개선 | 🥉 GIN 인덱스 |
| RRF 지원 | ✅ 네이티브 | ✅ 수동 구현 | ✅ SQL로 구현 |
| 실시간 인덱싱 | ✅ Streaming Node | ✅ 네이티브 | ⚠️ VACUUM 필요 |
시나리오 5: 스타트업 MVP / 프로토타입
요구사항:
- 빠른 개발 속도
- 낮은 학습 곡선
- 기존 스택 활용
- 비용 최소화
추천: 🥇 pgvector (PostgreSQL 18)
이유:
- ✅ 설치 5분, 학습 1시간
- ✅ SQL 익숙하면 바로 사용 가능
- ✅ 기존 PostgreSQL 인프라 활용
- ✅ RDS/Supabase로 관리형 서비스
- ✅ 월 $50-500 (프리티어/소규모)
권장 인프라 구성:
| 구성 요소 | 스펙 | 특징 |
|---|---|---|
| 플랫폼 | Supabase | 관리형 PostgreSQL |
| 플랜 | 무료 or $25/월 | 500MB DB |
| 기능 | pgvector 기본 포함 | 추가 설정 불필요 |
| 백업 | 자동 백업/복제 | 데이터 안전성 |
| API | REST API 자동 생성 | 빠른 개발 |
9. 마이그레이션 전략
pgvector → Qdrant
마이그레이션 시점 판단:
| 지표 | 임계값 | 조치 |
|---|---|---|
| 벡터 수 | > 10M | Qdrant 고려 |
| p99 지연시간 | > 100ms | Qdrant 고려 |
| 필터링 복잡도 | 3개 이상 조건 | Qdrant 고려 |
| 동시 업데이트 | 초당 1000+ | Qdrant 필수 |
마이그레이션 프로세스:
| 단계 | 작업 | 예상 시간 |
|---|---|---|
| 1단계 | Qdrant 컬렉션 생성 | 1분 |
| 2단계 | pgvector에서 데이터 읽기 | 벡터 수에 따라 |
| 3단계 | 배치로 Qdrant에 삽입 | 1M당 ~2분 |
| 4단계 | 검증 및 인덱스 최적화 | 10-30분 |
권장 배치 크기: 1,000개/배치 (안정성과 속도 균형)
Qdrant → Milvus
마이그레이션 시점 판단:
| 지표 | 임계값 | 조치 |
|---|---|---|
| 벡터 수 | > 100M | Milvus 고려 |
| 멀티모달 | 텍스트+이미지+오디오 | Milvus 필수 |
| 메모리 비용 | 월 $10,000+ | Milvus RaBitQ 고려 |
| 스토리지 비용 | 월 $5,000+ | Milvus Tiered Storage 고려 |
마이그레이션 프로세스:
| 단계 | 작업 | 예상 시간 | 주의사항 |
|---|---|---|---|
| 1단계 | Milvus 클러스터 구성 | 1-2시간 | Kubernetes 필요 |
| 2단계 | 스키마 설계 및 컬렉션 생성 | 30분 | JSON 필드 매핑 |
| 3단계 | Qdrant Scroll API로 읽기 | 벡터 수에 따라 | 메모리 관리 필요 |
| 4단계 | Milvus 배치 삽입 | 10M당 ~20분 | Storage V2 활용 |
| 5단계 | 인덱스 구축 및 검증 | 1-3시간 | HNSW 파라미터 튜닝 |
권장 배치 크기: 3,000-5,000개/배치 (Milvus 최적화)
10. 결론 및 요약
2025년 현재 상황
각 벡터 데이터베이스는 뚜렷한 강점을 가지며, 단일 “최고” 솔루션은 없다:
| 데이터베이스 | 핵심 강점 | 최적 사용 사례 |
|---|---|---|
| pgvector (PostgreSQL 18) | • 처리량 최강 (471 QPS) • SQL 통합 • 운영 단순 | • 기존 PostgreSQL 사용 • 복잡한 SQL 조인 • 스타트업/MVP |
| Qdrant 1.15 | • p99 최우수 (18.4ms) • 일관된 지연시간 • 필터링 최강 | • 실시간 서비스 • 안정적 응답 필요 • 복잡한 필터링 |
| Milvus 2.6 | • 확장성 최강 (100억+) • 72% 메모리 절감 • 멀티모달 지원 | • 엔터프라이즈급 • 비용 최적화 • 대규모 멀티 테넌시 |
빠른 선택 가이드
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”
벡터 데이터베이스 선택은 기술 스택, 팀 역량, 비용, 확장성 요구사항을 종합적으로 고려해야 한다. 다음 질문에 답하면 최적 선택을 찾을 수 있다:
- 현재 인프라: PostgreSQL 사용 중? → pgvector 우선 검토
- 벡터 규모: 1M 미만? → pgvector, 100M 이상? → Milvus
- 지연시간: p99 < 50ms 필수? → Qdrant
- 비용: 메모리/스토리지 최적화 중요? → Milvus 2.6
- 팀 역량: SQL 익숙? → pgvector, 분산 시스템 경험? → Milvus
프로토타입부터 시작하라: 실제 워크로드로 벤치마크한 후 결정하는 것이 가장 안전하다.
참고 자료
공식 문서
성능 벤치마크
관련 기술
- pgvector-PostgreSQL-Vector-Database-Extension: pgvector 상세 가이드
- RAG+Groq: RAG 시스템 구축
- Hybrid Search: Dense + Sparse 검색 전략
- pgvector 활용 벡터베이스 구현: 실전 프로젝트