---
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)
- [non-RDB 계층 PostgreSQL 통일 계획](../plans/260317_nonrdb_계층_postgresql_통일_계획.md)
- [non-RDB 계층 PostgreSQL 통일 1차 실행 완료](../worklog/260317_nonrdb_계층_postgresql_통일_1차_실행완료.md)
- [PostgreSQL Neo4j TCP healthcheck](../troubleshooting/260115_postgresql_neo4j_tcp_healthcheck.md)

## 문제 인식

- 지금 인프라와 서비스 계층에는 `PostgreSQL`, `ChromaDB`, `Neo4j`, 경우에 따라 `Redis/검색 전용 계층`처럼 역할이 나뉘는 구조가 남아 있다.
- 이 구조는 각 역할에 최적화된 장점이 있지만, 운영자 입장에서는 백업, 장애 추적, 권한, 런타임 SSOT, 복구 절차, 데이터 정합성 관리가 분산된다.
- 특히 팀 규모가 작고 서비스 경계가 자주 바뀌는 단계에서는 `DB를 여러 개 운영하는 비용`이 기능 이점보다 더 크게 느껴질 수 있다.
- 이번 아이디어의 직접 대상은 `ChromaDB`, `Neo4j`, 검색 전용 저장소 같은 non-RDB 계층이며, `Redis 전체 캐시 전략`은 지금 문서의 범위에 넣지 않는다.

## 현재상태 -> 기대상태

### 현재상태

- 관계형 데이터는 PostgreSQL이 맡는다.
- 일부 벡터/메모리/RAG 계층은 ChromaDB 같은 별도 저장소가 맡는다.
- 관계 탐색 일부는 Neo4j 같은 graph-native 저장소를 전제로 해석된다.
- 캐시/검색도 기능별로 분리 여지가 있다.
- 결과적으로 저장소 선택 이유가 `현재 필수 요구`보다 `과거 선택의 잔존`일 가능성이 섞여 있다.

### 기대상태

- 가능한 많은 데이터를 PostgreSQL 하나로 모은다.
- 벡터는 `pgvector`, 그래프성 질의는 PostgreSQL 관계/재귀 모델, 텍스트 검색은 PostgreSQL FTS와 `pg_trgm`으로 통일한다.
- 현재 남아 있는 전용 DB는 단계적으로 제거 대상에 둔다.
- 운영 SSOT, 백업, 접근통제, 모니터링, 장애 복구 기준을 PostgreSQL 중심으로 단순화한다.

## 아이디어

- 기본 전략을 `polyglot by default`가 아니라 `PostgreSQL only until proven otherwise`로 바꾼다.
- 새 기능을 열 때 기본 저장소는 PostgreSQL로 고정한다.
- 벡터는 `pgvector`, 검색은 `FTS + pg_trgm`, 그래프성 탐색은 관계 모델과 `WITH RECURSIVE`를 기본 해법으로 사용한다.
- 기존 ChromaDB, Neo4j, 검색 전용 계층도 후속 단계에서 PostgreSQL로 흡수하는 방향을 기본값으로 둔다.

핵심 한 줄은 아래와 같다.

- `지금 단계에서는 전용 DB를 줄이고, non-RDB 기능까지 PostgreSQL로 흡수하는 것을 기본 방향으로 삼는다.`

## 기대 효과

- 백업, 복구, 권한, 감사, 접근 경로가 단순해진다.
- 서비스 간 데이터 동기화와 이중 저장 부담이 줄어든다.
- `workspace-config`와 런타임 SSOT 해석도 더 직접적이 된다.
- 운영자가 장애 시 봐야 하는 저장소 종류와 복구 절차가 줄어든다.
- `rb8001`, `skill-rag-file` 같은 실제 경로에서 `PostgreSQL만 보면 된다`는 운영 해석이 가능해진다.

## 검증이 필요한 이유

- 캐시, 벡터, 텍스트, 그래프는 단순 저장이 아니라 `질의 패턴`이 다르다.
- 특히 그래프 순회와 대규모 분산 벡터 검색은 PostgreSQL 쪽에서 쿼리 설계와 인덱스 설계가 더 중요해진다.
- 따라서 이 아이디어는 `전용 DB 유지 여부`를 따지는 단계가 아니라, `PostgreSQL로 옮겼을 때 어떤 쿼리·인덱스·테이블 설계가 필요한가`를 검증하는 단계로 봐야 한다.

## 이 문서에서 빼야 하는 내용

- 어떤 저장소를 언제 끌 것인지, 마이그레이션 순서, 롤백 방식, 성능 게이트는 `plans`로 보낸다.
- 실제 벤치마크 결과, 운영 로그, cut-over 기록은 `research` 또는 `worklog`로 보낸다.
- 이미 운영 중인 특정 서비스의 개별 장애 원인은 `troubleshooting`으로 보낸다.

## 현재 판단

- 이 아이디어는 검토 대상이 아니라 현재 방향으로 고정할 수 있다.
- 현 단계 목표는 `전용 DB와 non-RDB 저장소를 유지할 이유를 찾는 것`이 아니라 `PostgreSQL 통일 경로를 설계하는 것`이다.
- 실행 순서와 제거 대상 우선순위는 [non-RDB 계층 PostgreSQL 통일 계획](../plans/260317_nonrdb_계층_postgresql_통일_계획.md)으로 넘긴다.
- 경계도 같이 고정한다.
  - 지금 없애는 대상: `ChromaDB`, `Neo4j`, 검색 전용 저장소
  - 지금 보류하는 대상: `Redis 전체 캐시 전략`
- 현재 시점의 해석은 아래 문장으로 고정한다.

`인프라의 벡터, 그래프, 검색 계층은 지금부터 PostgreSQL로 통일하는 방향으로 정리하고, 전용 DB는 현 단계에서 제거 대상으로 본다.`

## 실행 결과

- `skill-rag-file`은 문서 벡터 검색을 `team_document_chunk + pgvector(768)`로 옮겼다.
- `rb8001`은 메모리 벡터/그래프와 coldmail 기억, startup valuation 비교 경로를 PostgreSQL로 옮겼다.
- 24 런타임 검증에서 `rb8001 /health`는 `memory_store=postgresql`을 반환했고, 실제 coldmail/valuation/premia 경로도 PostgreSQL에서 동작했다.
- 따라서 이 아이디어는 더 이상 `좋겠다` 수준이 아니라 [non-RDB 계층 PostgreSQL 통일 1차 실행 완료](../worklog/260317_nonrdb_계층_postgresql_통일_1차_실행완료.md)로 연결된 실행 완료 항목이다.