Lv.2 초급PostgreSQL / MongoDB

2026.05.2817분 읽기Lv.2 초급

시리즈트랜잭션? PostgreSQL과 MongoDB의 차이점은?! · 파트 4시리즈 허브 보기

2026년 PostgreSQL vs MongoDB 실전 선택 가이드 — Part 4

4개 파트 시리즈의 최종편. OLTP·OLAP·대용량 쓰기 벤치마크 비교, 수직 vs 수평 확장 전략, pgvector vs Atlas Vector Search AI 워크로드, 라이선스 현실, 그리고 내 워크로드에 맞는 DB를 고르는 명확한 판단 기준을 정리한다.

시리즈 구성 — 트랜잭션? PostgreSQL과 MongoDB의 차이점은?!

• Part 1 — 트랜잭션의 기본 개념과 ACID 원칙
• Part 2 — PostgreSQL 트랜잭션 심화 (MVCC, 격리 수준, 데드락, VACUUM)
• Part 3 — MongoDB의 트랜잭션 진화와 멀티 도큐먼트 트랜잭션
• Part 4 — 실전 비교: 성능, 확장성, 2026년 선택 가이드 (현재 편)

목차

1. 들어가며 — "어느 쪽이 더 낫다"는 질문이 틀렸다
2. 성능 벤치마크: 워크로드별 실제 수치
   • 2-1. OLTP (트랜잭션 처리)
   • 2-2. 복잡한 분석 쿼리 (OLAP)
   • 2-3. 쓰기 집약적 워크로드
   • 2-4. 벤치마크 해석 시 주의점
3. 확장성: 수직 vs 수평
   • 3-1. PostgreSQL의 확장 전략
   • 3-2. MongoDB의 확장 전략
4. 2026년 AI 시대의 벡터 검색 경쟁
5. 라이선스와 비용: 간과하면 안 되는 현실
6. 실전 사용 사례: 누가 무엇을 쓰는가
7. 최종 선택 가이드: 내 상황에 맞는 DB는?
   • 7-1. 트랜잭션 관점 요약 비교
   • 7-2. 시나리오별 선택 기준
   • 7-3. 판단 플로우차트
8. 시리즈 최종 정리
9. 실무 적용 노트

1. 들어가며

4개 파트에 걸쳐 트랜잭션의 기초부터, PostgreSQL의 MVCC와 VACUUM, MongoDB의 WiredTiger와 멀티 도큐먼트 트랜잭션까지 살펴봤다. 이제 진짜 질문 앞에 섰다.

"그래서 나는 무엇을 써야 하는가?"

2026년 현재, 이 질문은 과거보다 훨씬 어려워졌다. PostgreSQL은 JSONB, pgvector, 파티셔닝 등으로 NoSQL 영역을 파고들고 있고, MongoDB는 ACID 트랜잭션, 벡터 검색, Atlas 플랫폼으로 엔터프라이즈 시장을 공략하고 있다. 경계가 흐려진 만큼, 단순한 "SQL vs NoSQL" 프레임은 이미 쓸모없어졌다.

이번 파트에서는 최신 벤치마크 수치와 실제 기업 사례, 그리고 명확한 선택 기준을 제시한다.

2. 성능 벤치마크: 워크로드별 실제 수치

성능 비교에서 가장 경계해야 할 것은 "어느 DB가 더 빠르다"는 단순 결론이다. 워크로드의 성격이 결과를 완전히 뒤집기 때문이다.

벤치마크 면책 고지: 아래 수치는 2025-2026년 Percona, EDB(EnterpriseDB) 등 주요 기관의 공개 벤치마크와 학술 논문을 종합한 것이다. 실제 환경(하드웨어, 설정, 쿼리 패턴)에 따라 결과는 크게 달라진다.

2-1. OLTP (트랜잭션 처리)

표준 OLTP 환경(16코어, 64GB RAM, NVMe SSD) 기준으로 PostgreSQL 17의 혼합 읽기/쓰기 처리량은 초당 15,000-25,000 트랜잭션을 기록했다.

멀티 도큐먼트 트랜잭션이 포함된 시나리오에서 MongoDB는 트랜잭션 레이어가 나중에 추가된 아키텍처 특성상 PostgreSQL 대비 오버헤드가 더 발생한다. 특히 고동시성(256 스레드 이상) 환경에서 MongoDB의 p99 레이턴시는 250ms를 초과한 반면, PostgreSQL은 10ms 미만을 유지하는 경향이 나타났다.

