PostgreSQL 하나로 벡터·그래프까지: pgvector와 Apache AGE 쓰는 법

AI 기능을 붙이기 시작하면 데이터 저장소가 빠르게 늘어난다. 관계형 데이터는 PostgreSQL, 임베딩은 Pinecone, 관계 탐색은 Neo4j, 로그 검색은 Elasticsearch. 저장소마다 백업 정책과 권한 체계, 장애 대응 절차가 제각각이 된다.

PostgreSQL은 이 스택을 하나로 접을 수 있는 후보다. 확장(extension) 하나를 설치하는 것만으로 벡터 검색과 그래프 질의를 같은 엔진 안에서 돌릴 수 있다. 마이크로소프트가 PostgreSQL 공식 블로그에서 pgvector와 Apache AGE를 한 인스턴스에 얹는 방법을 다룬 것도 같은 맥락이다. 아래에서는 각 확장이 무엇을 담당하는지, 실제 SQL이 어떻게 생겼는지, 그리고 전용 DB 대신 Postgres를 골라도 되는 기준은 무엇인지를 정리한다.

멀티모델의 근거: 확장 아키텍처

PostgreSQL은 30여 년 된 오픈소스 RDBMS로, ACID 트랜잭션과 SQL 표준을 지원한다. 여기까지는 다른 관계형 DB와 크게 다르지 않다.

차이는 확장 아키텍처에서 난다. Postgres는 저장 방식, 인덱스 타입, 질의 연산자를 외부 모듈이 교체하거나 추가할 수 있도록 설계돼 있다. 그 결과 벡터나 그래프 같은 다른 데이터 모델이 "관계형 위에 덧댄 기능"이 아니라 같은 엔진의 1급 데이터 타입으로 동작한다. 확장은 대부분 아래 한 줄로 켠다.

sql
CREATE EXTENSION IF NOT EXISTS vector;   -- pgvector (벡터)
CREATE EXTENSION IF NOT EXISTS age;      -- Apache AGE (그래프)

벡터 검색: pgvector

pgvector는 고차원 벡터를 컬럼 타입으로 저장하고 유사도로 검색하는 확장이다. 코사인 거리(<=>), L2 거리(<->), 내적(<#>) 연산자를 제공한다. 임베딩을 별도 벡터 DB로 보내는 대신 테이블 컬럼에 그대로 넣는다.

sql
CREATE TABLE documents (
  id        bigserial PRIMARY KEY,
  title     text,
  embedding vector(1536)          -- 임베딩 차원 수
);

-- HNSW 인덱스: 2026년 기준 기본 선택
CREATE INDEX ON documents
  USING hnsw (embedding vector_cosine_ops);

-- 질의 벡터와 가장 가까운 문서 5건
SELECT id, title
FROM documents
ORDER BY embedding <=> $1        -- $1 = 질의 임베딩
LIMIT 5;

인덱스는 두 갈래다.

0.8.0(2024년 11월)에서 WHERE 필터링이 개선되고 iterative index scan이 추가됐다. "카테고리가 X인 문서 중에서 의미가 가까운 것"처럼 조건과 유사도를 함께 거는 질의의 정확도가 올라갔다.

sql
SELECT id, title
FROM documents
WHERE category = 'guide'         -- 일반 조건
ORDER BY embedding <=> $1        -- 유사도 정렬
LIMIT 5;

메모리에 다 올리기 어려운 규모라면 pgvectorscale이 있다. Timescale 팀이 Rust/PGRX로 만들었고, DiskANN 계열의 StreamingDiskANN으로 인덱스를 RAM이 아니라 디스크에 둔다. 주 용도는 RAG(검색증강생성), 시맨틱 검색, 추천이다.

그래프: Apache AGE

Apache AGE는 PostgreSQL을 그래프 DB로 확장하며, 질의는 openCypher로 작성한다. 노드와 엣지를 따라가는 탐색 — "친구의 친구", 지식그래프, 추천 경로 — 이 대상이다.

sql
LOAD 'age';
SET search_path = ag_catalog, "$user", public;

SELECT create_graph('social');

-- 노드와 관계 생성
SELECT * FROM cypher('social', $$
  CREATE (a:Person {name:'Alice'})-[:KNOWS]->(b:Person {name:'Bob'})
$$) AS (v agtype);

-- 2-홉 탐색: 친구의 친구
SELECT * FROM cypher('social', $$
  MATCH (:Person {name:'Alice'})-[:KNOWS*2]->(fof)
  RETURN fof.name
$$) AS (name agtype);

벡터 + 그래프: 한 인스턴스 안의 GraphRAG

pgvector와 AGE를 함께 쓰면 벡터의 의미 검색과 그래프의 관계 탐색을 한 데이터베이스, 한 트랜잭션 안에서 엮을 수 있다. 의미로 후보 문서를 좁힌 뒤 그래프로 연결된 근거를 확장하는 GraphRAG 파이프라인을 별도 인프라 없이 구성한다는 뜻이다. 마이크로소프트 글이 강조하는 지점이 정확히 이 결합이다.

나머지 모델도 확장으로 붙는다

벡터와 그래프 외에도 대부분의 데이터 모델이 확장이나 내장 기능으로 커버된다.

Postgres + Pinecone + Neo4j + MongoDB + Elasticsearch로 쪼갤 스택을 하나로 모으면 백업·트랜잭션·권한 관리가 한 곳으로 수렴하고, 관계형·벡터·그래프 데이터를 하나의 쿼리로 조인할 수 있다. 개발자 커뮤니티의 "Just use Postgres" 정서가 근거 없는 유행만은 아닌 이유다.

전용 DB가 나은 경우

Postgres 하나로 수렴한다고 해서 전용 DB가 사라지는 것은 아니다. 수십억 개 규모의 벡터나 특정 워크로드에서는 Pinecone·Neo4j 같은 전용 엔진이 유리하다. 확장이 막히는 제약도 있다. pgvectorscale은 2026년 중반 기준 AWS RDS에서 지원되지 않아 직접 운영해야 한다.

관리 대상이 사라지는 것도 아니다. 확장을 여러 개 얹는 순간 인덱스 튜닝과 확장 버전 호환 관리가 팀의 몫이 된다. Postgres를 올릴 때 pgvector와 AGE의 호환 버전을 함께 확인해야 하는 식으로, "DB 다섯 개"가 "확장 다섯 개"로 옮겨간 것에 가깝다. 매니지드 서비스를 쓴다면 아키텍처를 확정하기 전에 필요한 확장이 지원 목록에 있는지부터 확인해야 한다.

정리

• 관계형·벡터·그래프를 한 엔진에서: pgvector가 벡터, Apache AGE가 그래프를 담당하고, 둘을 합치면 GraphRAG가 한 인스턴스 안에서 돌아간다.
• 시작 기준 세 가지: 데이터 규모, 팀의 운영 역량, 이미 Postgres를 쓰고 있는지 여부. 운영 중인 Postgres가 있다면 테이블 하나를 추가하는 비용으로 시맨틱 검색을 붙일 수 있다.
• 전용 DB는 극한에서: 초대규모·특수 워크로드이거나 매니지드 환경이 확장을 막을 때 검토한다.
• 대부분의 애플리케이션에는 Postgres 하나로 충분하며, 확장 생태계를 얼마나 감당할 수 있는지가 실제 판단 기준이 된다.

📎 출처: 원문 보기