pgvector vs Pinecone vs Milvus: 아키텍처 비교와 상황별 벡터 데이터베이스 선택 가이드

검색 증강 생성(RAG) 시스템이나 추천 엔진을 설계할 때 가장 먼저 결정해야 하는 인프라는 고차원 임베딩을 저장하고 검색할 벡터 데이터베이스(Vector Database)다. 시중에는 완전 관리형 SaaS부터 오픈소스 독립형 엔진, 기존 관계형 데이터베이스의 확장 기능까지 다양한 솔루션이 존재해 기술적 선택이 쉽지 않다.

그중에서도 pgvector, Pinecone, Milvus는 각각 RDBMS 확장, 완전 관리형 클라우드, 엔터프라이즈 분산 클러스터를 대표하는 3대 솔루션이다. 벡터 임베딩 코사인 유사도의 개념과 하이브리드 검색 파이프라인에서 설명했듯이, 데이터베이스가 지원하는 인덱싱 알고리즘과 메타데이터 필터링 구조는 RAG 시스템의 검색 지연 시간(P99)과 시스템 복잡도를 완전히 좌우한다. 이 글에서는 세 솔루션의 아키텍처 특성과 쿼리 구현, 그리고 프로젝트 상황별 선택 기준을 비교 정리한다.

벡터 데이터베이스 3대 아키텍처 비교표

각 솔루션의 호스팅 방식, 지원 인덱스, 최대 권장 규모 및 운영 비용 구조를 비교하면 다음과 같다.

솔루션별 아키텍처 특성과 DDL 구현 코드

각 시스템이 벡터 데이터를 적재하고 질의하는 방식은 엔지니어링 패러다임에 따라 확연히 다르다.

1. pgvector: 관계형 테이블과 벡터 인덱스의 결합

pgvector의 가장 큰 장점은 기존 비즈니스 엔터티(users, documents, tenants)와 벡터 데이터를 동일한 트랜잭션 경계 안에서 관리할 수 있다는 점이다.

-- pgvector 확장 활성화 및 테이블 정의
CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE document_sections (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    tenant_id VARCHAR(50) NOT NULL,
    content TEXT NOT NULL,
    embedding vector(1536), -- OpenAI text-embedding-3-small 차원
    created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW()
);

-- HNSW 인덱스 생성 (코사인 거리 연산자 vector_cosine_ops 적용)
CREATE INDEX idx_document_sections_embedding 
ON document_sections 
USING hnsw (embedding vector_cosine_ops) 
WITH (m = 16, ef_construction = 64);

-- 메타데이터 필터링과 벡터 유사도 정렬이 결합된 하이브리드 검색
SELECT id, content, 1 - (embedding <=> '[0.012, -0.045, ...]'::vector) AS cosine_similarity
FROM document_sections
WHERE tenant_id = 'org_enterprise_102'
ORDER BY embedding <=> '[0.012, -0.045, ...]'::vector
LIMIT 5;

2. Pinecone: 간결한 서버리스 API 호출

Pinecone은 복잡한 데이터베이스 튜닝 없이 클라이언트 SDK를 통해 네임스페이스 격리와 메타데이터 필터링을 즉시 수행할 수 있다.

from pinecone import Pinecone

pc = Pinecone(api_key="YOUR_API_KEY")
index = pc.Index("enterprise-knowledge")

# 메타데이터 필터링을 포함한 벡터 질의
query_response = index.query(
    namespace="tenant_102",
    vector=[0.012, -0.045, ...],
    top_k=5,
    include_metadata=True,
    filter={"category": {"$in": ["finance", "audit"]}}
)

for match in query_response['matches']:
    print(f"ID: {match['id']}, 점수: {match['score']}, 텍스트: {match['metadata']['text']}")

3. Milvus: 대규모 파티셔닝과 스키마 컬렉션

Milvus는 gRPC 프로토콜을 기반으로 분산 샤딩과 메모리-디스크 계층형 캐싱(DiskANN)을 지원한다.

