C.W.K.
Stream
Lesson 01 of 05 · published

SQL 이 순수 vector DB 를 이길 때

~20 min · pgvector, architecture

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

지루한 win: 한 데이터베이스

앱의 관계형 부분에 이미 Postgres 돌리고 있다면, 벡터를 describe 하는 row 옆에 두는 게 두 시스템을 하나로 합쳐. id 중복 그만, 두 store sync 그만, transaction 이 둘 다 cover, backup story 더 단순해짐.

pgvector 가 구체적으로 이기는 곳

  • 무거운 구조화 필터링. Postgres planner 가 'WHERE tenant = X AND created_at > Y' 와 vector ranking 결합에서 수십 년 앞서있어.
  • retrieval 결과 join. '가장 가까운 청크 20개 찾고, 작가와 click count join' 이 한 query, 세 개 아냐.
  • 기존 ops 근육. Backup, replication, monitoring, IAM, point-in-time recovery — 지루한 인프라가 다 이미 존재.

Chroma / Pinecone / Weaviate 가 여전히 이기는 곳

  • 거대 스케일 순수 벡터 워크로드 (>5천만 벡터) — dedicated store 가 ANN 에 더 많이 엔지니어링 투자.
  • built-in multi-vector + 하이브리드 — Weaviate, Vespa 가 더 많은 retrieval primitive 를 box 채로 ship.
  • 아직 Postgres 안 돌리고 있음 — pgvector 만 위해 Postgres 도입은 무거움.

2026년 1000만 청크 미만 + Postgres 이미 있는 대부분 팀은 pgvector 가 옳은 default.

Code

소유 비용 sketch·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

본인 retrieval 파이프라인 sketch. LLM prompt 에서 읽는 컬럼 중 non-vector 테이블 (작가, 태그, click count, 권한) 에서 오는 게 몇 개인지 카운트. 많으면 본인이 pgvector 로 자기 자신 설득한 거.

Progress

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

댓글 0

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

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