Add PostgreSQL consolidation research and idea

journey/README.md

@@ -55,6 +55,7 @@
 - [내부 NAS 직접 Go 동기화 아이디어](./ideas/260313_internal_nas_direct_go_sync_아이디어.md)
 - [컴퍼니엑스 직원용 모바일 파일 포털 아이디어](./ideas/260307_companyx_mobile_file_portal_아이디어.md)
 - [23장애시 24서버 임시진입면승격 아이디어](./ideas/260309_23장애시_24서버_임시진입면승격_아이디어.md)
+- [모든 DB를 PostgreSQL로 통일하는 아이디어](./ideas/260316_모든db를_postgresql로_통일하는_아이디어.md)
 - [외부 NAS -> 내부 NAS 컴퍼니엑스 동기화 리서치](./research/260307_external_nas_companyx_sync_research.md)
 - [외부 NAS -> 내부 NAS 컴퍼니엑스 실시간동기화 리서치](./research/260312_external_nas_companyx_실시간동기화_리서치.md)
 - [외부 NAS 동기화 Go/Python/DSM 도구화 리서치](./research/260313_external_nas_sync_go_python_dsm_tooling_리서치.md)
@@ -68,6 +69,7 @@
 - [51123 포트 진입점 프로젝트 경계 리서치](./research/260310_51123_포트_진입점_프로젝트경계_리서치.md)
 - [24 자동배포 0초 종료와 runtime SSOT 불일치 리서치](./research/260311_24자동배포_0초종료_runtime_ssot불일치_리서치.md)
 - [goosefarminvesting 도메인 DNS HTTPS nginx 진입상태 리서치](./research/260311_goosefarminvesting_도메인_DNS_https_nginx_진입상태_리서치.md)
+- [PostgreSQL 통합 vs 전용 DB 구조성능 리서치](./research/260316_postgres_통합_vs_전용db_구조성능_리서치.md)
 - [51123 구 IP 하드코딩 실행 경로 제거 계획](./plans/260309_51123_구IP하드코딩_실행경로제거_계획.md)
 - [24서버 실서비스 운영전환 계획](./plans/260309_24서버_실서비스운영전환_계획.md)
 - [24 자동배포 0초 종료 runtime SSOT 복구 계획](./plans/260311_24자동배포_0초종료_runtime_ssot복구_계획.md)

journey/ideas/260316_모든db를_postgresql로_통일하는_아이디어.md

