ivada-infra/DOCS
3
0
Fork 0
Code Issues 1 Pull Requests 5 Actions Packages Projects Releases Wiki Activity
DOCS/journey/research/260316_postgres_통합_vs_전용db_구조성능_리서치.md

16 KiB
Raw Blame History

tags
tags
infra
database
postgres
redis
pgvector
elasticsearch
neo4j
research

260316 PostgreSQL 통합 vs 전용 DB 구조성능 리서치

상위 원칙

관련 문서

목적

  • 벡터, 그래프, 검색 같은 non-RDB 기능을 지금 단계에서 PostgreSQL로 통일하는 판단 근거를 인프라 관점에서 다시 정리합니다.
  • 전용 DB 대비 Postgres가 몇 % 느리다 같은 숫자 요약이 통일 결정을 막을 정도의 SSOT인지 검증합니다.
  • 앞으로 전용 DB를 걷어내고 PostgreSQL 하나로 정리한다는 방향에서 무엇이 사실이고 무엇이 과장인지 분리합니다.

Facts

0. 이번 리서치의 직접 입력은 Gemini가 제시한 기능별 퍼센트 요약이다

  • 입력 주장:
    • Redis 대비 PostgreSQL 캐시 성능은 대략 10~50%
    • Milvus/Qdrant 대비 PostgreSQL 벡터 성능은 대략 70~85%
    • Elasticsearch 대비 PostgreSQL 텍스트 검색 성능은 대략 50~80%
    • Neo4j 대비 PostgreSQL 그래프 성능은 대략 10~50%
  • 이 수치들은 일견 그럴듯하지만, 이번 리서치에서 확인한 공식 문서와 벤더 자료 어디에도 항상 이 범위로 일반화된다는 단일 근거는 없다.
  • 따라서 이 퍼센트 범위는 대화 입력값으로는 쓸 수 있어도 공식 SSOT로 바로 승격할 수는 없다.

1. 캐시 관점에서 Redis는 만료를 1급 기능으로 제공한다

  • Redis 공식 문서의 EXPIRE는 키 만료 시간을 초 단위로 직접 설정하는 명령이며 복잡도는 O(1)로 문서화돼 있다.
  • PostgreSQL 공식 문서의 UNLOGGED TABLE은 WAL을 쓰지 않아 일반 테이블보다 상당히 빠를 수 있지만, crash-safe가 아니고 standby 복제도 되지 않는다.
  • 즉 Redis는 키 단위 만료를 기본 기능으로 제공하고, PostgreSQL은 영속성 비용을 줄인 테이블은 제공하지만 동일한 의미의 key TTL primitive를 코어 기능으로 제시하지는 않는다.

2. 벡터 검색 관점에서 PostgreSQL은 이미 실전 가능한 수준이지만, 조정 포인트가 많다

  • pgvector 공식 README에 따르면 기본 동작은 exact nearest neighbor search이며, 속도를 위해 approximate index를 쓰면 recall과 speed를 교환한다.
  • pgvector는 HNSW와 IVFFlat를 지원하고, HNSW는 IVFFlat보다 speed-recall tradeoff가 좋지만 메모리를 더 쓰고 build가 느리다.
  • pgvector 문서는 metadata filter가 많은 경우 approximate index 이후 필터링 때문에 원하는 개수가 덜 나올 수 있어 ef_search, iterative scan, partial index, partitioning 같은 추가 조정을 권장한다.
  • pgvector는 vector, halfvec, bit, sparsevec 타입을 제공하고, halfvec와 binary quantization 같은 저장 최적화 선택지도 문서화한다.
  • Qdrant 공식 문서는 shard 이동, shard replication, replication factor를 문서화하고 있다.
  • Milvus 공식 문서는 standalone과 distributed를 분리하고, distributed 모드가 billion-scale or even larger scenarios를 목표로 한다고 설명한다.

