---
tags: [infra, database, postgres, redis, pgvector, elasticsearch, neo4j, research]
---

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

## 상위 원칙
- [Infra Project Identity](../../00_Philosophy/00_IDENTITY/Infra_Project_Identity.md)
- [Core Infrastructure Principles](../../00_Philosophy/01_PRINCIPLES/Core_Infrastructure_Principles.md)
- [Operational Guardrails](../../00_Philosophy/02_GUARDRAILS/Operational_Guardrails.md)
- 공통 작성 원칙: [0_VALUE Writing Principles](https://github.com/happybell80/0_VALUE/blob/main/02_Governance/writing-principles.md)

## 관련 문서
- [Infra Journey](../README.md)
- [PostgreSQL Neo4j TCP healthcheck](../troubleshooting/260115_postgresql_neo4j_tcp_healthcheck.md)
- [내부 NAS 직접 Go 동기화 아이디어](../ideas/260313_internal_nas_direct_go_sync_아이디어.md)

## 목적

- 벡터, 그래프, 검색 같은 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 근거로 보기 어렵다.

## 근거 링크

- Redis EXPIRE: https://redis.io/docs/latest/commands/expire/
- PostgreSQL CREATE TABLE / UNLOGGED: https://www.postgresql.org/docs/current/sql-createtable.html
- PostgreSQL Full Text Search: https://www.postgresql.org/docs/current/textsearch.html
- PostgreSQL Recursive Queries: https://www.postgresql.org/docs/current/queries-with.html
- pgvector README: https://github.com/pgvector/pgvector
- Qdrant distributed deployment: https://qdrant.tech/documentation/guides/distributed_deployment/
- Milvus overview: https://milvus.io/docs/overview.md
- Elasticsearch fuzzy query: https://www.elastic.co/docs/reference/query-languages/query-dsl/query-dsl-fuzzy-query
- Neo4j graph platform / index-free adjacency 설명: https://neo4j.com/graphacademy/training-overview-40/02-overview40-neo4j-graph-platform/
- Timescale pgvectorscale 발표: https://www.timescale.com/newsroom/postgresql-is-now-faster-than-pinecone-75-cheaper-with-new-open-source