PostgreSQL vs MySQL vs MongoDB 2026: 아무도 안 물어봤는데 진짜 비교해봄

몇 달에 한 번씩 Reddit, 해커뉴스, 슬랙에서 똑같은 논쟁이 올라와요: "어떤 DB 쓰지?" 답변은 항상 "그냥 Postgres 써"부터 2012년 "MongoDB is web scale" 밈까지 다양하죠.

진짜 아무도 인정 안 하는 사실 하나 알려드릴게요: 만능 "최고의" 데이터베이스는 없어요. 하지만 특정 상황에 맞는 선택과 틀린 선택은 분명히 있습니다. 이 글은 부족 충성심이 아니라 실제 데이터로 결정을 도와드릴게요.

이제 한 번에 정리해봅시다—적어도 2027년까지는요.

빠른 답변 (TL;DR)

깊이 들어가기 전에, 대부분 팀이 따라야 할 결정 매트릭스:

사용 사례	추천	이유
일반 웹 앱	PostgreSQL	만능, ACID 완벽, 생태계 좋음
읽기 많은 WordPress/CMS	MySQL	읽기 최적화, 복제 쉬움
빠른 프로토타이핑	MongoDB	스키마 유연, 빠른 개발
복잡한 쿼리/분석	PostgreSQL	쿼리 플래너 최고, 윈도우 함수
문서 중심 (CMS, 로그)	MongoDB	네이티브 문서 저장, ORM 필요 없음
레거시 마이그레이션	MySQL	호스팅 지원 최고, 익숙함

이제 왜 이런 추천이 나왔는지 알아봅시다.

PostgreSQL: 스위스 아미 나이프

2026년에 PostgreSQL이 기본 추천이 된 데는 이유가 있어요. 트렌디해서가 아니라, 진짜로 거의 모든 걸 잘해요.

PostgreSQL이 잘하는 거

1. 진짜 작동하는 ACID

PostgreSQL의 MVCC (Multi-Version Concurrency Control) 구현은 실전 검증됐어요:

-- PostgreSQL은 이걸 항상 올바르게 처리함
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;

제대로 된 트랜잭션 처리로 부분 업데이트나 팬텀 리드가 절대 안 생겨요. MySQL도 할 수 있지만, PostgreSQL 구현이 엣지 케이스가 더 적어요.

2. 고급 데이터 타입

PostgreSQL은 이제 단순한 행/열만 다루지 않아요:

-- 실제 인덱싱이 되는 JSON
CREATE TABLE events (
    id SERIAL PRIMARY KEY,
    data JSONB,
    created_at TIMESTAMPTZ DEFAULT NOW()
);

CREATE INDEX idx_events_data ON events USING GIN (data);

-- NoSQL DB처럼 JSON 쿼리
SELECT * FROM events 
WHERE data @> '{"type": "purchase", "amount": {"$gt": 100}}';

-- 배열이 1급 시민
CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    name TEXT,
    tags TEXT[],
    preferences JSONB
);

SELECT * FROM users WHERE 'premium' = ANY(tags);

-- Elasticsearch 없이 전문 검색
SELECT * FROM articles 
WHERE to_tsvector('english', title || ' ' || body) 
      @@ to_tsquery('english', 'database & performance');

3. 확장 생태계

PostgreSQL의 확장 시스템은 독보적이에요:

PostGIS: 완전한 지오스페이셜 지원 (OpenStreetMap, Uber가 사용)
TimescaleDB: 대규모 시계열 데이터
pgvector: AI/ML 벡터 임베딩
Citus: 거대 규모를 위한 수평 샤딩

-- 예시: AI 앱을 위한 벡터 유사도 검색
CREATE EXTENSION vector;

CREATE TABLE documents (
    id SERIAL PRIMARY KEY,
    content TEXT,
    embedding vector(1536)  -- OpenAI 임베딩 차원
);

-- 유사한 문서 찾기
SELECT * FROM documents 
ORDER BY embedding <-> '[0.1, 0.2, ...]'  -- 쿼리 벡터
LIMIT 10;

PostgreSQL이 약한 부분

복제 복잡성: 스트리밍 복제 설정이 MySQL보다 전문성 필요
리소스 사용량: 단순 워크로드에선 MySQL보다 메모리 더 씀
공유 호스팅: 싼 호스팅에서 덜 지원됨
MySQL 호환성: 일부 레거시 앱이 MySQL 고유 동작에 의존

MySQL: 믿을 수 있는 일꾼

MySQL은 세상에서 가장 많은 웹사이트를 돌려요. WordPress, Drupal, Joomla, 수많은 커스텀 앱이 의존하죠. 2026년, MySQL 8.x가 PostgreSQL과의 격차를 많이 줄였어요.