3. 텍스트 검색 관점에서 PostgreSQL은 키워드 + 구문 + JSON + 오타허용까지 한 저장소에서 묶을 수 있다

  • PostgreSQL 공식 Full Text Search 문서는 dictionaries, synonym dictionary, thesaurus dictionary, ranking, highlighting, preferred index types, limitations까지 별도 장으로 제공한다.
  • PostgreSQL 공식 함수 문서는 phraseto_tsquery, websearch_to_tsquery, <-> phrase operator, setweight, json_to_tsvector/jsonb_to_tsvector를 제공한다.
  • pg_trgm 공식 문서는 similarity threshold, word similarity, strict word similarity와 함께 LIKE, ILIKE, 정규식, similarity query에 대한 GIN/GiST 인덱스 지원을 명시한다.
  • Elasticsearch 공식 문서의 fuzzy query는 Levenshtein edit distance 기반으로 검색어 변형(expansions)을 만들어 exact match를 수행하며, fuzziness, max_expansions, prefix_length 같은 파라미터를 1급 기능으로 제공한다.
  • 즉 PostgreSQL은 FTS + pg_trgm + JSON tsvector 조합만으로도 일반 서비스 검색에 필요한 핵심 기능을 상당 부분 직접 제공한다.

4. 그래프 관점에서 PostgreSQL은 재귀 탐색 + 순회 순서 + 사이클 감지를 공식 문법으로 제공한다

  • PostgreSQL 공식 문서는 계층형/트리형 데이터를 위해 WITH RECURSIVE를 제공하며, 재귀 질의는 내부적으로 반복 평가된다고 설명한다.
  • 같은 공식 문서는 SEARCH DEPTH FIRST, SEARCH BREADTH FIRST, CYCLE ... USING path 구문으로 정렬용 탐색 순서와 cycle detection을 직접 제공한다.
  • PostgreSQL ltree 확장은 계층형 경로를 위한 전용 타입과 쿼리 연산을 제공한다.
  • Neo4j 공식 학습 문서는 index-free adjacency를 핵심 차별점으로 설명하며, 시작점만 인덱스로 찾고 이후는 포인터를 따라가며 traversal한다고 설명한다.
  • Neo4j 측 설명은 복잡한 관계 순회에서 index lookup과 join 수를 줄이는 구조적 이점을 강조한다.

5. 현재 로빙 계열 문서는 여전히 PostgreSQL + ChromaDB + Neo4j 하이브리드 기억 구조를 전제한다

  • 330_백엔드_PostgreSQL_ChromaDB_Vector_Memory.md는 PostgreSQL = 사실 기억, ChromaDB = 연상 기억이라는 역할 분리를 설명한다.
  • 251016_phase2_hybrid_memory_implementation.md는 ChromaDB top-k 후보 + Neo4j 그래프 추론 + 점수 통합 구조를 구현 대상으로 기록한다.
  • 따라서 전용 DB를 없애고 PostgreSQL로 통일은 추상 아이디어가 아니라, 현재 하이브리드 전제를 실제로 뒤집는 아키텍처 변경이다.

6. 전용 DB 대비 Postgres 몇 % 수치는 공식 SSOT로 고정하기 어렵다

  • Redis, Qdrant, Milvus, Elasticsearch, Neo4j, Timescale/pgvectorscale 모두 각자 자신에게 유리한 벤치마크와 운영 조건을 제시한다.
  • 예를 들어 Timescale은 자체 발표에서 PostgreSQL + pgvector + pgvectorscale이 Pinecone보다 더 낮은 p95 latency와 더 높은 throughput을 보였다고 주장한다.
  • 반대로 Milvus는 공식 문서에서 자체 설계가 다른 vector DB보다 2-5x 빠른 경우가 많다고 주장한다.
  • 이 수치들은 제품 선택 참고자료로는 유효하지만, 벤더가 선택한 데이터셋·recall·하드웨어·필터 조건에 크게 의존한다.
  • 따라서 Redis 10~50%, Neo4j 10~50% 같은 숫자는 가능한 사례일 수는 있어도 범용 평균이나 운영 SSOT처럼 다루면 위험하다.

