PostgreSQL vs MySQL: 2026년에 새 프로젝트라면 어느 쪽인가
4 분 소요
새 프로젝트라면 특별한 이유가 없는 한 PostgreSQL을 권합니다. 반대로 팀이 이미 MySQL 운영 경험과 도구 위에 서 있다면, 갈아탈 이유도 대개는 없습니다. 두 DB 모두 성숙한 프로덕션급이고 대부분의 워크로드를 무리 없이 받치므로, 이 글은 우열 논쟁이 아니라 “어떤 조건이면 어느 쪽인가"의 판단 기준을 정리합니다. 마침 2026년 4월로 MySQL 8.0의 지원이 끝나서, MySQL 진영도 어차피 8.4 LTS로의 이주를 결정해야 하는 시점입니다.
한눈에 보는 비교 #
| 항목 | PostgreSQL | MySQL |
|---|---|---|
| 표준 준수·엄격함 | SQL 표준에 충실, 무결성에 엄격 | 역사적으로 관대(모드로 보완) |
| 기능 폭 | JSONB·배열·범위 타입·CTE·윈도·전문 검색 내장 | 핵심 기능은 갖춤, 폭은 좁음 |
| 확장 생태계 | pgvector·PostGIS·TimescaleDB 등 확장 구조 | 제한적(스토리지 엔진 플러그인 중심) |
| 복제 | 물리(스트리밍) + 논리, 도구는 조합형 | 논리 복제 역사가 길고 운영 노하우 축적 |
| 라이선스·거버넌스 | 커뮤니티 소유, 관대한 라이선스 | Oracle 소유, GPL + 상용 이중 |
| 버전 정책 | 매년 메이저, 각 5년 지원 | LTS(8.4, 지원 ~2029/2032) + Innovation(9.x) |
PostgreSQL로 기우는 조건 #
- 기능의 폭을 쓸 계획이 있을 때. JSONB, 배열, 범위 타입,
DISTINCT ON, 트랜잭션이 되는 DDL(실전 마이그레이션 편에서 다룬 그 강점)처럼 “별도 시스템 없이 DB 안에서 해결"되는 범위가 넓습니다. 벡터 검색(pgvector), 지리 정보(PostGIS) 같은 확장까지 계산에 넣으면 격차가 더 벌어집니다. - 데이터 무결성이 성패를 가르는 도메인일 때. PostgreSQL은 잘못된 값을 조용히 받아 주는 대신 에러를 냅니다. MySQL도 strict 모드가 기본이 된 지 오래지만, 설계 철학의 기본기가 엄격한 쪽은 PostgreSQL입니다.
- 생태계의 방향에 올라타고 싶을 때. 새 프레임워크의 기본값, 새 도구의 지원 목록 첫 줄, 관리형 신제품의 출시 순서가 몇 년째 PostgreSQL 우선입니다. 기초 강좌 1편에서 다룬 “기본값이 된 이유"가 곧 선택의 이유가 됩니다.
MySQL을 유지(또는 선택)하는 조건 #
- 팀과 조직의 축적이 MySQL에 있을 때. 운영 경험, 백업·복제 운영 노하우, 사내 표준, 모니터링 체계는 DB 기능보다 무겁습니다. 이 축적을 버리는 비용이 PostgreSQL의 기능 이득보다 크면 유지가 맞습니다.
- MySQL 특화 생태계에 의존할 때. 대규모 온라인 스키마 변경(gh-ost 등), 오케스트레이션, 프록시처럼 MySQL의 대규모 운영 도구는 검증 역사가 깁니다. 특히 초대형 샤딩 운영(Vitess 계열)은 MySQL 쪽 자산입니다.
- 제품 요건이 단순한 OLTP + 검증된 읽기 분산일 때. 이 범위에서는 두 DB의 차이가 체감되지 않으며, 어느 쪽을 골라도 됩니다.
단, MySQL을 유지한다면 버전 결정이 하나 남습니다. 8.0은 2026년 4월로 지원이 끝났으므로 8.4 LTS로 이주가 사실상 필수이고(8.4는 2029년까지 프리미어 지원), 9.x는 Innovation 릴리스라 일반 프로덕션용이 아닙니다.
자주 나오는 반론 두 가지 #
MySQL이 더 빠르지 않냐는 물음은 이제 사실이 아니라 워크로드 문제입니다. 단순 PK 조회 중심이면 MySQL(InnoDB 클러스터드 인덱스)이 유리한 시나리오가 있고, 복잡한 조인·집계·동시 읽기쓰기 혼합이면 PostgreSQL 플래너가 유리한 시나리오가 있습니다. 벤치마크 한 장으로 결정하지 말고 자기 쿼리 패턴으로 판단해야 합니다. PostgreSQL은 UPDATE가 비싸다는 말은 절반만 맞습니다. MVCC 구현상 UPDATE가 새 버전 행을 만들고 VACUUM이 뒤따르는 구조는 사실이지만, 실무 대응(autovacuum 튜닝, VACUUM 운영)이 정립되어 있어 설계 단계에서 겁먹을 이유는 아닙니다.
판단 순서 #
- 팀의 기존 축적(운영 경험·도구·표준)이 어느 쪽에 있는지부터 봅니다. 축적이 있으면 그쪽이 기본값입니다.
- 축적이 없다면(새 팀·새 제품) PostgreSQL을 기본값으로 두고, MySQL 특화 요건(초대형 샤딩 생태계 등)이 있는지만 점검합니다.
- 기능 요건 목록(벡터 검색·지리 정보·복잡한 분석 쿼리·JSONB)을 대조합니다. 하나라도 핵심이면 PostgreSQL 쪽 무게가 커집니다.
- MySQL로 결정했다면 8.4 LTS 기준으로 시작합니다. 8.0은 지원이 끝났고 9.x는 Innovation입니다.
정리 #
- 새 프로젝트의 기본값은 PostgreSQL, 이미 MySQL 위에 선 팀은 유지가 기본값입니다. 우열이 아니라 조건의 문제입니다.
- PostgreSQL의 강점은 기능 폭(JSONB·확장·DDL 트랜잭션)과 생태계의 방향성입니다.
- MySQL의 강점은 축적된 대규모 운영 노하우와 특화 도구(온라인 스키마 변경·샤딩 생태계)입니다.
- MySQL 8.0은 2026-04 지원 종료입니다. 유지하더라도 8.4 LTS 이주 계획이 필요합니다.
- 성능 논쟁은 워크로드 문제입니다. 벤치마크 인용이 아니라 자기 쿼리 패턴으로 판단하세요. PostgreSQL을 처음부터 배우려면 기초 강좌가 준비되어 있습니다.