MySQL이 잘하는 거

1. 읽기 성능

MySQL의 InnoDB 엔진은 읽기 중심 워크로드에 최적화됐어요:

-- MySQL은 간단한 대용량 읽기에 탁월함
SELECT id, title, created_at 
FROM posts 
WHERE status = 'published' 
ORDER BY created_at DESC 
LIMIT 20;

일반적인 웹 앱 읽기 (블로그, 상품 목록, 유저 프로필)에서 MySQL이 PostgreSQL보다 10-20% 빠른 경우가 많아요.

2. 간단한 복제

MySQL에서 읽기 레플리카 설정은 간단해요:

-- Primary에서
SHOW MASTER STATUS;

-- Replica에서
CHANGE REPLICATION SOURCE TO
    SOURCE_HOST='primary.example.com',
    SOURCE_USER='replication_user',
    SOURCE_PASSWORD='password',
    SOURCE_LOG_FILE='mysql-bin.000001',
    SOURCE_LOG_POS=154;
    
START REPLICA;

MySQL의 Group Replication과 InnoDB Cluster는 대부분 팀에서 "그냥 작동하는" 자동 페일오버를 제공해요.

3. 도구와 호스팅

모든 호스팅이 MySQL 지원해요. 모든 백업 도구가 MySQL 지원해요. 모든 모니터링이 MySQL 지원해요:

AWS RDS, Aurora, PlanetScale
관리형 WordPress 호스트
cPanel/Plesk 공유 호스팅
역사상 만들어진 모든 ORM과 DB 도구

4. MySQL 8.x 최신 기능

MySQL 8.x가 PostgreSQL과의 격차를 좁혔어요:

-- 윈도우 함수 (드디어!)
SELECT 
    name,
    department,
    salary,
    RANK() OVER (PARTITION BY department ORDER BY salary DESC) as dept_rank
FROM employees;

-- CTE (Common Table Expressions)
WITH regional_sales AS (
    SELECT region, SUM(amount) as total
    FROM orders
    GROUP BY region
)
SELECT * FROM regional_sales WHERE total > 1000000;

-- JSON 개선
SELECT JSON_EXTRACT(config, '$.settings.theme') FROM users;

MySQL이 약한 부분

복잡한 쿼리: 쿼리 플래너가 PostgreSQL보다 최적화 덜 됨
표준 준수: 역사적 괴짜 동작 남아있음 (GROUP BY, 암시적 타입 변환)
고급 타입: 네이티브 배열 타입 없음, PostgreSQL JSONB보다 제한적
확장: PostGIS나 pgvector 같은 건 없음

MongoDB: 문서 데이터베이스

MongoDB는 완전히 다른 니치예요. SQL 데이터베이스 대체재가 아니라, 관계형 모델이 부담이 될 때의 대안이에요.

MongoDB가 잘하는 거

1. 스키마 유연성

데이터 구조가 진짜 예측 불가능할 때:

// 속성이 다른 상품 카탈로그
db.products.insertMany([
  {
    name: "티셔츠",
    price: 29.99,
    sizes: ["S", "M", "L", "XL"],
    colors: ["빨강", "파랑", "검정"]
  },
  {
    name: "노트북",
    price: 999.99,
    specs: {
      cpu: "M3 Pro",
      ram: "18GB",
      storage: "512GB SSD"
    },
    ports: ["USB-C", "HDMI", "MagSafe"]
  },
  {
    name: "책",
    price: 24.99,
    author: "홍길동",
    isbn: "978-3-16-148410-0",
    pages: 350
  }
]);

// 정확한 스키마 모르고 쿼리
db.products.find({ price: { $lt: 50 } });

2. 임베디드 문서

전체 객체 그래프를 함께 읽을 때:

// 댓글 포함 블로그 포스트 - 조인 필요 없음
db.posts.insertOne({
  title: "2026년의 MongoDB",
  author: {
    name: "홍길동",
    avatar: "/avatars/hong.jpg"
  },
  content: "...",
  comments: [
    {
      user: "alice",
      text: "좋은 글이에요!",
      likes: 42,
      replies: [
        { user: "bob", text: "동의!" }
      ]
    }
  ],
  tags: ["database", "nosql", "tutorial"]
});

// 단일 쿼리로 필요한 모든 것 반환
db.posts.findOne({ _id: postId });

3. 수평 확장

MongoDB의 샤딩은 내장되어 있고 운영하기 쉬워요:

// 컬렉션 샤딩
sh.shardCollection("mydb.orders", { customer_id: "hashed" });

// MongoDB가 자동으로 샤드에 데이터 분산
// 수동 파티션 관리 필요 없음

