n8n에서 Vector Database를 생성할 때 추천되는 데이터베이스

8월 04, 2025


n8n으로 RAG(Retrieval-Augmented Generation) 워크플로우를 만들 때 핵심 구성 요소 중 하나가 Vector Database(Vector Store) 입니다.

문서, FAQ, 매뉴얼, 블로그 글과 같은 텍스트 데이터를 임베딩으로 변환해 저장하고, 사용자의 질문과 의미적으로 가까운 문서를 검색하는 역할을 합니다.

n8n은 여러 Vector Store 노드를 공식적으로 제공하며, 대표적으로 다음과 같은 선택지가 있습니다.(n8n Docs)

  • PGVector Vector Store
  • Supabase Vector Store (Supabase)
  • Milvus Vector Store
  • Simple Vector Store
  • Qdrant Vector Store
  • Pinecone Vector Store
  • Chroma Vector Store
  • Redis Vector Store
  • Weaviate Vector Store
  • MongoDB Atlas Vector Store

이 글에서는 n8n에서 자주 선택할 만한 Vector Database를 사용 목적별로 정리합니다.

결론부터: 대부분의 n8n 프로젝트에서는 PostgreSQL + pgvector를 먼저 검토

운영 환경에서 가장 균형 잡힌 선택지는 대체로 PostgreSQL + pgvector입니다.

특히 다음 조건에 해당한다면 PGVector를 우선 검토할 만합니다.

  • 이미 PostgreSQL을 사용하고 있다
  • n8n을 자체 서버 또는 Docker 환경에서 운영한다
  • 벡터 검색뿐 아니라 메타데이터 필터링도 중요하다
  • 운영 비용을 낮게 유지하고 싶다
  • 별도 Vector DB를 추가로 운영하기 부담스럽다
  • SQL 기반 관리와 백업 체계를 선호한다

다만 대규모 벡터 검색 성능이 매우 중요하거나, 수천만~수십억 단위 벡터를 다루는 전문 검색 시스템이라면 Milvus, Qdrant, Pinecone, Weaviate 같은 전용 Vector DB도 함께 검토하는 것이 좋습니다.

1. PostgreSQL + pgvector: 가장 먼저 추천할 만한 선택지

개요

pgvector는 PostgreSQL에서 벡터 데이터를 저장하고 유사도 검색을 수행할 수 있게 해주는 확장입니다.
n8n에서는 PGVector Vector Store 노드를 통해 PostgreSQL 기반 Vector Store를 사용할 수 있습니다.

n8n에서 사용할 때의 대표적인 노드 타입은 다음과 같습니다.

{
  "type": "n8n-nodes-langchain.vectorstorepgvector"
}

실제 워크플로우 JSON의 세부 파라미터 이름은 n8n 버전에 따라 달라질 수 있으므로, 블로그나 문서에서는 내부 JSON보다 n8n UI 기준으로 설명하는 편이 안전합니다.

장점

  • PostgreSQL 기반이라 운영 경험을 재사용하기 쉽다
  • 별도 Vector DB를 추가하지 않아도 된다
  • SQL을 이용한 필터링과 조인이 가능하다
  • 문서 내용, 메타데이터, 임베딩을 한 데이터베이스에서 관리할 수 있다
  • 백업, 복구, 권한 관리, 모니터링 체계를 PostgreSQL 중심으로 구성할 수 있다
  • 오픈소스 기반이라 비용 효율성이 좋다

주의할 점

  • n8n의 내부 운영 DB와 같은 PostgreSQL 서버를 사용할 수는 있지만, 가능하면 별도 데이터베이스나 별도 스키마로 분리하는 것이 좋다
  • 임베딩 차원 수는 사용하는 임베딩 모델과 반드시 맞아야 한다
  • 벡터 수가 많아질수록 인덱스, 메모리, 쿼리 튜닝이 중요해진다
  • 단순히 테이블만 만들면 끝나는 것이 아니라 HNSW 또는 IVFFlat 같은 인덱스 전략을 함께 고려해야 한다

