PostgreSQL vs MySQL: 2026년 프로덕션 의사결정 프레임워크

발행: 3일 전 (2026년 2월 21일 오후 01:14 GMT+9)

11 분 소요

Source: Dev.to

죄송합니다만, 번역하려는 본문 내용이 제공되지 않았습니다. 번역이 필요한 텍스트를 그대로 복사해서 알려주시면, 요청하신 대로 한국어로 번역해 드리겠습니다.

빠른 결정 매트릭스

상황	권장 기본값	이유
클래식 OLTP(주문, 사용자, 구독) – 중간 수준 동시성, 가벼운 JSON 사용	Either PostgreSQL 또는 MySQL	두 데이터베이스 모두 작동합니다; 팀의 친숙도, 관리형 서비스 성숙도, 생태계를 기준으로 선택하세요.
JSON이 쿼리 API의 일부인 경우(필터링, 포함, 동적 속성)	PostgreSQL	`jsonb`와 GIN 인덱스를 사용하면 스키마를 많이 바꾸지 않고도 유연하고 즉석에서 쿼리할 수 있습니다.
멀티 테넌트 격리를 위한 행 수준 보안(RLS)이 필요할 때	PostgreSQL	일류 수준의 RLS 기본 기능을 제공합니다.
단순 키 조회/작은 범위 스캔으로 매우 높은 읽기 확장이 필요하고, 가장 표준적인 복제 방식을 원할 때	MySQL	검증된 간단한 비동기/반동기 복제.
쓰기 부하가 핫스팟 중심일 때	Either (정확한 패턴을 테스트하세요)	두 데이터베이스 모두 처리 가능하지만 벤치마크가 필요합니다.
“SQL + 특이한 쿼리”(전체 텍스트 검색, 사용자 정의 연산자, 부분 인덱스, 고급 제약조건)	PostgreSQL	풍부한 확장 생태계.

Source: …

JSON 저장 및 인덱싱

두 데이터베이스 모두 JSON을 저장하지만, 실제 차이점은 인덱싱 유연성 및 새로운 필터가 추가될 때 재설계가 얼마나 자주 필요하냐에 있습니다.

PostgreSQL (유연하고 쿼리‑중심 JSON)

CREATE TABLE events (
  id         bigserial PRIMARY KEY,
  tenant_id  bigint NOT NULL,
  created_at timestamptz NOT NULL DEFAULT now(),
  type       text NOT NULL,
  attrs      jsonb NOT NULL
);

-- GIN index for generic JSON queries
CREATE INDEX events_attrs_gin
  ON events USING gin (attrs);

-- Composite index for tenant‑scoped ordering
CREATE INDEX events_tenant_created_at
  ON events (tenant_id, created_at DESC);

주의할 점

GIN 인덱스 크기 및 업데이트 비용 – 읽기/쿼리 유연성은 뛰어나지만, 쓰기‑중심 워크로드에서는 비용이 발생합니다.
연산자 선택이 중요 (@>, ->, ->>, ?| 등). 인덱스를 활용하려면 일관된 쿼리 패턴이 필요합니다.

MySQL (페이로드로서의 JSON, 제한된 인덱스 경로)

CREATE TABLE events (
  id         bigint unsigned NOT NULL AUTO_INCREMENT,
  tenant_id  bigint NOT NULL,
  created_at timestamp(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6),
  type       varchar(64) NOT NULL,
  attrs      json NOT NULL,
  status     varchar(32)
    GENERATED ALWAYS AS (JSON_UNQUOTE(JSON_EXTRACT(attrs, '$.status'))) STORED,
  PRIMARY KEY (id),
  KEY events_tenant_created_at (tenant_id, created_at),
  KEY events_status (status)
) ENGINE=InnoDB;

트레이드‑오프
새로운 필터 예시(attrs.customer.segment)가 생기면, 일반 JSON 인덱스에 의존하는 대신 생성된 컬럼 + 인덱스를 추가해야 합니다.

어떤 접근 방식을 선택할지

사용 사례	PostgreSQL	MySQL
JSON이 쿼리의 핵심 영역(고객이 필터/정렬에 사용, 임시 쿼리, 주간 스키마 변화)	✅	❌
JSON이 단순히 페이로드 저장이며 인덱싱이 필요한 3‑10개의 경로만 명시 가능	❌	✅

동시성 및 MVCC 함정

Feature	PostgreSQL	MySQL (InnoDB)
MVCC 구현	읽는 작업은 쓰는 작업을 차단하지 않으며, 높은 변경률에서 죽은 튜플이 축적됩니다.	MVCC도 마찬가지지만 next‑key와 gap lock이 차단을 일으킬 수 있습니다.
일반적인 함정	• 장시간 실행 트랜잭션이 vacuum을 방해하여 테이블 팽창을 초래합니다. • 업데이트가 빈번한 테이블은 테이블별 `autovacuum`을 조정해야 합니다.	• 적절한 인덱스 없이 업데이트하면 많은 행이 잠길 수 있습니다. • 모든 보조 인덱스는 쓰기 오버헤드를 증가시킵니다.
온라인 DDL	`CREATE INDEX CONCURRENTLY`는 쓰기 차단을 피하지만 느리고 실패할 수 있습니다.	최신 MySQL은 online DDL을 지원하지만, 대규모 인덱스 생성은 여전히 부하와 복제 지연을 발생시킵니다.

