MongoDB와 PostgreSQL 사이: JSONB·pgvector·TCO로 보는 데이터베이스 선택

PostgreSQL로 다시 돌아오는 이유

4년간 MongoDB를 운영한 팀이 PostgreSQL을 다시 선택하는 흐름이 2026년에 뚜렷해지고 있다. 신규 프로젝트에서는 PostgreSQL이 MongoDB보다 3:1 비율로 우세하며, 성숙한 JSONB 지원과 pgvector 기반 벡터 검색 통합이 전환의 주요 배경으로 언급된다.

이는 관계형 데이터베이스에 대한 취향의 변화라기보다 운영 복잡도와 TCO(Total Cost of Ownership)를 다시 계산한 결과에 가깝다. 초기 개발에서는 스키마 없는 문서 모델이 속도를 내기 쉽지만, 서비스가 커지면 데이터 일관성 및 마이그레이션 관리 비용이 커질 수 있다. 비즈니스 로직이 복잡해질수록 문서 사이의 관계를 처리해야 하는 경우도 늘어난다. MongoDB의 $lookup은 관계형 JOIN과 비교해 성능과 표현력 측면에서 제약이 있다.

PostgreSQL은 9.4(2014년)에서 JSONB를 도입한 뒤 GIN 인덱스, JSON_TABLE(v17), 경로 연산자를 안정화했다. 여기에 AI 애플리케이션이 벡터와 메타데이터를 하나의 데이터베이스에서 처리하려는 요구까지 더해지며 pgvector 채택이 빨라지고 있다.

⤢✕

JSONB와 BSON이 다루는 방식

PostgreSQL JSONB와 MongoDB BSON은 모두 JSON 형태의 데이터를 저장하지만, 저장 구조와 쿼리 모델은 다르다.

PostgreSQL JSONB는 JSON을 분해된 바이너리 형식으로 저장한다. 이 과정에서 키 정렬과 중복 키 제거가 일어나며, 삽입 시에는 파싱 오버헤드가 있지만 읽을 때 재파싱할 필요가 없다. GIN(Generalized Inverted Index) 인덱스로 중첩 필드를 직접 인덱싱할 수 있고, 관계형 컬럼과 JSONB 컬럼을 같은 테이블에 섞어 둘 수 있다.

MongoDB BSON은 타입 정보를 바이트로 인코딩하는 Binary JSON 포맷이다. 삽입 오버헤드는 낮고 문서 전체의 직렬화·역직렬화가 최소화된다. 중첩 필드는 멀티키 인덱스(Multikey Index)로 처리하며, 같은 데이터 기준 저장 공간은 MongoDB가 최대 2.23배 작다.

특성	PostgreSQL JSONB	MongoDB BSON
삽입 성능	파싱 오버헤드로 상대적 열세	낮은 오버헤드
읽기 성능	재파싱 불필요, 인덱스 활용 우수	문서 역직렬화 필요
저장 공간	상대적으로 큼	최대 2.23배 효율적
인덱싱	GIN, B-tree 중첩 지원	멀티키 인덱스
SQL 호환성	완전한 SQL 쿼리 지원	MQL(MongoDB Query Language)
트랜잭션	완전한 ACID	다중 문서 트랜잭션 지원(v4+)

MongoDB가 2026년에 발표한 벤치마크는 256명 동시 사용자, 30분, 약 1300만 문서 환경의 업데이트 집중 워크로드를 측정했다. 다만 Atlas는 측정 도중 M40에서 M50으로 자동 스케일업됐고 PostgreSQL은 같은 인스턴스를 유지했으므로, 이를 공정한 비교로 보기는 어렵다.

운영 환경에서 나타나는 경향도 워크로드에 따라 나뉜다. 읽기가 중심이면 PostgreSQL JSONB와 GIN 인덱스가 MongoDB와 동등하거나 우세하다. 반대로 업데이트가 집중되고 문서 안의 필드를 세밀하게 바꾸는 작업에서는 MongoDB의 in-place update가 JSONB 전체 재기록보다 유리하다. 복잡한 집계는 PostgreSQL의 SQL과 Window Function이 MongoDB Aggregation Pipeline보다 표현력이 높고, 전문 검색과 문서 검색을 함께 써야 할 때는 tsvector와 JSONB 조합이 MongoDB Atlas Search보다 비용 효율적이다.

-- PostgreSQL JSONB 활용 예시: 중첩 필드 인덱싱과 쿼리
CREATE INDEX idx_user_profile_country
ON users USING GIN ((profile -> 'address'));

-- JSON_TABLE (PostgreSQL 17+): 문서를 행으로 변환
SELECT u.id, t.city, t.country
FROM users u,
JSON_TABLE(u.profile, '$.address' COLUMNS (
    city TEXT PATH '$.city',
    country TEXT PATH '$.country'
)) AS t
WHERE t.country = 'KR';

-- JSONB와 관계형 컬럼 혼합 JOIN
SELECT o.id, o.total, u.email, o.metadata->>'source' AS source
FROM orders o
JOIN users u ON o.user_id = u.id
WHERE o.metadata @> '{"channel": "mobile"}'
  AND o.total > 100000;

벡터와 메타데이터를 한곳에 둘 때

pgvector 0.8은 PostgreSQL 안에서 HNSW 인덱스를 사용해 약 95% ANN(Approximate Nearest Neighbor) 재현율을 달성한다. 외부 벡터 DB를 두지 않아도 되는 핵심 가치는 검색 성능만이 아니라 운영 구성을 줄이는 데 있다.

⤢✕

