pgvector: PostgreSQL에서 벡터 데이터 활용을 위한 실전 가이드
EDB 팀
2025년 9월 8일
1. pgvector란 무엇인가?
pgvector는 PostgreSQL에 벡터 저장, 쿼리, 인덱싱 기능을 더하는 오픈소스 확장입니다. 이를 통해 별도 벡터 데이터베이스 없이 PostgreSQL 내에서 유사도 검색이 가능해집니다
지원 기능은 다음과 같습니다:
- 벡터 데이터 타입: 단정밀도, 반정밀도, 바이너리, 희소 벡터
- 유사도 연산자: L2, Cosine, Inner Product, L1, Hamming, Jaccard 등
- 인덱싱: HNSW 및 IVFFlat 지원
- PostgreSQL의 트랜잭션, JOIN, Point-in-Time Recovery 등의 기능 그대로 활용 가능
2. 개발 실무 적용법 – 설치부터 유사도 쿼리까지
설치 및 초기 설정
CREATE EXTENSION vector;
최근 PostgreSQL 13 이상에서 동작하며, 다양한 패키지 관리자 및 Docker, Homebrew, GitHub Actions를 통해 설치 가능
벡터 칼럼 정의 및 벡터 삽입 예시
CREATE TABLE items (
id SERIAL PRIMARY KEY,
embedding vector(1536)
);
INSERT INTO items (embedding) VALUES ('[0.1,0.2,…,0.1536]');
유사도 쿼리 예시
SELECT * FROM items
ORDER BY embedding <-> '[0.2,0.1,...]'
LIMIT 5;
<->는 L2 거리 기반 순위, <=>는 Cosine, <#>는 Inner Product 연산자입니다
인덱스 기반 최적화
CREATE INDEX ON items USING hnsw (embedding vector_l2_ops);
SET hnsw.ef_search = 100;
IVFFlat도 지원하지만, 데이터 변화가 자주 일어날 경우 HNSW가 업데이트 및 성능 측면에서 유리합니다
3. 벡터DB와 비교: pgvector의 강점과 한계
장점
- 기존 PostgreSQL 인프라 활용 가능 (일괄 저장, JOIN, 트랜잭션 등 그대로 활용)
- 비용 효율적 (오픈소스이며 자체 호스팅 가능)
- pgvectorscale 같은 확장 도구와 함께 사용 시 대규모 벡터워크로드에서도 높은 성능 및 낮은 레이턴시 달성
한계
- PostgreSQL 자체 아키텍처 위에 추가된 솔루션임 → 고부하·복잡한 벡터 워크로드에서는 운영 부담 발생 가능
- Notion 사례처럼 높은 가변 트래픽 상황에서는 튜닝이 복잡하고, 서비스 장애 위험이 있음
4. 언제 pgvector를 선택할까?
적합한 경우:
- 중규모 AI 도입 초기 단계 (추천 엔진, semantic search, RAG)
- 이미 PostgreSQL 기반 시스템이 있고 벡터 저장만 추가적으로 원하는 경우
- 비용과 운영 안정성을 중시하는 경우
차선책 검토 권장:
- 수백만~수억 벡터, 초저지연이 필수적인 서비스 → Pinecone, Qdrant 등 벡터 전용 DB 사용 고려
5. 요약 비교표
| 항목 | pgvector (Postgres) | 전용 벡터DB (e.g. Pinecone) |
|---|---|---|
| 오픈소스/상용 | 오픈소스, 자체 호스팅 가능 | 대부분 상용/Managed 서비스 |
| 인프라 통합성 | PostgreSQL과 완전 통합 | 별도 API/스토리지를 요구 |
| 운영 복잡도 | 직접 관리 필요, 튜닝도 직접 수행 | 관리형으로 운영 부담 낮음 |
| 성능 및 확장성 | pgvectorscale 조합 시 매우 우수 | 규모가 큰 워크로드에 특화 |
| 비용 효율 | 오픈소스 기반, 예측 가능한 비용 | 플랫폼에 따라 비용 상승 가능성 있음 |