적합한 경우

  • 사내 문서 검색
  • FAQ 챗봇
  • 제품 매뉴얼 검색
  • 고객지원 지식베이스
  • 중소규모 RAG 시스템
  • 기존 PostgreSQL 인프라를 활용하고 싶은 경우

2. Supabase Vector Store: 빠른 구축과 관리형 환경에 적합

개요 (Supabase)

Supabase는 PostgreSQL 기반의 백엔드 플랫폼이며, pgvector를 활용해 Vector Store를 구성할 수 있습니다.
n8n에서는 Supabase Vector Store 노드를 통해 Supabase 데이터베이스를 Vector Store로 사용할 수 있습니다.

대표적인 노드 타입은 다음과 같습니다.

{
  "type": "n8n-nodes-langchain.vectorstoresupabase"
}

장점

  • PostgreSQL + pgvector 기반이라 구조가 익숙하다
  • 별도 서버 운영 부담이 적다
  • 빠르게 프로토타입을 만들기 좋다
  • Supabase의 인증, API, 관리 콘솔과 함께 사용할 수 있다
  • n8n과 연동하기 쉬운 공식 Vector Store 노드가 있다

주의할 점

  • 무료 또는 저가 요금제에서는 저장 공간, 성능, 요청량 제한을 확인해야 한다
  • 민감한 데이터를 저장할 경우 Row Level Security, API Key 관리, 접근 권한 설정을 신중히 해야 한다
  • 완전한 자체 통제가 필요한 환경에서는 자체 PostgreSQL + pgvector가 더 적합할 수 있다

적합한 경우

  • 빠르게 RAG 프로토타입을 만들고 싶은 경우
  • 서버 운영보다 서비스 개발에 집중하고 싶은 경우
  • PostgreSQL 기반 관리형 서비스를 선호하는 경우
  • 작은 팀이나 스타트업에서 빠른 검증이 필요한 경우

3. Milvus Vector Store: 대규모 벡터 검색에 적합한 전문 Vector DB

개요

Milvus는 벡터 검색을 위해 설계된 오픈소스 Vector Database입니다.
n8n에서는 Milvus Vector Store 노드를 통해 Milvus에 문서를 삽입하고 검색할 수 있습니다.

대표적인 노드 타입은 다음과 같습니다.

{
  "type": "n8n-nodes-langchain.vectorstoremilvus"
}

장점

  • 벡터 검색 전용 데이터베이스
  • 대규모 벡터 검색에 적합
  • 다양한 인덱스와 검색 전략을 지원
  • Standalone, Distributed 등 여러 배포 방식을 선택할 수 있음
  • AI 검색, 추천, 이미지 검색, 멀티모달 검색처럼 벡터 검색이 핵심인 서비스에 적합

주의할 점

  • PostgreSQL + pgvector보다 운영 복잡도가 높다
  • 별도 인프라와 모니터링이 필요하다
  • 작은 프로젝트에서는 과한 선택이 될 수 있다
  • 메타데이터 중심의 복잡한 SQL 쿼리가 중요하다면 PostgreSQL 기반 접근이 더 단순할 수 있다

적합한 경우

  • 대규모 문서 검색 시스템
  • 수백만~수천만 개 이상의 벡터 검색을 고려하는 경우
  • 검색 성능과 확장성이 중요한 AI/ML 프로젝트
  • Vector DB를 별도 핵심 인프라로 운영할 수 있는 팀

4. Simple Vector Store: 개발과 테스트 전용으로 사용

개요

n8n의 Simple Vector Store는 n8n 애플리케이션 메모리에 임베딩을 저장하는 간단한 Vector Store입니다.

대표적인 노드 타입은 다음과 같습니다.

{
  "type": "n8n-nodes-langchain.vectorstoreinmemory"
}

장점

  • 설정이 매우 간단하다
  • 별도 데이터베이스가 필요 없다
  • RAG 워크플로우 구조를 빠르게 테스트할 수 있다
  • 튜토리얼, 데모, 실험용으로 적합하다