동시 트랜잭션 레이턴시 비교 (64 concurrent threads):

2026년 2월 출판된 이커머스 환경 비교 논문에 따르면, 동일 데이터셋으로 PostgreSQL이 복잡한 분석 쿼리를 1.6-15.1배 빠르게 처리했으며, 다중 기준 필터 쿼리에서는 실행 시간이 65-80% 더 짧았다.

2-2. 복잡한 분석 쿼리 (OLAP)

PostgreSQL의 독보적 영역이다. 멀티 테이블 조인, 윈도우 함수, CTE(Common Table Expression) 등 SQL의 강력한 분석 기능은 MongoDB의 집계 파이프라인이 쉽게 따라오기 어렵다.

-- PostgreSQL: 국가별 월간 매출 + 3개월 이동 평균
SELECT
    u.country,
    DATE_TRUNC('month', o.created_at)    AS month,
    COUNT(*)                              AS order_count,
    SUM(o.total)                          AS revenue,
    AVG(SUM(o.total)) OVER (
        PARTITION BY u.country
        ORDER BY DATE_TRUNC('month', o.created_at)
        ROWS BETWEEN 2 PRECEDING AND CURRENT ROW
    )                                     AS rolling_3m_avg
FROM orders o
JOIN users u ON o.user_id = u.id
WHERE o.status = 'completed'
GROUP BY u.country, DATE_TRUNC('month', o.created_at);

// MongoDB: 동일 쿼리를 집계 파이프라인으로 구현 (훨씬 장황해짐)
db.orders.aggregate([
  { $match: { status: 'completed' } },
  { $lookup: {
      from: 'users', localField: 'user_id',
      foreignField: '_id', as: 'user'
  }},
  { $unwind: '$user' },
  { $group: {
      _id: {
        country: '$user.country',
        month: { $dateToString: { format: '%Y-%m', date: '$created_at' } }
      },
      order_count: { $sum: 1 },
      revenue:     { $sum: '$total' }
  }},
  // 이동 평균은 $setWindowFields 추가 구현 필요 (MongoDB 5.0+)
  { $setWindowFields: {
      partitionBy: '$_id.country',
      sortBy: { '_id.month': 1 },
      output: {
        rolling_3m_avg: {
          $avg: '$revenue',
          window: { documents: [-2, 'current'] }
        }
      }
  }}
]);

2-3. 쓰기 집약적 워크로드

반대로 MongoDB가 우세한 영역이 있다. 단순 도큐먼트 삽입, IoT 텔레메트리, 클릭스트림 같은 쓰기 집약적 워크로드에서는 MongoDB가 PostgreSQL보다 유리하다.

MongoDB 8.0은 이전 버전 대비 벌크 쓰기 성능 +54%, 읽기 +36%, 업데이트 처리량 +59%를 달성했다. 스키마가 자주 바뀌는 이벤트 스트리밍, 동적 상품 카탈로그, 사용자 행동 로그 등은 MongoDB의 강점이 가장 잘 발휘되는 영역이다.

2-4. 벤치마크 해석 시 주의점

3. 확장성: 수직 vs 수평

3-1. PostgreSQL의 확장 전략

PostgreSQL은 태생적으로 수직 확장(Scale Up)이 기본 전략이다. 더 강력한 서버(CPU, RAM, 스토리지)를 투입하는 방식이다. 이 방법은 단순하고 트랜잭션 일관성을 유지하기 쉽지만, 하드웨어 한계에 부딪히면 대안이 필요하다.

PostgreSQL의 수평 확장 옵션:

Read Replica    — 읽기 분산 (쓰기는 여전히 Primary)
Partitioning    — 단일 노드 내 테이블 파티셔닝
Citus Extension — 분산 PostgreSQL (수평 확장)
클라우드 관리형 — Supabase, Neon, AWS Aurora PostgreSQL

2026년 관점에서 Supabase와 Neon 같은 클라우드 서비스가 PostgreSQL을 MongoDB Atlas 수준으로 운영을 단순화시켰다. "MongoDB는 관리하기 쉽고 PostgreSQL은 어렵다"는 편견은 이제 많이 사라졌다.

3-2. MongoDB의 확장 전략

MongoDB는 처음부터 수평 확장(Scale Out)을 네이티브로 지원하도록 설계됐다. 샤딩(Sharding)을 통해 데이터를 여러 노드에 자동으로 분산한다.