동시성 리트머스 테스트 (skip‑locked 작업 큐)

PostgreSQL (첫 번째 클래스 SKIP LOCKED)

WITH next_job AS (
  SELECT id
  FROM jobs
  WHERE run_at  '{"status":"failed"}'
  ORDER BY created_at DESC
  LIMIT 50
)
SELECT * FROM next_job;

확인 포인트: (tenant_id, created_at)에 대한 인덱스 스캔, 워밍업 후 낮은 shared‑read buffer, 예상치 못한 순차 스캔 없음.

MySQL 예시 (생성 컬럼 필터)

EXPLAIN ANALYZE
SELECT id
FROM events
WHERE tenant_id = 42 AND status = 'failed'
ORDER BY created_at DESC
LIMIT 50;

확인 포인트: 선택된 키가 복합 인덱스와 일치하는지, 검사된 행 수 ≈ 반환된 행 수.

팁: 모든 쿼리가 테넌트 범위라면 인덱스를 테넌트 접두사로 만들세요. 이것이 “인덱스를 만들었는데도 지연 시간이 여전히 높다”는 가장 흔한 실수입니다.

백업, 복구 및 시점 복구 (PITR)

항목	PostgreSQL	MySQL
PITR 메커니즘	Base backups + WAL archiving	Full backups + binary logs
관리형 제공 권장 사항	복원을 자동화하고 현실적인 데이터셋 크기에서 복원 시간을 측정할 수 있는 공급자를 선택하세요.	동일 – 정기적으로 복원을 테스트하세요.
쓰기를 차단하지 않는 인덱스 생성	`CREATE INDEX CONCURRENTLY`	Online DDL (예: `ALTER TABLE … ADD INDEX … ALGORITHM=INPLACE, LOCK=NONE`)

운영 건강 체크리스트

Autovacuum: dead‑tuple 수, 팽창 지표, 그리고 테이블별 설정을 모니터링합니다.
Transaction age: vacuum을 차단하는 장기 실행 트랜잭션을 감시합니다.
WAL volume: 배포 또는 백필 후 급증하는 WAL 양은 저장소에 부담을 줄 수 있습니다.
Lock waits: 차단된 DDL이나 핫 테이블 경쟁을 감시합니다.
Replica lag: 특히 대규모 인덱스 구축이나 대량 로드 후 복제 지연을 확인합니다.

핵심 요약

Score your workload 를 두 엔진에 대해 평가합니다.
Prototype 을 사용해 중요한 쿼리(JSON 경로 포함)를 양쪽에서 시도해 봅니다.
EXPLAIN ANALYZE 와 실제 부하를 이용해 Measure 합니다.
복구 테스트, autovacuum/innodb‑flush 튜닝을 지원하고 필요한 운영 편의성을 제공하는 Pick the managed service 를 선택합니다.

이 프레임워크를 통해 논문상으로 가장 좋아 보이는 것이 아니라 가장 늦게 실패하는 데이터베이스를 선택하게 됩니다.

데이터베이스 엔진 선택을 위한 의도적 가이드

모니터링해야 할 핵심 지표

Replication lag – 소스보다 몇 초 뒤처졌는지.
Lock waits / deadlocks – 인덱스 누락을 조기에 파악.
Buffer‑pool hit rate – 메모리 크기와 작업 집합이 맞는지 여부를 나타냄.
Redo / binlog volume – 급증 여부를 감시 (예: 마이그레이션 중).
Rows examined vs. rows returned – 비효율적인 쿼리를 찾아냄.

팁: 두 데이터베이스를 모두 깊이 계측할 시간이 없다면, 그것 자체가 신호다. 사고 발생 시 팀이 이미 잘 다룰 수 있는 엔진을 선택하라.

PostgreSQL을 선택해야 할 경우

서비스가 시간이 지남에 따라 쿼리 복잡도가 누적될 예정일 때.
JSON이 제품의 핵심 쿼리 영역일 때.
다중 테넌트 격리가 필요할 때 (예: Row‑Level Security).
vacuum 및 bloat 관리를 의식적으로 수행할 준비가 되어 있을 때.

MySQL을 선택해야 할 경우

워크로드가 예측 가능하고 쿼리 패턴이 안정적일 때.
복제와 읽기 확장을 위한 가장 일반적인 운영 매뉴얼을 선호할 때.

아직 결정하지 못했다면

고통스러울 것으로 예상되는 JSON 및 동시성 패턴을 구현한다.
해당 패턴을 부하 하에서 실행한다.
실패 모드를 감당할 수 있는 엔진을 선택한다.