---
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)
- [non-RDB 계층 PostgreSQL 통일 계획](../plans/260317_nonrdb_계층_postgresql_통일_계획.md)
- [PostgreSQL Neo4j TCP healthcheck](../troubleshooting/260115_postgresql_neo4j_tcp_healthcheck.md)
- [백엔드: PostgreSQL, ChromaDB, Vector Memory 설계](https://github.com/happybell80/robeing/blob/main/DOCS/book/300_architecture/330_%EB%B0%B1%EC%97%94%EB%93%9C_PostgreSQL_ChromaDB_Vector_Memory.md)
- [Phase 2: ChromaDB + Neo4j 하이브리드 기억 회상 시스템 구현](https://github.com/happybell80/robeing/blob/main/DOCS/journey/troubleshooting/251016_phase2_hybrid_memory_implementation.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 같은 추가 조정을 권장한다.
- `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](https://github.com/happybell80/robeing/blob/main/DOCS/book/300_architecture/330_%EB%B0%B1%EC%97%94%EB%93%9C_PostgreSQL_ChromaDB_Vector_Memory.md)는 `PostgreSQL = 사실 기억`, `ChromaDB = 연상 기억`이라는 역할 분리를 설명한다.
- [251016_phase2_hybrid_memory_implementation.md](https://github.com/happybell80/robeing/blob/main/DOCS/journey/troubleshooting/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 통일 계획](../plans/260317_nonrdb_계층_postgresql_통일_계획.md) 기준의 `스키마/인덱스/랭킹 설계 실행`이다.

## 한 줄 결론

- 현재 단계에서는 벡터, 그래프, 검색 같은 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 text search functions/operators: https://www.postgresql.org/docs/current/functions-textsearch.html
- PostgreSQL Recursive Queries: https://www.postgresql.org/docs/current/queries-with.html
- PostgreSQL pg_trgm: https://www.postgresql.org/docs/current/pgtrgm.html
- PostgreSQL ltree: https://www.postgresql.org/docs/current/ltree.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