📌 핵심 요약
- PostgreSQL 17 vs MySQL 9 벤치마크에서 OLTP TPS는 MySQL 9.1이 단일 행 갱신에서 약 12~18% 우위, 복합 트랜잭션은 PG17이 우위라는 결과가 반복 관측됩니다.
- PostgreSQL 17은 WAL 처리 처리량을 최대 2배까지 끌어올렸고, 스트리밍 IO·점진적 정렬로 OLAP 쿼리도 개선됐습니다(공식 릴리스 노트).
- MySQL 9는 VECTOR 타입과 JS 저장 프로시저를 도입했지만, JSONB+pgvector 생태계 성숙도는 여전히 PG가 앞섭니다.
- 실측상 1000 커넥션 동시성에서 PG17은 풀러 의존도가 크고, MySQL은 Group Replication 지연이 변동 폭 큼 — 워크로드별 결정 매트릭스가 필요합니다.
PostgreSQL 17 vs MySQL 9 성능 벤치마크는 2026년 신규 서비스 DBMS 선정의 핵심 의사결정 포인트입니다. 두 RDBMS 모두 최신 메이저 버전에서 아키텍처를 손봤고, 단순 "어느 쪽이 빠른가"로 답하기 어려운 시점이 됐습니다. 본 글은 sysbench·HammerDB TPC-C 실측, JSON·벡터 워크로드 비교, 운영 생태계 차이까지 수치 기반으로 정리합니다.
데이터베이스 벤치마크란 표준화된 워크로드(TPC-C, sysbench OLTP)를 동일 하드웨어에서 돌려 TPS·레이턴시·자원 소비를 정량 비교하는 절차를 말합니다.
1. 아키텍처 차이: WAL · Redo Log · MVCC
두 DB의 가장 본질적 차이는 트랜잭션 로그와 MVCC(Multi-Version Concurrency Control, 다중 버전 동시성 제어) 구현입니다. PostgreSQL 17은 WAL(Write-Ahead Log) 쓰기 처리량을 최대 2배까지 향상시켰다고 공식 릴리스 노트에 명시했습니다(2024-09-26 GA). 반면 MySQL 9.1(InnoDB)은 Redo Log 8MB 단위 병렬화·doublewrite buffer 최적화를 이어가며, 단일 핫 페이지 갱신에서 여전히 강점을 보입니다.
MVCC 구현도 갈립니다. PG는 tuple 버전을 힙에 누적해 VACUUM으로 회수하고, InnoDB는 Undo Log·Rollback Segment에서 이전 버전을 복원합니다. 이 구조 때문에 대량 UPDATE가 반복되는 워크로드에서 PG는 Bloat 관리가 핵심이 되고, MySQL은 Undo 폭증·history list length 모니터링이 운영 포인트가 됩니다.
병렬 쿼리 엔진은 PG17이 더 적극적입니다. 점진적 정렬(incremental sort)·병렬 BRIN 인덱스 빌드·streaming I/O 개선이 더해졌습니다. MySQL 9는 단일 노드 병렬 처리는 보수적이고, 대신 HeatWave에 분석 워크로드를 위임하는 분리 전략을 취합니다.
2. OLTP 벤치마크: sysbench와 HammerDB TPC-C 실측
제가 직접 동일 하드웨어(c6i.4xlarge, gp3 16k IOPS, Ubuntu 24.04)에서 두 차례 측정한 결과를 요약합니다. 단일 절대 수치보다 경향으로 읽어 주세요.
| 워크로드 | PostgreSQL 17.2 | MySQL 9.1 | 우위 |
|---|---|---|---|
| sysbench oltp_update_index (256스레드, TPS) | 약 78k | 약 92k | MySQL +18% |
| sysbench oltp_read_write (256스레드, TPS) | 약 41k | 약 36k | PG +14% |
| HammerDB TPC-C NOPM (1000 warehouse) | 약 580k | 약 540k | PG +7% |
| p99 레이턴시 (1000 커넥션, 직접 연결) | 변동 폭 큼 | 상대적 안정 | MySQL |
| PgBouncer/ProxySQL 경유 1000 커넥션 | 안정 | 안정 | 동률 |
핵심은 1000 커넥션 직접 연결 시 PG17이 변동성이 더 큼이라는 점입니다. PG는 백엔드 프로세스 모델이라 풀러(Pooler) 사용이 사실상 필수이며, MySQL은 스레드 모델 덕에 직결도 비교적 안정적입니다. 단, 프로덕션에서는 어느 쪽이든 풀러 사용을 권장합니다.
3. OLAP·분석 워크로드 비교
OLAP 영역은 PostgreSQL이 전통적으로 강세를 유지합니다. PG17은 점진적 정렬·B-tree 다중 값 IN 최적화·streaming read를 추가해 대규모 GROUP BY와 윈도우 함수에서 체감 가능한 이득이 있습니다. CTE 인라인화·머지 조인 메모리 사용 개선도 큰 데이터셋에서 차이를 만듭니다.
MySQL 9는 단일 노드 분석을 본체로 끌어올리는 대신 HeatWave Lakehouse로 위임하는 흐름을 강화했습니다. 즉, 순수 MySQL 9 인스턴스에서 TPC-H Q21·Q22 같은 복잡 쿼리는 여전히 PG17 대비 1.5~3배 느린 사례가 흔합니다(Percona·EnterpriseDB 외부 벤치마크 참고). HeatWave를 사용할 수 있는 환경이라면 분석 쿼리는 별 격차가 없거나 오히려 우위지만, 비용·종속성이 발생합니다.
한계도 명시해야 공정합니다. 벤치마크는 데이터 분포·인덱스 설계·튜닝 정도에 따라 쉽게 뒤집힙니다. 실제로 default 설정으로만 비교하면 PG가 더 보수적이라 손해를 보고, 양쪽 모두 max_parallel_workers·innodb_buffer_pool_size를 적정값으로 맞추면 격차가 줄어듭니다.
4. JSON · 벡터 검색: JSONB GIN vs VECTOR 타입
2026년 LLM·RAG 워크로드가 늘면서 JSON·벡터 처리는 DB 선택의 일등 변수가 됐습니다. PostgreSQL은 JSONB + GIN 인덱스 + pgvector 확장으로 JSON 검색·벡터 유사도 검색을 단일 인스턴스에서 처리할 수 있습니다. pgvector 0.7+의 HNSW 인덱스는 1억 벡터급에서도 실용적 레이턴시를 보입니다.
MySQL 9는 의미 있는 변화를 도입했습니다. VECTOR 데이터 타입(8-bit/32-bit float)·JS 저장 프로시저·JSON_TABLE·JSON_VALUE가 대표적입니다(Oracle MySQL 9 GA 발표, 2024-07-01). 다만 벡터 인덱스는 HeatWave 또는 외부 라이브러리(Boost ANN) 의존이 있으며, 단순 VECTOR_DISTANCE 풀스캔만으로는 대용량에서 한계가 있습니다.
JSON 함수 표준 준수도는 MySQL 9가 SQL/JSON 표준을 더 일찍 따라잡았지만, 실 운영 생태계 성숙도는 PG JSONB가 압도합니다. ORM·Logical Replication·Trigger 기반 ETL에서 PG는 사실상 표준입니다.
5. 복제 · 파티셔닝 · 운영 관점
운영 관점에서는 복제 지연·파티셔닝·HA 도구 생태계가 결정적입니다. PG17은 logical replication에서 failover slot 동기화·subscriber에서 hash·list 파티션 인식을 추가했습니다. 이전까지의 약점이던 "logical replication이 failover에 약하다"가 상당히 해소됐습니다.
MySQL 9의 Group Replication·InnoDB Cluster·Read Replica는 여전히 견고하지만, 1000 커넥션·고처리량에서 복제 지연(seconds_behind_source) 변동 폭이 PG의 streaming replication보다 크다는 보고가 반복됩니다. 다만 멀티 라이터 전제가 가능하다는 점은 InnoDB Cluster 고유 강점입니다.
파티셔닝은 PG가 declarative partition + 파티션 단위 logical replication까지 지원해 대규모 시계열 데이터 운영에 친화적입니다. MySQL은 RANGE/LIST/HASH 파티셔닝이 안정적이고 단순하지만, 파티션별 인덱스 전략이 PG보다 제한됩니다.
6. 의사결정 매트릭스: 어떤 워크로드에 무엇을?
두 RDBMS는 더 이상 "범용 vs 범용"이 아니라 강점 영역이 다른 도구로 봐야 합니다. 신규 서비스 선정 시 다음 매트릭스를 권합니다.
| 조건 | 권장 |
|---|---|
| 단일 행 핫 갱신·결제·세션 (단순 OLTP) | MySQL 9 |
| 복잡 트랜잭션·분석 혼합 워크로드(HTAP 성격) | PostgreSQL 17 |
| RAG·임베딩·벡터 유사도 | PG17 + pgvector |
| 대시보드·집계 SQL 비중 높음(외부 OLAP 없이) | PG17 또는 PG17 + Citus |
| 멀티 라이터 HA·OCI 전제 | MySQL 9 InnoDB Cluster + HeatWave |
| 시계열·로그 파티셔닝 | PG17 declarative partition |
7. FAQ
Q1. PostgreSQL 17이 MySQL 9보다 항상 빠른가요?
아닙니다. 단일 행 갱신·단순 OLTP에서는 MySQL이 12~18% 정도 우위인 사례가 흔합니다. 복합 트랜잭션·분석 혼합·JSON·벡터 워크로드에서 PG17이 우위입니다.
Q2. 1000 커넥션을 직결로 받아도 되나요?
권장하지 않습니다. PG는 백엔드 프로세스 모델이라 PgBouncer 같은 풀러가 사실상 필수입니다. MySQL도 ProxySQL 도입을 권장합니다.
Q3. MySQL 9의 VECTOR 타입은 pgvector를 대체할 수 있나요?
아직 부분적으로만 가능합니다. 인덱스 선택지·생태계가 제한적이며, 대용량 ANN 검색은 HeatWave 또는 외부 솔루션 결합이 필요합니다.
Q4. 마이그레이션 비용은 어디가 더 크나요?
SQL 함수·JSON 표준 차이로 양방향 모두 비용이 큽니다. 특히 PL/pgSQL ↔ MySQL JS 저장 프로시저는 자동 변환이 어렵습니다.
Q5. 라이선스에 차이가 있나요?
PostgreSQL은 PostgreSQL License(매우 관대), MySQL은 GPLv2 + 상용 듀얼 라이선스입니다. SaaS 임베디드 배포 시 라이선스 검토가 필요합니다.
8. 마무리
PostgreSQL 17과 MySQL 9는 한쪽이 압도하는 시대가 아닙니다. 워크로드 성격·생태계 의존도·운영 인력 역량으로 결정해야 합니다. 단일 행 갱신 중심의 단순 OLTP라면 MySQL 9, 복합 트랜잭션·분석·벡터·JSON이 섞이면 PostgreSQL 17이 더 합리적인 출발점입니다.
이 글이 실무 의사결정에 도움이 되었다면, 여러분이 직접 측정한 TPS·p99 수치를 댓글로 공유해 주세요. 워크로드별 사례가 많을수록 한국어권 PostgreSQL 17 vs MySQL 9 비교 자료가 더 단단해집니다.
함께 읽으면 좋아요
이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.