샤딩 키(Shard Key) 설계가 핵심이다. 잘못 고르면 특정 샤드에 트래픽이 집중되는 핫스팟 현상이 발생한다.

// 복합 샤딩 키 설정 예시
sh.shardCollection(
  "iot.sensorData",
  { deviceId: 1, timestamp: 1 }
  // deviceId만 쓰면 디바이스 수가 적을 때 핫스팟 위험
  // timestamp만 쓰면 최신 데이터가 한 샤드에 집중되는 단조 증가 문제
);

확장성 비교:

4. 2026년 AI 시대의 벡터 검색 경쟁

2026년 데이터베이스 선택에서 빼놓을 수 없는 새로운 변수가 등장했다. 바로 AI 워크로드와 벡터 검색이다.

두 데이터베이스 모두 벡터 검색을 내장하기 시작했고, 이제 "AI 앱에는 전용 벡터 DB가 필요하다"는 공식도 흔들리고 있다.

PostgreSQL + pgvector

-- pgvector: 관계형 필터 + 시맨틱 검색 동시 적용
CREATE EXTENSION vector;

CREATE TABLE products (
    id        SERIAL PRIMARY KEY,
    name      TEXT,
    price     NUMERIC,
    category  TEXT,
    embedding VECTOR(1536)  -- OpenAI text-embedding-3-small 차원
);

SELECT name, price,
       1 - (embedding <=> '[0.1, 0.2, ...]'::vector) AS similarity
FROM products
WHERE price < 100000
  AND category = '전자제품'
ORDER BY embedding <=> '[0.1, 0.2, ...]'::vector
LIMIT 10;

pgvector 0.8(2025년 9월 출시)은 ANN(Approximate Nearest Neighbor) 검색 정확도를 크게 개선했다. pgvectorscale 확장은 50M 벡터 기준 471 QPS를 기록하며 일부 전용 벡터 DB와 견줄 수준으로 성장했다 — 단, 이 수치는 특정 구성 환경에서의 벤치마크 클레임이며 보편적 보장은 아니다.

MongoDB Atlas Vector Search

// MongoDB Atlas Vector Search: 메타데이터 필터 + 벡터 검색
db.products.aggregate([
  {
    $vectorSearch: {
      index:         "product_embedding_index",
      path:          "embedding",
      queryVector:   [0.1, 0.2],
      numCandidates: 100,
      limit:         10,
      filter: {
        price:    { $lt: 100000 },
        category: "전자제품"
      }
    }
  }
]);

MongoDB Atlas Vector Search는 MongoDB 8.0에서 대폭 강화됐다. 비정형 텍스트 콘텐츠 위주의 RAG(Retrieval-Augmented Generation) 파이프라인에서 도큐먼트 모델이 자연스럽게 어울린다는 평가를 받는다.

AI 벡터 검색 선택 기준:

5. 라이선스와 비용: 간과하면 안 되는 현실

기술 비교 못지않게 중요한 것이 라이선스다.

SSPL 주의사항: MongoDB의 SSPL은 일반적인 내부 사용에는 문제가 없다. 다만 MongoDB 기능을 클라우드 서비스로 외부에 제공(SaaS화)할 경우 소스 코드 공개 의무가 생길 수 있다. AWS, Google, Azure 같은 클라우드 사업자들이 MongoDB 호환 서비스 제공 시 갈등을 빚었던 이유다.

PostgreSQL은 이런 제약이 전혀 없다. 누구나 PostgreSQL을 기반으로 상용 서비스를 만들 수 있다.

6. 실전 사용 사례: 누가 무엇을 쓰는가

PostgreSQL을 선택한 사례

MongoDB를 선택한 사례

주목할 패턴: 폴리글랏(Polyglot) 퍼시스턴스

대형 서비스는 단일 DB를 쓰지 않는다.

핵심 트랜잭션 (주문, 결제, 재고)      → PostgreSQL
동적 콘텐츠, 카탈로그, 사용자 프로필  → MongoDB
캐싱, 세션                            → Redis
검색                                  → Elasticsearch 또는 pgvector / Atlas Search
AI 임베딩                             → pgvector 또는 Atlas Vector Search

2026년 흥미로운 흐름 중 하나는 단일화 전략이다. 일부 대형 클라우드 기업들이 PostgreSQL 기반 기업들을 인수하면서 "그냥 PostgreSQL만 써라"는 움직임도 커지고 있다. 벡터 검색, 큐, 전문 검색까지 PostgreSQL 확장으로 처리하여 운영 복잡도를 줄이는 접근이다.