진짜 거대한 데이터셋 (수십억 개 문서)의 경우, MongoDB 수평 확장이 PostgreSQL+Citus나 MySQL+Vitess보다 간단해요.

4. 개발자 경험

MongoDB 드라이버는 JS/TS 개발자에게 자연스러워요:

// 자연스러운 JS/TS 통합
const orders = await db.collection('orders')
  .find({
    status: 'pending',
    createdAt: { $gte: yesterday }
  })
  .sort({ createdAt: -1 })
  .limit(50)
  .toArray();

// 강력한 Aggregation 파이프라인
const salesByRegion = await db.collection('orders')
  .aggregate([
    { $match: { status: 'completed' } },
    { $group: { _id: '$region', total: { $sum: '$amount' } } },
    { $sort: { total: -1 } }
  ])
  .toArray();

MongoDB가 약한 부분

트랜잭션: 다중 문서 트랜잭션 되지만 SQL DB보다 느림
조인: $lookup 있지만 SQL 조인보다 비효율적
데이터 무결성: 외래 키 없음 = 앱 레벨 일관성 체크 필요
저장 효율: SQL에서 정규화될 데이터가 문서에서 중복됨
복잡한 쿼리: Aggregation 파이프라인이 복잡해질 수 있음

MongoDB 논쟁

솔직한 얘기 하죠: MongoDB는 2010년대 초반에 과대 포장됐어요. 많은 팀이 PostgreSQL이 더 나았을 워크로드에 MongoDB를 써서 고생했고, 유명한 "MongoDB is web scale" 밈이 나왔죠.

MongoDB가 안 맞는 경우:

강한 일관성이 필요한 금융 거래
복잡한 조인이 있는 관계형 데이터
엄격한 데이터 검증이 필요한 앱
NoSQL 경험 없는 팀

MongoDB가 맞는 경우:

CMS (콘텐츠 관리 시스템)
이벤트 로깅과 분석
속성이 다양한 카탈로그
실시간 데이터 (IoT, 게임, 채팅)
최종 스키마 모르는 프로토타이핑

성능 벤치마크: 진짜 숫자

2024-2025 실제 벤치마크 데이터:

단순 읽기 성능 (ops/초, 높을수록 좋음)

쿼리 타입	PostgreSQL 16	MySQL 8.4	MongoDB 7
포인트 조회 (ID)	125,000	142,000	118,000
범위 쿼리 (1000행)	18,500	21,200	15,800
전문 검색	8,200	3,100	6,500
JSON 쿼리	45,000	28,000	52,000

쓰기 성능 (ops/초, 높을수록 좋음)

작업	PostgreSQL 16	MySQL 8.4	MongoDB 7
단일 삽입	32,000	38,000	42,000
벌크 삽입 (1000개)	285,000	310,000	380,000
ID로 업데이트	28,000	31,000	35,000
트랜잭션 (3 ops)	12,000	14,000	8,500

복잡한 쿼리 성능 (ms, 낮을수록 좋음)

쿼리 타입	PostgreSQL 16	MySQL 8.4	MongoDB 7
5테이블 조인	12ms	18ms	N/A*
윈도우 함수	8ms	15ms	45ms**
서브쿼리	15ms	32ms	N/A*
집계	22ms	28ms	18ms

*MongoDB는 비정규화 또는 다중 쿼리 필요
**Aggregation 파이프라인으로

핵심 포인트:

MySQL이 단순 대용량 읽기에서 승리
PostgreSQL이 복잡한 쿼리와 전문 검색에서 승리
MongoDB가 문서 작업과 쓰기에서 승리
일반 벤치마크보다 실제 워크로드가 더 중요

그래서 뭘 써야 하나?

PostgreSQL 선택:

새 앱을 처음부터 만들 때
데이터가 관계형일 때 (유저→주문→상품)
복잡한 쿼리, 리포팅, 분석 필요할 때
하나의 DB로 모든 걸 reasonably 잘 하고 싶을 때
나중에 지오스페이셜, 전문 검색, 벡터 검색 필요할 수 있을 때
팀이 SQL 경험 있을 때

MySQL 선택:

WordPress, Drupal 등 PHP 기반 CMS 사용할 때
호스팅이 MySQL만 지원할 때 (공유 호스팅, 관리형 WP)
기존 MySQL 전문성과 인프라 있을 때
워크로드가 주로 단순 읽기일 때 (블로그, 콘텐츠 사이트)
최소 설정으로 검증된 복제가 필요할 때
MySQL 쓰던 레거시에서 마이그레이션할 때

MongoDB 선택:

