PostgreSQL pgvector로 설계하는 HNSW·IVFFlat 벡터 검색

PostgreSQL은 2026년 DB-Engines 순위 1위를 유지하고 있으며, 개발자 사용률은 55.6%로 MySQL의 40.5%보다 15%p 이상 높다. JSON/JSONB, 시계열, PostGIS에 이어 벡터 검색까지 한 데이터베이스에서 처리할 수 있게 되면서, pgvector는 RAG를 기존 PostgreSQL 운영 체계 안에 넣는 선택지가 됐다.

AWS RDS for PostgreSQL, Azure Database for PostgreSQL, Google Cloud SQL for PostgreSQL도 pgvector를 공식 지원한다. 별도의 벡터 데이터베이스를 늘리지 않고도 기존 데이터와 임베딩을 같은 환경에서 관리할 수 있다는 점이 핵심이다.

pgvector 2.0에서 달라진 인덱스와 타입

pgvector 0.8.x를 거쳐 2026년 기준으로 안정화된 pgvector 2.0에서는 HNSW가 권장 기본값으로 자리 잡았다. 병렬 인덱스 빌드도 개선돼 멀티코어 환경에서 HNSW 구축 시간이 대폭 단축됐다.

halfvec, sparsevec 타입을 통한 양자화 지원은 메모리 효율을 높이면서 검색 정확도를 유지하는 데 쓰인다. WHERE 조건과 벡터 검색을 함께 쓰는 하이브리드 쿼리의 실행 계획도 개선됐다.

삽입 패턴과 운영 제약으로 인덱스 고르기

HNSW와 IVFFlat은 모두 pgvector의 벡터 인덱스지만, 맞는 워크로드가 다르다. 실시간 삽입량, 메모리 여유, 읽기 비중, 배포 방식부터 확인해야 한다.

⤢✕

읽기 중심 환경에 맞는 HNSW

HNSW는 계층형 그래프로 벡터를 연결한다. 검색할 때는 상위 레이어에서 시작해 하위 레이어로 이동하며 가까운 이웃을 찾는다. 2026년 pgvector에서는 기본 인덱스 타입으로 쓰인다.

평균 쿼리 레이턴시는 고 recall 기준 2-6ms다. 데이터가 없는 상태에서도 인덱스를 만들 수 있어, CI/CD나 블루/그린 배포에서 스키마를 먼저 적용하고 이후 데이터를 넣는 흐름을 지원한다. 반면 IVFFlat보다 인덱스 생성 시간이 길고 메모리를 더 소비한다.

주요 조정 지점은 인덱스 빌드 품질을 정하는 hnsw.ef_construction과 런타임 검색 범위를 정하는 hnsw.ef다.

-- HNSW 인덱스 생성 예시
CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 64);

-- 런타임 검색 범위 조정 (세션 단위)
SET hnsw.ef = 100;

-- 코사인 유사도 기반 벡터 검색
SELECT id, title, 1 - (embedding <=> '[0.1, 0.2, ...]') AS similarity
FROM documents
ORDER BY embedding <=> '[0.1, 0.2, ...]'
LIMIT 10;

빠른 빌드와 삽입에 유리한 IVFFlat

IVFFlat은 벡터 공간을 k-means 클러스터링으로 분할한 뒤, 검색 시 가까운 클러스터만 대상으로 삼는다. probes 값에 따라 쿼리 레이턴시는 2-10ms 범위에서 달라진다.

인덱스 빌드는 빠르고 메모리 사용량은 적다. 다만 인덱스를 만들기 전에 데이터가 있어야 하며, 최소 수천 건의 레코드가 필요하다. 초당 수십만 건 규모의 대규모 실시간 삽입 환경에서는 이 특성이 유리하다. lists는 클러스터 수를, ivfflat.probes는 검색할 클러스터 수를 제어한다.

-- IVFFlat 인덱스 생성 예시 (100만 행 기준 lists=1000)
CREATE INDEX ON documents USING ivfflat (embedding vector_cosine_ops)
WITH (lists = 1000);

-- 검색 정확도/속도 트레이드오프 조정
SET ivfflat.probes = 10;

-- 벡터 검색 (L2 거리)
SELECT id, title, embedding <-> '[0.1, 0.2, ...]' AS distance
FROM documents
ORDER BY embedding <-> '[0.1, 0.2, ...]'
LIMIT 10;

인덱스 파라미터는 검색 품질, 레이턴시, 빌드 시간, 메모리 사용량의 균형을 정한다.

구분	파라미터	기본값	권장 범위	효과
HNSW	`m`	16	8-64	그래프 연결 수, 높을수록 recall↑ 메모리↑
HNSW	`ef_construction`	64	32-200	빌드 품질, 높을수록 정확↑ 빌드 시간↑
HNSW	`hnsw.ef`	40	40-200	런타임 검색 범위, 높을수록 recall↑ 레이턴시↑
IVFFlat	`lists`	100	sqrt(n)~n/10	클러스터 수
IVFFlat	`ivfflat.probes`	1	1-lists/10	검색할 클러스터 수, 높을수록 recall↑

PostgreSQL 안에서 구성하는 RAG 검색 경로

RAG는 LLM의 hallucination을 줄이고 최신 정보를 주입하기 위한 아키텍처 패턴이다. pgvector를 사용하면 문서 청크, 메타데이터, 임베딩 검색을 PostgreSQL에서 함께 다룰 수 있다.