7. 최종 선택 가이드: 내 상황에 맞는 DB는?

7-1. 트랜잭션 관점 요약 비교

4개 파트를 통해 다룬 트랜잭션 관련 핵심 차이를 한 곳에 모았다.

7-2. 시나리오별 선택 기준

PostgreSQL을 선택해야 할 때:

금융, 핀테크, 회계      — 최강 수준의 ACID와 감사 추적이 필수
복잡한 조인과 집계 쿼리 — 분석 시스템, BI, 리포팅
엄격한 스키마 필요      — ERP, CRM, 규제 산업 (의료, 금융)
SQL 숙련 팀             — 장기 유지보수를 고려한 프로젝트
SaaS 백엔드             — Supabase, Neon 등 관리형 서비스로 운영 간소화
AI 앱                   — 관계형 데이터 + 벡터 검색 동시 필요 (pgvector)

MongoDB를 선택해야 할 때:

스키마가 자주 바뀌는 초기 스타트업 — 빠른 프로토타이핑
IoT 텔레메트리                      — 디바이스마다 페이로드 구조가 다른 데이터
콘텐츠 관리 시스템                  — 각 문서가 다른 속성을 갖는 경우
실시간 이벤트 스트리밍              — 쓰기가 압도적으로 많은 워크로드
글로벌 분산 서비스                  — 네이티브 샤딩으로 지역별 수평 확장 필요
JS/TS 팀                            — BSON 도큐먼트 모델이 코드와 자연스럽게 매핑
RAG 파이프라인                      — 비정형 콘텐츠 위주의 AI 서비스

두 DB를 함께 고려해야 할 때:

마이크로서비스 — 서비스별로 데이터 특성이 근본적으로 다른 경우
플랫폼 서비스  — 핵심 트랜잭션(PostgreSQL) + 유연한 카탈로그·리뷰(MongoDB)

7-3. 판단 플로우차트

8. 시리즈 최종 정리

4개 파트에 걸쳐 긴 여정을 마무리한다. 핵심만 추려보자.

트랜잭션 철학의 차이

PostgreSQL = "모든 데이터 작업은 트랜잭션이다"
              ACID가 기본값, 개발자가 신경 쓰지 않아도 보장됨

MongoDB    = "잘 설계된 도큐먼트 하나면 트랜잭션이 필요 없다"
              트랜잭션은 필요할 때 명시적으로 사용하는 도구

선택의 핵심 원칙

1. 정합성 vs 유연성: 데이터 정합성이 최우선이면 PostgreSQL. 스키마 유연성이 최우선이면 MongoDB.
2. 쿼리 복잡도: 복잡한 조인과 분석이 많으면 PostgreSQL. 단순 도큐먼트 조회/쓰기가 많으면 MongoDB.
3. 확장 방향: 수직 확장 + SQL 생태계면 PostgreSQL. 글로벌 수평 확장이 필수면 MongoDB.
4. 팀 역량: SQL 숙련 팀은 PostgreSQL. NoSQL/JS 팀은 MongoDB.
5. 미신을 버려라: "MongoDB는 트랜잭션이 없다", "PostgreSQL은 확장이 안 된다" — 둘 다 2018년 이전의 이야기다.

2026년의 최종 결론

두 데이터베이스 모두 성숙했고, 상대방의 강점을 흡수하고 있다. "어느 쪽이 더 좋은가"라는 질문보다 "내 워크로드와 팀에 무엇이 맞는가"를 물어야 한다. 그리고 대부분의 일반적인 웹/앱 서비스에서는 PostgreSQL이 더 안전한 기본 선택이다. MongoDB가 진가를 발휘하는 곳은 스키마가 유동적이고 쓰기가 폭발적이며 수평 확장이 필수인 명확한 상황이다.

시리즈 전체 요약

참고 자료

• tech-insider.org: MongoDB vs PostgreSQL 2026 (April 2026)
• Airbyte: MongoDB vs. PostgreSQL (2025)
• MDPI Big Data & Cognitive Computing: PostgreSQL vs MongoDB E-Commerce Benchmark (Feb 2026)
• leanware.co: MongoDB vs PostgreSQL (Mar 2026)
• knowi.com: MongoDB vs PostgreSQL Updated 2026
• DEV.to: What's Changing in Vector Databases in 2026
• singhajit.com: When to Use PostgreSQL vs MongoDB vs DynamoDB (Mar 2026)
• EnterpriseDB: Performance Comparison MongoDB vs PostgreSQL