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

11 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 같은 추가 조정을 권장한다.
  • Qdrant 공식 문서는 shard 이동, shard replication, replication factor를 문서화하고 있다.
  • Milvus 공식 문서는 standalone과 distributed를 분리하고, distributed 모드가 billion-scale or even larger scenarios를 목표로 한다고 설명한다.

3. 텍스트 검색 관점에서 PostgreSQL은 코어 기능이 넓지만, Elasticsearch는 퍼지/분산 검색 경험이 더 직접적이다

  • PostgreSQL 공식 Full Text Search 문서는 dictionaries, synonym dictionary, thesaurus dictionary, ranking, highlighting, preferred index types, limitations까지 별도 장으로 제공한다.
  • Elasticsearch 공식 문서의 fuzzy query는 Levenshtein edit distance 기반으로 검색어 변형(expansions)을 만들어 exact match를 수행하며, fuzziness, max_expansions, prefix_length 같은 파라미터를 1급 기능으로 제공한다.
  • 즉 PostgreSQL도 텍스트 검색을 충분히 수행할 수 있지만, 오타 허용, 분산 검색, 검색 전용 운영경험은 Elasticsearch 쪽이 더 직접적인 도구 체계를 갖고 있다.

4. 그래프 관점에서 Neo4j는 관계 순회를 데이터 구조 차원에서 최적화한다

  • PostgreSQL 공식 문서는 계층형/트리형 데이터를 위해 WITH RECURSIVE를 제공하며, 재귀 질의는 내부적으로 반복 평가된다고 설명한다.
  • Neo4j 공식 학습 문서는 index-free adjacency를 핵심 차별점으로 설명하며, 시작점만 인덱스로 찾고 이후는 포인터를 따라가며 traversal한다고 설명한다.
  • Neo4j 측 설명은 복잡한 관계 순회에서 index lookup과 join 수를 줄이는 구조적 이점을 강조한다.

5. 전용 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 하나로 시작은 충분히 현실적이지만 모든 역할을 영구 대체와는 다르다

  • 캐시, 벡터, 텍스트, 관계를 하나의 PostgreSQL에 모으면 운영 복잡도, 백업, 권한, CDC, 동기화 포인트를 크게 줄일 수 있다.
  • 특히 지금처럼 데이터 규모가 폭발적으로 크지 않고 팀이 작을수록 통합 저장소의 이점이 크다.
  • 다만 이것은 전용 DB가 쓸모없다가 아니라 전용 DB가 필요한 임계점 전까지는 PostgreSQL이 우선 후보가 될 수 있다는 의미다.

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

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

3. 벡터는 PostgreSQL + pgvector가 기본값이 될 수 있지만, 대규모 분산 요구가 생기면 전용 DB 우위가 다시 커진다

  • 로컬 필터와 관계형 데이터 조인을 함께 써야 하는 RAG, memory, catalog search는 PostgreSQL이 매우 자연스럽다.
  • 반면 shard/replica를 전제로 한 대규모 분산 운영, 초대형 컬렉션, 고QPS 독립 벡터 계층이 필요하면 Qdrant/Milvus 같은 전용 DB가 설계상 유리하다.
  • 따라서 벡터는 PostgreSQL 우선, 분산 임계점 도달 시 전용 DB 재도입이 가장 보수적인 해석이다.

4. 텍스트 검색은 기능 부족보다 운영 목적 차이로 보는 편이 정확하다

  • PostgreSQL FTS는 생각보다 넓은 기능을 이미 갖고 있다.
  • 하지만 검색이 서비스의 주기능이 되고, 오타 허용·검색 랭킹 튜닝·대규모 색인 재구성·검색 클러스터 운영이 중요해지면 Elasticsearch가 더 자연스럽다.
  • 즉 Postgres는 검색이 약하다보다 검색 전용 운영면은 Elasticsearch가 더 직접적이다가 더 정확하다.

5. 그래프는 가장 까다로운 영역이지만, 현 단계에서 전용 DB 유지 근거로 바로 이어지지는 않는다

  • PostgreSQL의 recursive CTE로 그래프성 질의를 구현할 수는 있다.
  • 그러나 복잡한 관계 탐색을 핵심 기능으로 삼는 순간, Neo4j의 index-free adjacency와 graph-native traversal 모델이 구조적으로 유리하다.
  • 다만 지금 목적이 극한 그래프 성능 최적화가 아니라 저장소 단일화와 운영 단순화라면, 이 구조적 약점만으로 Neo4j를 즉시 유지해야 한다고 결론내릴 필요는 없다.

6. 이번 주제의 안전한 결론은 전용 DB 유지 기준이 아니라 PostgreSQL 통일 전제를 분명히 하는 것이다

  • Redis 대비 10~50%, Neo4j 대비 10~50% 같은 퍼센트는 문서 첫 줄 결론으로는 위험하다.
  • 사용자가 본 Gemini 요약은 방향성 수준에서는 꽤 그럴듯하지만, 2025~2026년 최신 검증치처럼 받아들이기에는 출처 사슬이 충분히 드러나지 않는다.
  • 지금 더 중요한 질문은 아래와 같다.
  • 현재 운영 규모에서 PostgreSQL로 벡터/검색/그래프 요구를 먼저 수용할 수 있는가
  • 저장소 단일화로 줄어드는 운영 복잡도가 현재 성능 손실보다 더 큰가
  • 당장 전용 DB를 남겨야 할 만큼 이미 확인된 병목이 있는가

Unresolved

  • 현재 23/24/NAS 인프라 기준으로 어떤 데이터셋 규모와 동시성에서 PostgreSQL 단일화가 실제로 비용/성능 이득을 주는지 내부 벤치마크는 아직 없다.
  • robeing 운영에서 Neo4j/Chroma/Redis 계열을 PostgreSQL로 통일할 때 가장 먼저 병목이 되는 서비스가 무엇인지도 아직 계측되지 않았다.
  • 따라서 이 주제는 외부 일반론만으로 닫을 수 없고, 다음 단계에서 내부 대표 워크로드 벤치마크가 필요하다.

한 줄 결론

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

근거 링크