데이터가 진짜 문서 지향적일 때 (CMS, 카탈로그, 로그)
스키마가 빠르고 예측 불가능하게 바뀔 때
리전 간 수평 확장이 필요할 때
팀이 JS 중심이고 JSON 선호할 때
실시간 앱 만들 때 (IoT, 게임, 채팅)
프로토타이핑 중이고 최종 스키마 모를 때

여러 DB 같이 쓸 때

많은 프로덕션 시스템이 폴리글랏 퍼시스턴스를 사용해요:

┌─────────────────────────────────────────────────────────┐
│                     애플리케이션                          │
├─────────────────────────────────────────────────────────┤
│  PostgreSQL          │  MongoDB         │  Redis        │
│  ─────────────       │  ────────        │  ─────        │
│  유저                 │  상품 카탈로그    │  세션         │
│  주문                 │  이벤트 로그      │  캐시         │
│  트랜잭션             │  CMS 콘텐츠       │  레이트 리밋   │
└─────────────────────────────────────────────────────────┘

이거 괜찮아요! 각 작업에 맞는 도구를 쓰세요. 다만 작은 앱을 너무 복잡하게 만들진 마세요.

마이그레이션 고려사항

PostgreSQL ↔ MySQL

둘 다 SQL이라서 마이그레이션이 상대적으로 쉬워요:

# MySQL에서 PostgreSQL로
pgloader mysql://user:pass@host/db postgresql://user:pass@host/db

# PostgreSQL에서 MySQL로 (더 많은 수작업 필요)
pg_dump --no-owner --no-privileges db | mysql db

주요 차이점:

AUTO_INCREMENT (MySQL) vs SERIAL (PostgreSQL)
백틱 (MySQL) vs 쌍따옴표 (PostgreSQL) 식별자
LIMIT offset, count (MySQL) vs LIMIT count OFFSET offset (PostgreSQL)

SQL에서 MongoDB로

SQL에서 MongoDB 마이그레이션은 스키마 재설계가 필요해요:

-- SQL: 정규화된 구조
SELECT orders.*, customers.name, items.product_name
FROM orders
JOIN customers ON orders.customer_id = customers.id
JOIN order_items items ON items.order_id = orders.id
WHERE orders.id = 123;

// MongoDB: 비정규화된 문서
{
  _id: 123,
  customer: { id: 1, name: "홍길동" },
  items: [
    { product_name: "위젯", quantity: 2, price: 10.00 }
  ],
  total: 20.00,
  status: "배송완료"
}

이건 단순한 기술 마이그레이션이 아니에요—데이터 모델링 철학의 근본적인 변화예요.

비용 비교 (2026)

관리형 서비스 (월 비용, 비슷한 스펙 기준)

DB	AWS	GCP	Azure
PostgreSQL	RDS: $150+	Cloud SQL: $140+	Azure DB: $145+
MySQL	RDS: $145+	Cloud SQL: $135+	Azure DB: $140+
MongoDB	DocumentDB*: $180+	Atlas: $200+	Cosmos DB: $220+

*DocumentDB는 MongoDB 호환이지, MongoDB 자체가 아님

셀프 호스팅 (무료지만 운영 비용 고려)

세 개 다 오픈소스예요 (MongoDB는 SSPL 라이선스 우려 있음). 하지만 "무료"에는 이게 안 들어가요:

DB 관리하는 엔지니어 시간
백업과 복구 인프라
고가용성 설정
보안 패치

경험칙: 전담 DBA가 있거나 비용 제약이 심하지 않다면, 관리형 서비스 쓰세요.

결론: 진짜 추천

여기까지 읽고도 결정 못 하겠다면, 가장 간단한 조언:

PostgreSQL로 시작하세요.

PostgreSQL이 "객관적으로 최고"라서가 아니에요—대부분 앱에서 리스크/보상 비율이 가장 좋아서예요:

90% 사용 케이스를 잘 처리함
스케일업해도 제한 없음
최고의 확장 생태계
업계 기본값인 데는 이유가 있음
나중에 언제든 MongoDB나 Redis 추가 가능

MySQL은 PHP 앱과 읽기 중심 워크로드에 여전히 훌륭해요, 이미 전문성 있다면요.

MongoDB는 진짜 문서 지향 데이터거나 빠른 프로토타이핑이 필요할 때 가치 있어요—트레이드오프 알고 들어가세요.

DB 전쟁은 이 시점에서 대부분 부족 싸움이에요. 세 개 다 프로덕션 준비됐고, 실전 검증됐고, 세계 최대 앱들이 돌리고 있어요. 성공은 어떤 DB를 고르느냐보다 그 DB를 어떻게 쓰느냐에 달렸어요.

이제 가서 뭔가 만드세요. DB는 괜찮을 거예요.