본문 바로가기
C.W.K.
Stream
Lesson 01 of 05 · published

SQL이 전용 벡터 DB보다 나을 때

~20 min · pgvector, architecture

Level 0Scout
0 XP0/41 lessons0/10 achievements
0/120 XP to next level120 XP to go0% complete

수수하지만 강한 장점: 데이터베이스 하나

앱의 관계형 데이터를 이미 Postgres에 두고 있다면 벡터도 관련 행 옆에 두는 편이 좋아. ID를 중복 관리하거나 두 저장소를 동기화할 필요가 없고, 트랜잭션은 양쪽 데이터를 함께 보호하며 백업 절차도 단순해져.

pgvector가 특히 유리한 곳

  • 복잡한 구조화 필터. Postgres 플래너는 'WHERE tenant = X AND created_at > Y' 같은 조건과 벡터 순위를 결합하는 일에 이미 성숙해 있어.
  • 검색 결과 조인. '가장 가까운 청크 20개를 찾고 작가와 클릭 수를 붙이기'를 여러 번 왕복하지 않고 쿼리 하나로 처리할 수 있어.
  • 이미 갖춘 운영 역량. 백업, 복제, 감시, IAM, 특정 시점 복구처럼 검증된 인프라를 그대로 쓸 수 있어.

Chroma, Pinecone, Weaviate가 더 나은 곳

  • 벡터 5천만 개가 넘는 대규모 전용 작업 — 전용 저장소는 ANN 성능에 더 많은 최적화를 해 두었어.
  • 내장된 다중 벡터와 하이브리드 기능 — Weaviate와 Vespa는 더 다양한 검색 기능을 바로 제공해.
  • 아직 Postgres를 쓰지 않는 경우 — pgvector 하나 때문에 Postgres까지 도입하는 것은 무거워.

2026년 기준으로 청크가 1000만 개 미만이고 이미 Postgres를 쓰는 팀이라면 pgvector가 대개 알맞은 기본 선택이야.

Code

운영 비용 개요·text
순수 vector DB:
  + 스케일에서 best ANN 성능
  + best multi-vector / 하이브리드 primitive
  -- 두 시스템 backup, monitor, secure, sync
  -- ID/메타데이터 중복

pgvector:
  + 1 시스템, 1 backup, 1 IAM 모델
  + Join, transaction, 구조화 필터 공짜
  + 기존 ops 근육
  -- ~1000만 벡터 넘으면 dedicated store 보다 느림
  -- 하이브리드 scaffold 적음 (직접 빌드해야)

External links

Exercise

현재 검색 파이프라인을 그려 봐. LLM 프롬프트에 넣는 값 가운데 작가, 태그, 클릭 수, 권한처럼 벡터가 아닌 테이블에서 읽는 열이 몇 개인지 세어. 그 수가 많다면 pgvector를 선택할 근거가 이미 나온 셈이야.

Progress

Progress is local-only — sign in to sync across devices.
이 페이지에서 버그를 발견하셨거나 피드백이 있으세요?문제 신고

댓글 0

🔔 답글 알림 (로그인 필요)
로그인댓글을 남기려면 로그인해 주세요.

아직 댓글이 없어요. 첫 댓글을 남겨보세요.