From 4bf5996e3b73a9268ba3ec4449a7e93098d82f44 Mon Sep 17 00:00:00 2001
From: happybell80 <happybell80@naver.com>
Date: Tue, 17 Mar 2026 00:04:15 +0900
Subject: [PATCH] Deepen PostgreSQL consolidation research

---
 ...�합_vs_전용db_구조성능_리서치.md | 69 +++++++++++--------
 1 file changed, 42 insertions(+), 27 deletions(-)

diff --git a/journey/research/260316_postgres_통합_vs_전용db_구조성능_리서치.md b/journey/research/260316_postgres_통합_vs_전용db_구조성능_리서치.md
index 293dc1e..910dfc9 100644
--- a/journey/research/260316_postgres_통합_vs_전용db_구조성능_리서치.md
+++ b/journey/research/260316_postgres_통합_vs_전용db_구조성능_리서치.md
@@ -13,6 +13,8 @@ tags: [infra, database, postgres, redis, pgvector, elasticsearch, neo4j, researc
 ## 관련 문서
 - [Infra Journey](../README.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)
 
 ## 목적
@@ -44,22 +46,33 @@ tags: [infra, database, postgres, redis, pgvector, elasticsearch, neo4j, researc
 - `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은 코어 기능이 넓지만, Elasticsearch는 퍼지/분산 검색 경험이 더 직접적이다
+### 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도 텍스트 검색을 충분히 수행할 수 있지만, `오타 허용`, `분산 검색`, `검색 전용 운영경험`은 Elasticsearch 쪽이 더 직접적인 도구 체계를 갖고 있다.
+- 즉 PostgreSQL은 `FTS + pg_trgm + JSON tsvector` 조합만으로도 일반 서비스 검색에 필요한 핵심 기능을 상당 부분 직접 제공한다.
 
-### 4. 그래프 관점에서 Neo4j는 관계 순회를 데이터 구조 차원에서 최적화한다
+### 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. `전용 DB 대비 Postgres 몇 %` 수치는 공식 SSOT로 고정하기 어렵다
+### 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을 보였다고 주장한다.
@@ -69,11 +82,11 @@ tags: [infra, database, postgres, redis, pgvector, elasticsearch, neo4j, researc
 
 ## Interpretation
 
-### 1. `PostgreSQL 하나로 시작`은 충분히 현실적이지만 `모든 역할을 영구 대체`와는 다르다
+### 1. 지금 이 아이디어를 닫는 데 필요한 핵심은 `PostgreSQL이 대체 가능한가`이지 `전용 DB가 영원히 불필요한가`가 아니다
 
-- 캐시, 벡터, 텍스트, 관계를 하나의 PostgreSQL에 모으면 운영 복잡도, 백업, 권한, CDC, 동기화 포인트를 크게 줄일 수 있다.
-- 특히 지금처럼 데이터 규모가 폭발적으로 크지 않고 팀이 작을수록 `통합 저장소`의 이점이 크다.
-- 다만 이것은 `전용 DB가 쓸모없다`가 아니라 `전용 DB가 필요한 임계점 전까지는 PostgreSQL이 우선 후보가 될 수 있다`는 의미다.
+- 현재 판단 대상은 장기 기술종결 선언이 아니라, `지금 운영 구조에서 ChromaDB/Neo4j/검색 전용 계층을 걷어내고 PostgreSQL로 옮길 수 있는가`다.
+- 위 Facts 기준으로 보면 PostgreSQL은 이미 벡터 타입/인덱스, FTS/phrase/web-style query, trigram similarity, recursive traversal, cycle detection, path-like 타입까지 갖고 있다.
+- 따라서 기능 목록만 놓고 보면 현재 논의 대상인 `벡터 + 검색 + 그래프`를 PostgreSQL로 통일할 최소 기능은 이미 충족한다.
 
 ### 2. 캐시는 `속도`보다 `TTL/eviction semantics` 차이가 더 본질적이다
 
@@ -81,38 +94,37 @@ tags: [infra, database, postgres, redis, pgvector, elasticsearch, neo4j, researc
 - 실제 구조 차이는 `Redis는 만료와 메모리 중심 접근을 기본 계약으로 제공`하고, PostgreSQL은 `기본적으로 영속성과 트랜잭션`을 우선한다는 점이다.
 - 따라서 `Postgres를 캐시처럼 쓰겠다`는 말은 가능하지만, `Redis의 운영 의미까지 완전히 대체`한다고 말하면 과장일 수 있다.
 
-### 3. 벡터는 `PostgreSQL + pgvector`가 기본값이 될 수 있지만, 대규모 분산 요구가 생기면 전용 DB 우위가 다시 커진다
+### 3. 벡터는 현재 워크로드 기준으로 PostgreSQL 이관 장애보다 `인덱스 설계 문제`가 더 크다
 
-- 로컬 필터와 관계형 데이터 조인을 함께 써야 하는 RAG, memory, catalog search는 PostgreSQL이 매우 자연스럽다.
-- 반면 shard/replica를 전제로 한 대규모 분산 운영, 초대형 컬렉션, 고QPS 독립 벡터 계층이 필요하면 Qdrant/Milvus 같은 전용 DB가 설계상 유리하다.
-- 따라서 벡터는 `PostgreSQL 우선, 분산 임계점 도달 시 전용 DB 재도입`이 가장 보수적인 해석이다.
+- 로빙 계열 벡터 검색은 메타데이터 필터, 사용자 단위 분리, top-k 검색, 기억 회상, 파일/RAG 결합처럼 관계형 데이터와 함께 움직이는 비중이 크다.
+- 이 유형은 별도 벡터 DB보다 `PostgreSQL + pgvector + 관계형 필터`가 오히려 자연스럽다.
+- 실제 남는 과제는 `HNSW/IVFFlat 선택`, `ef_search/iterative_scan`, `부분 인덱스/파티셔닝`, `halfvec/압축 여부` 같은 튜닝이지, 기능 부재가 아니다.
 
-### 4. 텍스트 검색은 `기능 부족`보다 `운영 목적 차이`로 보는 편이 정확하다
+### 4. 검색은 `FTS + pg_trgm` 조합으로 먼저 닫을 수 있다
 
-- PostgreSQL FTS는 생각보다 넓은 기능을 이미 갖고 있다.
-- 하지만 검색이 서비스의 주기능이 되고, 오타 허용·검색 랭킹 튜닝·대규모 색인 재구성·검색 클러스터 운영이 중요해지면 Elasticsearch가 더 자연스럽다.
-- 즉 `Postgres는 검색이 약하다`보다 `검색 전용 운영면은 Elasticsearch가 더 직접적이다`가 더 정확하다.
+- 사용자가 기대하는 검색은 보통 `정확 키워드`, `구문`, `웹검색식 입력`, `오타/부분일치`, `메타데이터 필터`, `랭킹`의 조합이다.
+- PostgreSQL은 `phraseto_tsquery`, `websearch_to_tsquery`, `setweight`, `jsonb_to_tsvector`, `pg_trgm` similarity를 모두 공식 기능으로 제공한다.
+- 따라서 현재 단계의 검색 통일은 `Elasticsearch 대체 불가 여부`를 묻기보다 `PostgreSQL 안에서 검색 스키마와 인덱스를 어떻게 짤지`를 묻는 단계로 보는 것이 맞다.
 
-### 5. 그래프는 가장 까다로운 영역이지만, 현 단계에서 전용 DB 유지 근거로 바로 이어지지는 않는다
+### 5. 그래프는 `무제한 자유 탐색`이 아니라 `경계 있는 관계 탐색`으로 재정의하면 PostgreSQL로 수렴시킬 수 있다
 
 - PostgreSQL의 recursive CTE로 그래프성 질의를 구현할 수는 있다.
-- 그러나 복잡한 관계 탐색을 핵심 기능으로 삼는 순간, Neo4j의 index-free adjacency와 graph-native traversal 모델이 구조적으로 유리하다.
-- 다만 지금 목적이 `극한 그래프 성능 최적화`가 아니라 `저장소 단일화와 운영 단순화`라면, 이 구조적 약점만으로 Neo4j를 즉시 유지해야 한다고 결론내릴 필요는 없다.
+- `SEARCH`와 `CYCLE` 구문, path array, `ltree` 같은 도구를 쓰면 bounded-depth traversal, 계층형 경로, 관계 추적은 공식 SQL 범위 안에서 구현할 수 있다.
+- 현재 로빙 문서에 적힌 Neo4j 용도도 초거대 공개 그래프 탐색이 아니라 `사건-감정-결과 관계 가중치`와 같은 제한된 관계망이므로, 현 단계에서는 PostgreSQL 모델 재설계로 충분히 흡수 가능한 범주에 가깝다.
 
-### 6. 이번 주제의 안전한 결론은 `전용 DB 유지 기준`이 아니라 `PostgreSQL 통일 전제`를 분명히 하는 것이다
+### 6. 이 아이디어를 닫는 데 남은 미확정은 `가능한가`가 아니라 `어떻게 옮길까`에 가깝다
 
 - `Redis 대비 10~50%`, `Neo4j 대비 10~50%` 같은 퍼센트는 문서 첫 줄 결론으로는 위험하다.
 - 사용자가 본 Gemini 요약은 `방향성` 수준에서는 꽤 그럴듯하지만, `2025~2026년 최신 검증치`처럼 받아들이기에는 출처 사슬이 충분히 드러나지 않는다.
-- 지금 더 중요한 질문은 아래와 같다.
-- `현재 운영 규모에서 PostgreSQL로 벡터/검색/그래프 요구를 먼저 수용할 수 있는가`
-- `저장소 단일화로 줄어드는 운영 복잡도가 현재 성능 손실보다 더 큰가`
-- `당장 전용 DB를 남겨야 할 만큼 이미 확인된 병목이 있는가`
+- 이 리서치 기준으로는 `현재 운영 규모에서 PostgreSQL로 먼저 수용 불가`라는 직접 근거가 아직 없다.
+- 그래서 다음 질문은 `전용 DB를 남겨야 하나`보다 `Chroma 컬렉션을 어떤 테이블/인덱스로 옮길까`, `Neo4j 관계를 어떤 스키마와 recursive query로 바꿀까`, `검색 랭킹을 어떤 column weighting으로 설계할까`가 된다.
 
 ## Unresolved
 
-- 현재 `23/24/NAS` 인프라 기준으로 어떤 데이터셋 규모와 동시성에서 PostgreSQL 단일화가 실제로 비용/성능 이득을 주는지 내부 벤치마크는 아직 없다.
-- `robeing` 운영에서 Neo4j/Chroma/Redis 계열을 PostgreSQL로 통일할 때 가장 먼저 병목이 되는 서비스가 무엇인지도 아직 계측되지 않았다.
-- 따라서 이 주제는 외부 일반론만으로 닫을 수 없고, 다음 단계에서 내부 대표 워크로드 벤치마크가 필요하다.
+- `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` 공식을 아직 정하지 않았다.
+- 즉 이 주제의 다음 단계는 추가 일반론 리서치가 아니라 `스키마/인덱스/랭킹 설계 계획`이다.
 
 ## 한 줄 결론
 
@@ -123,7 +135,10 @@ tags: [infra, database, postgres, redis, pgvector, elasticsearch, neo4j, researc
 - 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