⤢✕

문서 청크 테이블에는 원문, 메타데이터, 임베딩을 함께 저장하고, 검색 대상 임베딩에는 HNSW 인덱스를 둔다. 메타데이터에는 GIN 인덱스를 별도로 둬 하이브리드 검색에 사용한다.

-- pgvector 확장 설치
CREATE EXTENSION IF NOT EXISTS vector;

-- 문서 청크 테이블 (text-embedding-3-small 기준 1536차원)
CREATE TABLE document_chunks (
    id          BIGSERIAL PRIMARY KEY,
    doc_id      BIGINT NOT NULL,
    chunk_index INTEGER NOT NULL,
    content     TEXT NOT NULL,
    metadata    JSONB DEFAULT '{}',
    embedding   vector(1536),
    created_at  TIMESTAMPTZ DEFAULT NOW()
);

-- HNSW 인덱스 (코사인 유사도)
CREATE INDEX idx_chunks_hnsw ON document_chunks
USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 64);

-- 메타데이터 인덱스 (하이브리드 검색용)
CREATE INDEX idx_chunks_metadata ON document_chunks USING gin (metadata);

SQL WHERE 절과 벡터 검색을 같은 쿼리에서 결합할 수 있는 점은 pgvector의 강점이다. 아래 쿼리는 ai_papers 카테고리이면서 최근 30 days 안에 생성된 청크만 벡터 유사도로 정렬한다.

-- 특정 카테고리 내에서만 벡터 검색 (하이브리드 필터링)
SELECT
    c.id,
    c.content,
    c.metadata->>'source' AS source,
    1 - (c.embedding <=> $1::vector) AS similarity
FROM document_chunks c
WHERE
    c.metadata->>'category' = 'ai_papers'
    AND c.created_at > NOW() - INTERVAL '30 days'
ORDER BY c.embedding <=> $1::vector
LIMIT 5;

논리적 복제로 OLTP와 벡터 검색 분리하기

PostgreSQL 17의 논리적 복제를 이용하면 OLTP 데이터베이스 변경사항을 벡터 검색 전용 레플리카로 복제할 수 있다. 쓰기 부하와 검색 부하를 나누면서 최신 임베딩을 유지하려는 구성이다.

⤢✕

전문 벡터 DB와 비교할 때 볼 지점

Pinecone, Weaviate, Qdrant 같은 전문 벡터 DB와 비교할 때는 순수 검색 성능만이 아니라 기존 관계형 데이터와의 결합 방식, 운영 부담, 비용을 함께 봐야 한다.

구분	pgvector	Pinecone	Weaviate	Qdrant
기존 RDB 통합	최강 (SQL 네이티브)	별도 동기화 필요	별도 동기화 필요	별도 동기화 필요
순수 벡터 검색 성능	우수	최상	우수	우수
하이브리드 SQL+벡터	네이티브 지원	제한적	GraphQL 지원	필터 지원
운영 복잡도	낮음 (기존 인프라 활용)	낮음 (SaaS)	중간	중간
비용	기존 PostgreSQL 비용	종량제 (고비용)	오픈소스/SaaS	오픈소스/SaaS
클라우드 매니지드	AWS/GCP/Azure 모두 지원	전용 SaaS	일부	일부

이미 PostgreSQL을 쓰고 있고 스택 복잡도를 줄여야 한다면 pgvector가 적합하다. SQL 필터와 벡터 검색을 자주 결합하거나 RDS, Cloud SQL, Azure Database 같은 매니지드 서비스를 사용 중인 경우도 마찬가지다. 대상 벡터가 수천만 건 이하인 환경에도 맞는다.

수억 건 이상의 벡터를 다루거나, 벡터 검색 자체가 애플리케이션의 유일한 핵심 기능인 경우에는 전문 벡터 DB를 검토할 수 있다. 멀티테넌트 벡터 격리와 자동 스케일링 같은 고급 기능이 필수일 때도 같은 판단이 필요하다.

매니지드 PostgreSQL에서 pgvector 활성화하기

AWS RDS for PostgreSQL과 Aurora PostgreSQL에서는 CREATE EXTENSION vector;로 활성화할 수 있다. Multi-AZ 고가용성과 pgvector 조합을 지원하며, RDS Proxy 연결 풀링과 함께 사용할 수 있다.

Azure Database for PostgreSQL - Flexible Server에서는 Azure Portal의 확장 프로그램 탭에서 활성화한다. Azure OpenAI Service와 같은 리전에 배포하면 임베딩 레이턴시를 최소화할 수 있다.

Google Cloud SQL for PostgreSQL에서는 Cloud SQL Studio에서 CREATE EXTENSION vector를 실행할 수 있다. Vertex AI Embeddings API와 연동해 엔드투엔드 파이프라인을 구성하는 방식도 가능하다.

HNSW의 낮은 레이턴시와 IVFFlat의 삽입 성능 중 어느 쪽이 우선인지에 따라 선택은 달라진다. PostgreSQL 인프라를 이미 운영하고 있다면 별도 벡터 DB를 도입하기 전에, pgvector로 SQL과 벡터 검색을 함께 다루는 구성을 먼저 검토할 수 있다.