벡터와 메타데이터를 같은 트랜잭션에서 원자적으로 갱신할 수 있고, 유사도 검색 결과에 SQL WHERE, JOIN, 집계를 바로 적용할 수 있다. 별도 벡터 DB의 인프라, 모니터링, 인증 관리도 필요 없으며 네트워크 홉이 사라져 P99 레이턴시도 감소한다.

시나리오	pgvector	외부 벡터 DB
벡터 수 < 100만	충분	과잉
벡터 수 1000만+	성능 한계	권장
다중 모달(이미지+텍스트)	제한적	네이티브 지원
실시간 스트리밍 색인	가능	최적화됨
필터링 벡터 검색	우수	가변적
멀티테넌시 격리	스키마 분리	네임스페이스

벡터 수가 1000만 이하이고 필터링 검색 비중이 높은 AI 애플리케이션에서는 pgvector가 외부 벡터 DB와 비교해 총 운영 비용을 30~60% 절감할 수 있다.

비용 구조에서 확인할 지점

항목	MongoDB Atlas (M40)	PostgreSQL (RDS r6g.xlarge)
인프라 비용/월	$3,000~$8,000	$800~$2,500
운영 인력	MongoDB 전문가 필요	PostgreSQL DBA (범용)
벡터 검색	Atlas Vector Search 추가 비용	pgvector 포함 (무료)
전문 검색	Atlas Search 추가 비용	tsvector 포함 (무료)
마이그레이션 비용	진입 장벽 낮음	초기 전환 비용 발생

동일 처리량을 기준으로 PostgreSQL 배포가 MongoDB Atlas보다 연간 2~6만 달러를 절감한 사례가 보고됐다. 다만 이 계산에는 애플리케이션 코드 변경, 팀 재교육, 마이그레이션 기간이 들어 있지 않다. 월별 인프라 비용만으로 기술 선택을 확정하기 어려운 이유다.

⤢✕

문서 모델을 관계형 구조로 옮기는 방법

MongoDB 컬렉션을 PostgreSQL로 옮길 때는 세 방향을 고려할 수 있다. 문서를 jsonb 컬럼에 그대로 담는 방식은 변경 폭을 줄여 빠르게 이전할 수 있다. 자주 조회하는 필드만 전용 컬럼으로 꺼내고 나머지는 JSONB에 남기는 하이브리드 모델은 조회와 유연성 사이에서 균형을 잡는다. 문서 구조를 관계형 스키마로 완전히 바꾸는 방식은 장기 유지보수성에 가장 유리하다.

-- 패턴 2: 하이브리드 모델 예시
CREATE TABLE products (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    name TEXT NOT NULL,         -- 자주 조회되는 필드: 전용 컬럼
    price NUMERIC(12,2),        -- 자주 조회되는 필드: 전용 컬럼
    category TEXT,              -- 자주 조회되는 필드: 전용 컬럼
    attributes JSONB,           -- 가변적인 속성: JSONB 유지
    embedding vector(1536),     -- AI 검색용 벡터
    created_at TIMESTAMPTZ DEFAULT now()
);

CREATE INDEX idx_products_category ON products(category);
CREATE INDEX idx_products_attrs ON products USING GIN(attributes);
CREATE INDEX idx_products_embedding ON products
    USING hnsw(embedding vector_cosine_ops);

전환은 파일럿과 검증을 거쳐 진행하는 편이 안전하다. 먼저 쿼리 패턴, 데이터 볼륨, 인덱스 사용률을 확인하고 문서의 각 필드를 컬럼으로 둘지 JSONB로 둘지 설계한다. 이어 10% 데이터로 성능을 검증한 뒤 기준을 충족하면 전체 데이터를 이전한다. mongodump + pgloader 또는 ETL 파이프라인을 사용할 수 있다. 이후 신규 데이터를 양쪽에 기록하는 이중 쓰기 기간을 운영하고, 읽기를 PostgreSQL로 옮긴 다음 MongoDB 읽기를 중단한다. 검증을 마친 뒤에만 MongoDB를 폐기한다.

⤢✕

이 과정에서는 MongoDB 인덱스를 PostgreSQL의 등가물로 다시 매핑해야 한다. 예를 들어 멀티키 인덱스는 GIN을 검토할 수 있다. Aggregation Pipeline은 SQL Window Function과 CTE로 전환하고, MQL을 쓰던 애플리케이션 쿼리 레이어도 전면 재작성한다. 다중 문서 트랜잭션은 정규화된 관계형 구조를 기준으로 경계를 다시 설계할 수 있다.

MongoDB가 더 맞는 환경

PostgreSQL을 향한 회귀가 모든 상황의 답은 아니다. MongoDB는 네이티브 수평 쓰기 샤딩이 필요한 경우 추가 확장 없이 쓰기 트래픽을 수평 분산할 수 있다. PostgreSQL에서는 Citus 같은 외부 확장이 필요하다.

문서 내부 필드를 세밀하게 갱신하는 초고속 쓰기 워크로드도 MongoDB에 유리할 수 있다. Atlas Charts, Atlas Device Sync, App Services에 깊게 통합된 환경이라면 생태계 전환 비용도 따져야 한다. MongoDB와 MQL에 숙련된 팀이 PostgreSQL로 옮기면서 겪을 생산성 손실 역시 기술 기능표만으로는 계산되지 않는다.

JSONB, pgvector, SQL의 조합은 문서·관계형·벡터 데이터를 ACID 트랜잭션과 함께 다룰 수 있게 한다. 그러나 데이터베이스의 선택은 트렌드보다 비즈니스 요구사항, 운영 현실, 팀이 이미 보유한 역량을 기준으로 내려야 한다.