제한사항

  • 데이터가 메모리에 저장된다
  • n8n 재시작 시 데이터가 사라질 수 있다
  • 운영 환경에서 사용하기 어렵다
  • 민감한 데이터를 넣기에는 적합하지 않다
  • 여러 사용자가 같은 n8n 인스턴스를 사용하는 경우 데이터 접근 범위를 주의해야 한다

적합한 경우

  • n8n RAG 기능 테스트
  • Vector Store 노드 사용법 학습
  • 짧은 데모
  • 임베딩·검색 흐름 검증

운영 환경에서는 Simple Vector Store 대신 PostgreSQL + pgvector, Supabase, Milvus, Qdrant, Pinecone 등 영속 저장이 가능한 Vector Store를 사용하는 것이 좋습니다.

사용 사례별 추천

사용 사례 추천 Vector Store
대부분의 자체 운영 n8n 프로젝트 PostgreSQL + pgvector
기존 PostgreSQL 사용 환경 PostgreSQL + pgvector
빠른 프로토타이핑 Supabase Vector Store
관리형 PostgreSQL 선호 Supabase Vector Store
대규모 벡터 검색 Milvus, Qdrant, Pinecone, Weaviate
개발·테스트 Simple Vector Store
서버리스 또는 SaaS 기반 운영 선호 Supabase, Pinecone
오픈소스 자체 호스팅 선호 PostgreSQL + pgvector, Milvus, Qdrant, Weaviate

PostgreSQL + pgvector 기본 설정 예시

아래 예시는 1536차원 임베딩 모델을 사용하는 경우의 테이블 예시입니다.
사용하는 임베딩 모델의 차원 수가 다르면 vector(1536) 부분을 반드시 변경해야 합니다.

-- 1. pgvector 확장 활성화
CREATE EXTENSION IF NOT EXISTS vector;

-- 2. 문서 및 임베딩 저장 테이블 생성
CREATE TABLE documents (
  id BIGSERIAL PRIMARY KEY,
  content TEXT NOT NULL,
  metadata JSONB DEFAULT '{}'::jsonb,
  embedding VECTOR(1536)
);

-- 3. 코사인 유사도 검색용 HNSW 인덱스 생성
CREATE INDEX documents_embedding_hnsw_idx
ON documents
USING hnsw (embedding vector_cosine_ops);

HNSW는 검색 성능과 recall 측면에서 좋은 선택이 될 수 있지만, 인덱스 생성 시간과 메모리 사용량이 증가할 수 있습니다.
데이터 규모, 삽입 빈도, 검색 빈도에 따라 IVFFlat도 검토할 수 있습니다.

IVFFlat 예시는 다음과 같습니다.

CREATE INDEX documents_embedding_ivfflat_idx
ON documents
USING ivfflat (embedding vector_cosine_ops)
WITH (lists = 100);

IVFFlat 인덱스는 일반적으로 어느 정도 데이터가 적재된 뒤 생성하는 것이 좋습니다.

n8n에서 RAG 워크플로우를 구성하는 기본 흐름

n8n에서 Vector Store를 사용할 때의 기본 흐름은 다음과 같습니다.

1. 문서 수집

예를 들어 다음과 같은 소스에서 문서를 가져옵니다.

  • Google Drive
  • Notion
  • 웹페이지
  • PDF
  • 데이터베이스
  • 사내 문서 저장소

2. 문서 분할

긴 문서는 그대로 임베딩하기보다 적절한 크기로 나누는 것이 좋습니다.

n8n에서는 Data Loader와 Text Splitter를 활용해 문서를 chunk 단위로 나눌 수 있습니다.

대표적인 분할 방식은 다음과 같습니다.

  • Recursive Character Text Splitter
  • Character Text Splitter
  • Token Text Splitter

일반적인 문서 기반 RAG에서는 Recursive Character Text Splitter를 먼저 검토하는 것이 무난합니다.

3. 임베딩 생성

분할된 문서 조각을 임베딩 모델을 통해 벡터로 변환합니다.