Interpretation

1. 지금 이 아이디어를 닫는 데 필요한 핵심은 PostgreSQL이 대체 가능한가이지 전용 DB가 영원히 불필요한가가 아니다

  • 현재 판단 대상은 장기 기술종결 선언이 아니라, 지금 운영 구조에서 ChromaDB/Neo4j/검색 전용 계층을 걷어내고 PostgreSQL로 옮길 수 있는가다.
  • 위 Facts 기준으로 보면 PostgreSQL은 이미 벡터 타입/인덱스, FTS/phrase/web-style query, trigram similarity, recursive traversal, cycle detection, path-like 타입까지 갖고 있다.
  • 따라서 기능 목록만 놓고 보면 현재 논의 대상인 벡터 + 검색 + 그래프를 PostgreSQL로 통일할 최소 기능은 이미 충족한다.

2. 캐시는 속도보다 TTL/eviction semantics 차이가 더 본질적이다

  • Redis와 PostgreSQL의 차이를 단순 latency 수치로만 보면 판단이 흔들릴 수 있다.
  • 실제 구조 차이는 Redis는 만료와 메모리 중심 접근을 기본 계약으로 제공하고, PostgreSQL은 기본적으로 영속성과 트랜잭션을 우선한다는 점이다.
  • 따라서 Postgres를 캐시처럼 쓰겠다는 말은 가능하지만, Redis의 운영 의미까지 완전히 대체한다고 말하면 과장일 수 있다.

3. 벡터는 현재 워크로드 기준으로 PostgreSQL 이관 장애보다 인덱스 설계 문제가 더 크다

  • 로빙 계열 벡터 검색은 메타데이터 필터, 사용자 단위 분리, top-k 검색, 기억 회상, 파일/RAG 결합처럼 관계형 데이터와 함께 움직이는 비중이 크다.
  • 이 유형은 별도 벡터 DB보다 PostgreSQL + pgvector + 관계형 필터가 오히려 자연스럽다.
  • 실제 남는 과제는 HNSW/IVFFlat 선택, ef_search/iterative_scan, 부분 인덱스/파티셔닝, halfvec/압축 여부 같은 튜닝이지, 기능 부재가 아니다.
  • 대표 질의 형태도 이미 PostgreSQL 친화적이다.
    • tenant_id = ? AND category = 'memory' ORDER BY embedding <=> :query LIMIT 10
    • tenant_id = ? AND created_at >= now() - interval '30 days' ORDER BY embedding <=> :query LIMIT 5

4. 검색은 FTS + pg_trgm 조합으로 먼저 닫을 수 있다

  • 사용자가 기대하는 검색은 보통 정확 키워드, 구문, 웹검색식 입력, 오타/부분일치, 메타데이터 필터, 랭킹의 조합이다.
  • PostgreSQL은 phraseto_tsquery, websearch_to_tsquery, setweight, jsonb_to_tsvector, pg_trgm similarity를 모두 공식 기능으로 제공한다.
  • 따라서 현재 단계의 검색 통일은 Elasticsearch 대체 불가 여부를 묻기보다 PostgreSQL 안에서 검색 스키마와 인덱스를 어떻게 짤지를 묻는 단계로 보는 것이 맞다.
  • 대표 질의 형태는 아래처럼 바로 그릴 수 있다.
    • WHERE search_tsv @@ websearch_to_tsquery('simple', :q)
    • ORDER BY ts_rank_cd(search_tsv, websearch_to_tsquery('simple', :q)) DESC, similarity(title, :q) DESC
    • metadata 필터는 metadata->>'source' = 'companyx' 같은 SQL 조건으로 결합 가능하다.