from pymilvus import Collection, DataType, FieldSchema, CollectionSchema

fields = [
    FieldSchema(name="id", dtype=DataType.INT64, is_primary=True, auto_id=True),
    FieldSchema(name="org_id", dtype=DataType.VARCHAR, max_length=64),
    FieldSchema(name="vector", dtype=DataType.FLOAT_VECTOR, dim=1536)
]
schema = CollectionSchema(fields, description="대규모 기업 문서 지식 베이스")
collection = Collection("corp_docs", schema)

# HNSW 인덱스 빌드 설정
index_params = {
    "metric_type": "COSINE",
    "index_type": "HNSW",
    "params": {"M": 16, "efConstruction": 64}
}
collection.create_index(field_name="vector", index_params=index_params)

인덱싱 알고리즘: HNSW와 IVFFlat의 성능 트레이드오프

벡터 데이터베이스 성능의 핵심은 인덱싱 알고리즘의 선택이다.

• HNSW (Hierarchical Navigable Small World): 다층 그래프 구조를 형성해 최단 경로로 근사 최근접 이웃(ANN)을 탐색한다. 검색 재현율(Recall)이 95~99%에 달하고 지연 시간이 수 밀리초에 불과하지만, 인덱스 생성 시 메모리(RAM)를 많이 소모한다.
• IVFFlat (Inverted File Flat): 공간을 여러 개의 클러스터(보로노이 다이어그램)로 분할한 뒤 역색인 목록을 탐색한다. 메모리 사용량이 HNSW 대비 1/3 수준으로 적지만, 검색 정확도가 다소 떨어지고 인덱스 튜닝(lists, probes)이 까다롭다.

현재 pgvector 0.7+ 버전부터 HNSW가 완벽히 안정화되었으므로, 메모리가 허용되는 한 모든 실무 환경에서는 HNSW 인덱스를 우선 적용하는 것이 권장된다.

프로젝트 규모와 팀 역량에 따른 상황별 의사결정 트리

팀의 현황에 맞춘 가장 합리적인 선택 기준은 다음과 같다.

1. 상황 A: 서비스 주 데이터베이스가 이미 PostgreSQL인 경우 → pgvector 우선 도입
   • 별도의 벡터 전용 DB를 프로비저닝할 필요 없이 단일 DB에서 RLS 보안, 트랜잭션, 데이터 동기화를 모두 처리할 수 있다. 벡터 규모가 1,000만 건 이하인 90% 이상의 일반 상용 서비스에서는 pgvector로 충분하다.
2. 상황 B: 인프라 운영팀이 없고 빠른 런칭이 필요한 경우 → Pinecone 선택
   • 인덱스 튜닝, 서버 용량 증설(Sharding), 백업 등을 신경 쓸 여력이 없는 소규모 스타트업이나 신속한 PoC 프로젝트에 최적이다.
3. 상황 C: 사내 온프레미스 망분리 또는 1억 건 이상의 대규모 데이터 → Milvus 구축
   • 클라우드 SaaS로 외부 반출이 불가능한 금융/의료 데이터이거나, 글로벌 사용자 대상 수십억 건의 벡터 검색을 비용 효율적으로 처리해야 하는 엔터프라이즈 환경에 적합하다.

프로덕션 도입 시 고려해야 할 데이터 마이그레이션과 벤더 락인

벡터 데이터베이스를 도입할 때는 추후 임베딩 모델 교체(예: OpenAI text-embedding-ada-002에서 text-embedding-3-large로 이전) 시 발생할 전체 재색인(Reindexing) 비용을 반드시 염두에 두어야 한다.

벡터 데이터만 보관하고 원본 텍스트나 고유 식별자를 외부 DB에 흩뿌려 두면, 모델 이전 시 두 시스템 간의 동기화 실패로 데이터 무결성이 깨지기 쉽다. 원본 청크 텍스트와 메타데이터가 단일 원천(Single Source of Truth)으로 철저히 버전 관리되고 있는지 확인해야 기술 부채를 방어할 수 있다.