이때 중요한 점은 다음과 같습니다.

  • 삽입할 때 사용한 임베딩 모델과 검색할 때 사용하는 임베딩 모델을 동일하게 유지한다
  • 벡터 차원 수가 데이터베이스 테이블 정의와 일치해야 한다
  • 비용, 속도, 정확도를 고려해 임베딩 모델을 선택한다

4. Vector Store에 저장

PGVector, Supabase, Milvus, Qdrant 등의 Vector Store 노드에서 Insert Documents 모드를 사용해 문서를 저장합니다.

저장할 때는 문서 내용뿐 아니라 다음과 같은 메타데이터도 함께 저장하는 것이 좋습니다.

  • 문서 제목
  • 원본 파일명
  • URL
  • 작성일
  • 카테고리
  • 권한 정보
  • 부서 또는 프로젝트명

메타데이터를 잘 넣어두면 나중에 검색 결과를 필터링하거나 출처를 표시하기 쉬워집니다.

5. 검색 및 답변 생성

사용자가 질문하면 n8n은 질문을 임베딩으로 변환하고 Vector Store에서 의미적으로 가까운 문서 조각을 검색합니다.

검색 결과는 다음 방식으로 사용할 수 있습니다.

  • AI Agent의 Tool로 연결
  • Vector Store Retriever와 Chain에 연결
  • Vector Store Question Answer Tool 사용
  • Vector Store 노드의 Get Many 기능으로 직접 검색

운영 환경에서의 추천 구성

소규모 또는 일반적인 사내 RAG

추천 구성:

n8n + PostgreSQL + pgvector

이 구성은 운영이 단순하고 비용 효율적입니다.
기존 PostgreSQL 백업 및 모니터링 체계를 활용할 수 있으며, 메타데이터 필터링도 SQL 기반으로 처리할 수 있습니다.

빠른 프로토타입 또는 스타트업 초기 검증

추천 구성:

n8n + Supabase Vector Store

Supabase를 사용하면 데이터베이스 서버 운영 부담을 줄이면서 빠르게 RAG 기능을 검증할 수 있습니다.
다만 운영 단계로 넘어갈 때는 요금제, 보안 정책, 백업 전략을 반드시 점검해야 합니다.

대규모 AI 검색 서비스

추천 구성:

n8n + Milvus

또는 다음 선택지도 함께 검토할 수 있습니다.

n8n + Qdrant
n8n + Pinecone
n8n + Weaviate

벡터 검색이 서비스의 핵심이고 데이터 규모가 크다면 전용 Vector DB가 더 적합할 수 있습니다.

개발 및 테스트

추천 구성:

n8n + Simple Vector Store

Simple Vector Store는 학습과 테스트에는 좋지만, 운영 환경에서는 사용하지 않는 것이 좋습니다.
데이터가 영속 저장되지 않기 때문입니다.

최종 정리

n8n에서 Vector Database를 선택할 때는 단순히 “어떤 DB가 가장 좋은가?”보다 다음 질문을 먼저 해야 합니다.

  • 이미 사용 중인 데이터베이스가 있는가?
  • 운영 환경인가, 테스트 환경인가?
  • 벡터 데이터 규모는 어느 정도인가?
  • 메타데이터 필터링이 중요한가?
  • 자체 호스팅이 필요한가?
  • 관리형 서비스를 선호하는가?
  • 검색 성능이 서비스의 핵심인가?

대부분의 n8n RAG 프로젝트에서는 PostgreSQL + pgvector가 가장 균형 잡힌 출발점입니다.
빠른 프로토타입에는 Supabase Vector Store, 대규모 벡터 검색에는 Milvus, Qdrant, Pinecone, Weaviate 같은 전용 Vector DB를 고려할 수 있습니다.

그리고 Simple Vector Store는 개발·테스트용으로만 사용하는 것이 안전합니다.

결론적으로, 특별한 대규모 검색 요구사항이 없다면 다음 순서로 검토하는 것을 추천합니다.

  1. PostgreSQL + pgvector
  2. Supabase Vector Store
  3. Qdrant / Milvus / Pinecone / Weaviate
  4. Simple Vector Store는 테스트용으로만 사용

댓글 쓰기 · 수정

0 댓글