5. 그래프는 무제한 자유 탐색이 아니라 경계 있는 관계 탐색으로 재정의하면 PostgreSQL로 수렴시킬 수 있다

  • PostgreSQL의 recursive CTE로 그래프성 질의를 구현할 수는 있다.
  • SEARCH와 CYCLE 구문, path array, ltree 같은 도구를 쓰면 bounded-depth traversal, 계층형 경로, 관계 추적은 공식 SQL 범위 안에서 구현할 수 있다.
  • 현재 로빙 문서에 적힌 Neo4j 용도도 초거대 공개 그래프 탐색이 아니라 사건-감정-결과 관계 가중치와 같은 제한된 관계망이므로, 현 단계에서는 PostgreSQL 모델 재설계로 충분히 흡수 가능한 범주에 가깝다.
  • 대표 질의도 3단계 이하 관계 회상에 가깝다.
    • 특정 사건과 감정/결과로 연결된 최근 사건 찾기
    • 사용자별 최근 1년 유사 사건 경로 찾기
    • 성공 결과가 붙은 사건을 우선 랭킹하기

6. 이 아이디어를 닫는 데 남은 미확정은 가능한가가 아니라 어떻게 옮길까에 가깝다

  • Redis 대비 10~50%, Neo4j 대비 10~50% 같은 퍼센트는 문서 첫 줄 결론으로는 위험하다.
  • 사용자가 본 Gemini 요약은 방향성 수준에서는 꽤 그럴듯하지만, 2025~2026년 최신 검증치처럼 받아들이기에는 출처 사슬이 충분히 드러나지 않는다.
  • 이 리서치 기준으로는 현재 운영 규모에서 PostgreSQL로 먼저 수용 불가라는 직접 근거가 아직 없다.
  • 그래서 다음 질문은 전용 DB를 남겨야 하나보다 Chroma 컬렉션을 어떤 테이블/인덱스로 옮길까, Neo4j 관계를 어떤 스키마와 recursive query로 바꿀까, 검색 랭킹을 어떤 column weighting으로 설계할까가 된다.

Unresolved

  • ChromaDB collection -> PostgreSQL table 매핑 단위를 tenant per table, global table + tenant key, partition per tenant 중 무엇으로 잡을지 결정이 아직 없다.
  • Neo4j의 Event-Emotion-Result 그래프를 adjacency table, materialized path, ltree, jsonb edge payload 중 어떤 방식으로 표현할지 결정이 아직 없다.
  • 검색 쪽도 문서 원문, 요약문, 태그, metadata jsonb에 어떤 가중치를 줄지와 FTS + pg_trgm + vector hybrid rank 공식을 아직 정하지 않았다.
  • 내부 대표 질의셋 10~20개를 무엇으로 고정할지 아직 없다.
  • 즉 이 주제의 다음 단계는 추가 일반론 리서치가 아니라 non-RDB 계층 PostgreSQL 통일 계획 기준의 스키마/인덱스/랭킹 설계 실행이다.

실행 검증 결과

  • skill-rag-file은 PostgreSQL team_document_chunk에 실제 문서 chunk를 저장하고 검색 결과를 반환하는 것으로 검증됐다.
  • rb8001은 PostgreSQL memory_vectors, memory_graph_nodes, memory_graph_edges에서 실제 저장/회상/관계 조회가 검증됐다.
  • 잔여 Neo4j 런타임 경로였던 coldmail memory, startup valuation comparable prior, valuation premia recalculation도 PostgreSQL 경로로 치환되어 24 컨테이너 안에서 실동작이 확인됐다.
  • 따라서 이 리서치의 남은 미확정은 더 이상 PostgreSQL로 가능한가가 아니라 이후 성능 미세조정과 범위 확장뿐이며, 실행 근거는 non-RDB 계층 PostgreSQL 통일 1차 실행 완료에 닫힘 증거로 남긴다.

한 줄 결론

  • 현재 단계에서는 벡터, 그래프, 검색 같은 non-RDB 기능도 PostgreSQL로 통일하는 쪽이 더 합리적이며, Gemini식 퍼센트 비교는 이 결정을 뒤집을 정도의 SSOT 근거로 보기 어렵다.

근거 링크