@@ -0,0 +1,77 @@
+---
+tags: [infra, database, postgres, ideas, consolidation]
+---
+
+# 260316 모든 DB를 PostgreSQL로 통일하는 아이디어
+
+## 상위 원칙
+- [Infra Project Identity](../../00_Philosophy/00_IDENTITY/Infra_Project_Identity.md)
+- [Core Infrastructure Principles](../../00_Philosophy/01_PRINCIPLES/Core_Infrastructure_Principles.md)
+- 공통 작성 원칙: [0_VALUE Writing Principles](https://github.com/happybell80/0_VALUE/blob/main/02_Governance/writing-principles.md)
+
+## 관련 문서
+- [Infra Journey](../README.md)
+- [PostgreSQL 통합 vs 전용 DB 구조성능 리서치](../research/260316_postgres_통합_vs_전용db_구조성능_리서치.md)
+- [PostgreSQL Neo4j TCP healthcheck](../troubleshooting/260115_postgresql_neo4j_tcp_healthcheck.md)
+
+## 문제 인식
+
+- 지금 인프라와 서비스 계층에는 `PostgreSQL`, `ChromaDB`, `Neo4j`, 경우에 따라 `Redis/검색 전용 계층`처럼 역할이 나뉘는 구조가 남아 있다.
+- 이 구조는 각 역할에 최적화된 장점이 있지만, 운영자 입장에서는 백업, 장애 추적, 권한, 런타임 SSOT, 복구 절차, 데이터 정합성 관리가 분산된다.
+- 특히 팀 규모가 작고 서비스 경계가 자주 바뀌는 단계에서는 `DB를 여러 개 운영하는 비용`이 기능 이점보다 더 크게 느껴질 수 있다.
+
+## 현재상태 -> 기대상태
+
+### 현재상태
+
+- 관계형 데이터는 PostgreSQL이 맡는다.
+- 일부 벡터/메모리/RAG 계층은 ChromaDB 같은 별도 저장소가 맡는다.
+- 관계 탐색 일부는 Neo4j 같은 graph-native 저장소를 전제로 해석된다.
+- 캐시/검색도 기능별로 분리 여지가 있다.
+- 결과적으로 저장소 선택 이유가 `현재 필수 요구`보다 `과거 선택의 잔존`일 가능성이 섞여 있다.
+
+### 기대상태
+
+- 가능한 많은 데이터를 PostgreSQL 하나로 모은다.
+- 벡터는 `pgvector` 계열로, 텍스트 검색은 PostgreSQL FTS로, 캐시성 데이터는 PostgreSQL 내부 구조로 먼저 수용 가능한지 본다.
+- 전용 DB는 `구조적으로 대체 불가능한 요구`가 있는 경우에만 남긴다.
+- 운영 SSOT, 백업, 접근통제, 모니터링, 장애 복구 기준을 PostgreSQL 중심으로 단순화한다.
+
+## 아이디어
+
+- 기본 전략을 `polyglot by default`가 아니라 `PostgreSQL first`로 바꾼다.
+- 새 기능을 열 때 먼저 묻는 질문을 아래처럼 바꾼다.
+- `이 요구를 PostgreSQL로 먼저 수용할 수 있는가`
+- `정말 전용 DB가 없으면 안 되는 구조적 이유가 있는가`
+- `전용 DB를 유지할 경우 운영 복잡도 증가를 어떤 가치로 상쇄하는가`
+
+핵심 한 줄은 아래와 같다.
+
+- `전용 DB를 기본값으로 두지 말고, PostgreSQL에서 막히는 요구가 확인될 때만 별도 저장소를 남긴다.`
+
+## 기대 효과
+
+- 백업, 복구, 권한, 감사, 접근 경로가 단순해진다.
+- 서비스 간 데이터 동기화와 이중 저장 부담이 줄어든다.
+- `workspace-config`와 런타임 SSOT 해석도 더 직접적이 된다.
+- 운영자가 장애 시 봐야 하는 저장소 종류와 복구 절차가 줄어든다.
+
+## 검증이 필요한 이유
+
+- 캐시, 벡터, 텍스트, 그래프는 단순 저장이 아니라 `질의 패턴`이 다르다.
+- 특히 그래프 순회와 대규모 분산 벡터 검색은 PostgreSQL 통합 전략의 약한 지점일 수 있다.
+- 따라서 이 아이디어는 `좋아 보이는 단순화`만으로 채택하면 안 되고, 대표 워크로드 기준으로 병목과 손실을 먼저 확인해야 한다.
+
+## 이 문서에서 빼야 하는 내용
+
+- 어떤 저장소를 언제 끌 것인지, 마이그레이션 순서, 롤백 방식, 성능 게이트는 `plans`로 보낸다.
+- 실제 벤치마크 결과, 운영 로그, cut-over 기록은 `research` 또는 `worklog`로 보낸다.
+- 이미 운영 중인 특정 서비스의 개별 장애 원인은 `troubleshooting`으로 보낸다.
+
+## 현재 판단
+
+- 이 아이디어는 충분히 검토할 가치가 있다.
+- 다만 `모든 DB를 바로 없앤다`가 아니라 `PostgreSQL 중심 단일화가 기본값이 되는가`를 묻는 방향이 더 안전하다.
+- 현재 시점에서 가장 현실적인 해석은 아래 문장이다.
+
+`인프라 기본 전략을 전용 DB 우선이 아니라 PostgreSQL 우선으로 바꾸고, 전용 DB는 구조적으로 필요한 경우에만 남기는 방향을 검토할 가치가 있다.`

journey/research/260316_postgres_통합_vs_전용db_구조성능_리서치.md

@@ -0,0 +1,133 @@
+---
+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)
+
+## 목적
+
+- `PostgreSQL 하나로 Redis/Vector DB/Elasticsearch/Neo4j 역할까지 통합할 수 있는가`를 인프라 관점에서 다시 정리합니다.
+- `전용 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. 그래프는 PostgreSQL 통합 전략의 가장 약한 고리다
+
+- PostgreSQL의 recursive CTE로 그래프성 질의를 구현할 수는 있다.
+- 그러나 복잡한 관계 탐색을 핵심 기능으로 삼는 순간, Neo4j의 index-free adjacency와 graph-native traversal 모델이 구조적으로 유리하다.
+- 따라서 `모든 DB를 PostgreSQL로 통일` 아이디어에서 가장 늦게 결정해야 할 영역은 그래프다.
+
+### 6. 이번 주제의 안전한 결론은 `숫자 SSOT`가 아니라 `전환 기준 SSOT`를 만드는 것이다
+
+- `Redis 대비 10~50%`, `Neo4j 대비 10~50%` 같은 퍼센트는 문서 첫 줄 결론으로는 위험하다.
+- 사용자가 본 Gemini 요약은 `방향성` 수준에서는 꽤 그럴듯하지만, `2025~2026년 최신 검증치`처럼 받아들이기에는 출처 사슬이 충분히 드러나지 않는다.
+- 더 안전한 SSOT는 아래 질문들이다.
+- `TTL이 핵심 기능인가`
+- `분산 벡터 shard/replica가 지금 필요한가`
+- `오타 허용/검색 전용 랭킹 운영이 핵심인가`
+- `다단 관계 순회가 핵심 제품 기능인가`
+
+## Unresolved
+
+- 현재 `23/24/NAS` 인프라 기준으로 어떤 데이터셋 규모와 동시성에서 PostgreSQL 단일화가 실제로 비용/성능 이득을 주는지 내부 벤치마크는 아직 없다.
+- `robeing` 운영에서 Neo4j/Chroma/Redis 계열을 PostgreSQL로 통일할 때 가장 먼저 병목이 되는 서비스가 무엇인지도 아직 계측되지 않았다.
+- 따라서 이 주제는 외부 일반론만으로 닫을 수 없고, 다음 단계에서 내부 대표 워크로드 벤치마크가 필요하다.
+
+## 한 줄 결론
+
+- `PostgreSQL로 대부분을 통합`하는 방향은 충분히 현실적이지만, `전용 DB보다 몇 % 느리다` 같은 숫자를 SSOT로 고정하기보다 `어떤 기능 요구가 나오면 전용 DB를 유지/재도입할지`를 기준으로 삼는 편이 안전하다.
+
+## 근거 링크
+
+- 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