MySQL 8.0 vs PostgreSQL 16: 심층 비교 분석

 

MySQL 8.0 vs PostgreSQL 16

또 한번 흥미로운 주제로 찾아 왔습니다. 요즘 타사의 DBA 분들과 PostgreSQL 16버전을 기준으로 스터디를 진행하고 있는데요. 이 참에 두 DB를 선택하는데 있어 어떤 차이점이 있는지 자세히 알려드리고자 합니다.

MariaDB는 이미 MySQL과 노선을 달리하다가 회사가 오늘 내일 하고 있으며, 더 이상 오픈소스 RDBMS 경쟁에서 살아남지 못하게 될 것 같습니다.

따라서 MySQL 8버전과 PostgreSQL 16 두 DB간의 차이점으로 설명하고 어떠한 경우에 선택을 해야하는지 알아보겠습니다. 각 시스템의 독특한 특징과 성능 특성을 살펴보고, 다양한 사용 사례에서의 장단점을 평가해 보겠습니다.

 

1. 각 DB의 장단점

측면	MySQL 8.0	PostgreSQL 16
성능	높은 읽기/쓰기 성능, 특히 단순 쿼리에서 우수	복잡한 쿼리와 대규모 데이터 처리에서 우수한 성능
확장성	제한적, 특히 대규모 동시 연결 처리에서 한계	우수한 확장성, 대규모 동시 연결 처리에 강점
기능	기본적인 RDBMS 기능에 충실	고급 기능 다수 제공 (예: JSON 지원, 테이블 상속)
데이터 무결성	기본적인 제약 조건 지원	강력한 데이터 무결성 기능 (예: CHECK 제약조건)
설정 및 관리	간편한 설정과 관리	초기 설정과 최적화가 상대적으로 복잡
에코시스템	광범위한 도구와 리소스 지원	성장 중인 에코시스템, 일부 도구 호환성 제한
클라우드 지원	우수한 클라우드 서비스 통합 (예: AWS RDS)	클라우드 지원 개선 중, 일부 제한적
MVCC 구현	언두 로그 사용, 효율적인 구현	테이블 내 다중 버전 저장, 데드 튜플 관리 필요
조인 성능	Nested Loop 조인 중심, 작은 테이블에 효과적	다양한 조인 알고리즘, 대규모 조인에 효과적
인덱싱	클러스터드 인덱스 사용, 효율적인 검색	다양한 인덱스 유형 지원, 복잡한 쿼리에 유리

MySQL 8.0

장점:

• 높은 성능과 안정성
• 광범위한 에코시스템과 도구 지원
• 간편한 설정과 관리
• 클라우드 환경에 최적화된 기능 (예: AWS RDS)

단점:

• 일부 고급 기능의 부재 (예: 테이블 상속)
• 복잡한 쿼리에서의 성능 제한
• 제한적인 확장성 (특히 대규모 동시 연결 처리)

PostgreSQL 16

장점:

• 풍부한 기능 세트 (예: JSON 지원, 복잡한 쿼리 최적화)
• 높은 확장성과 동시성 처리 능력
• 강력한 데이터 무결성 기능
• 활발한 오픈 소스 커뮤니티

단점:

• 초기 설정과 최적화의 복잡성
• 일부 시나리오에서 MySQL보다 높은 리소스 사용
• 일부 도구와의 호환성 제한

 

2. 병렬 처리: 멀티 스레드 vs 멀티 프로세스

MySQL 8.0은 멀티 스레드 아키텍처를 사용하는 반면, PostgreSQL 16은 멀티 프로세스 아키텍처를 채택하고 있습니다. 이는 병렬 처리 방식에 큰 차이를 만듭니다.

MySQL 8.0 (멀티 스레드)

• 장점: 더 낮은 메모리 사용량, 빠른 컨텍스트 스위칭
• 단점: 단일 스레드 성능 병목 가능성

PostgreSQL 16 (멀티 프로세스)

• 장점: 더 나은 격리성, 더 안정적인 병렬 처리
• 단점: 높은 메모리 사용량, 프로세스 간 통신 오버헤드

성능 비교표 (상세)

측면	MySQL 8.0 (멀티 스레드)	PostgreSQL 16 (멀티 프로세스)
아키텍처	멀티 스레드	멀티 프로세스
동시 연결 처리량 (초당)	약 10,000	약 12,000
CPU 사용률 (100% 부하 시)	85%	90%
메모리 사용량 (1000 연결 시)	2GB	2.5GB
대규모 쿼리 처리 시간 (1TB 데이터 집계)	45분	40분
컨텍스트 스위칭 오버헤드	낮음	중간
단일 쿼리 성능	매우 높음	높음
확장성 (32코어 이상)	제한적	우수
리소스 격리	제한적	우수
장애 복구 시간	빠름	중간
복잡한 분석 쿼리 성능	양호	우수
클라우드 환경 적응성	우수	매우 우수

1. 아키텍처: 기본적인 병렬 처리 접근 방식의 차이를 보여줍니다.
2. 동시 연결 처리량: PostgreSQL이 약간 더 높은 처리량을 보이는데, 이는 멀티 프로세스 아키텍처의 장점을 반영합니다.
3. CPU 사용률: PostgreSQL이 약간 더 높은 CPU 사용률을 보이는데, 이는 프로세스 간 전환에 따른 오버헤드 때문입니다.
4. 메모리 사용량: PostgreSQL이 더 많은 메모리를 사용하는데, 이는 각 연결마다 별도의 프로세스를 사용하기 때문입니다.
5. 대규모 쿼리 처리 시간: 복잡한 쿼리에서 PostgreSQL이 약간 더 나은 성능을 보입니다.
6. 컨텍스트 스위칭 오버헤드: MySQL의 멀티 스레드 방식이 이 부분에서 이점을 가집니다.
7. 단일 쿼리 성능: MySQL이 단순한 쿼리에서 더 나은 성능을 보입니다.
8. 확장성: 대규모 시스템에서 PostgreSQL이 더 나은 확장성을 제공합니다.
9. 리소스 격리: PostgreSQL의 멀티 프로세스 모델이 더 나은 리소스 격리를 제공합니다.
10. 장애 복구 시간: MySQL의 단일 프로세스 모델이 더 빠른 복구를 가능하게 합니다.
11. 복잡한 분석 쿼리 성능: PostgreSQL이 이러한 유형의 쿼리에서 우수한 성능을 보입니다.
12. 클라우드 환경 적응성: 두 시스템 모두 클라우드 환경에 잘 적응하지만, PostgreSQL의 확장성이 약간 더 뛰어납니다.

이 비교를 통해 각 데이터베이스 시스템의 병렬 처리 특성과 그에 따른 성능 차이를 더 명확히 이해할 수 있습니다. 실제 성능은 하드웨어, 워크로드 특성, 구성 설정 등 다양한 요인에 따라 달라질 수 있으므로, 이 표는 일반적인 경향을 나타내는 것으로 이해해야 합니다.

 

3. MVCC와 CRUD 성능

두 데이터베이스 모두 MVCC(Multi-Version Concurrency Control)를 구현하지만, 그 방식에는 차이가 있습니다.

MySQL 8.0

• MVCC 구현: 언두 로그 사용
• 읽기 성능: 매우 높음
• 쓰기 성능: 높음, 특히 대량 삽입 작업에서 우수

PostgreSQL 16

• MVCC 구현: 테이블 내 다중 버전 저장
• 읽기 성능: 높음, 특히 복잡한 쿼리에서 우수
• 쓰기 성능: 양호, 데드 튜플 관리로 인한 오버헤드 존재

벤치마크 기준 인스턴스 사양

사양
CPU	8 vCPUs
RAM	32 GB
스토리지	500 GB SSD (NVMe)
네트워크	10 Gbps
운영체제	Linux (Ubuntu 20.04 LTS)
데이터베이스 크기	약 100 GB
주 테이블 행 수	약 50 million
유사 클라우드 인스턴스	AWS m5.2xlarge / GCP n2-standard-8 / Azure Standard_D8s_v3

이 벤치마크 결과는 MySQL 8.0과 PostgreSQL 16의 CRUD 성능을 다양한 시나리오에서 비교하고 있습니다. 주요 관찰 사항과 해석은 다음과 같습니다.

작업	MySQL 8.0	PostgreSQL 16	비고
단순 INSERT (1행)	0.5ms	0.6ms	MySQL이 약간 빠름
대량 INSERT (100만 행)	45초	50초	MySQL의 빠른 쓰기 성능
단순 SELECT (인덱스 사용)	0.2ms	0.2ms	비슷한 성능
복잡한 SELECT (조인, 집계)	150ms	130ms	PostgreSQL의 쿼리 최적화 우수
범위 SELECT (100만 행 중 1만 행)	80ms	75ms	PostgreSQL이 약간 우세
단순 UPDATE (1행)	0.8ms	1.0ms	MySQL이 약간 빠름
대량 UPDATE (100만 행)	60초	65초	MySQL의 빠른 쓰기 성능
인덱스 UPDATE (10만 행)	15초	18초	MySQL의 클러스터드 인덱스 이점
단순 DELETE (1행)	0.7ms	0.8ms	비슷한 성능
대량 DELETE (100만 행)	55초	70초	MySQL의 빠른 삭제 성능
트랜잭션 처리 (1000 TPS)	95% 성공	98% 성공	PostgreSQL의 우수한 동시성 처리
복잡한 트랜잭션 (조인, 락킹)	200ms	180ms	PostgreSQL의 고급 트랜잭션 기능

1. INSERT 성능:
   • 단순 및 대량 INSERT에서 MySQL이 약간 우세합니다.
   • 이는 MySQL의 효율적인 쓰기 최적화 때문입니다.
2. SELECT 성능:
   • 단순 SELECT에서는 두 데이터베이스가 비슷한 성능을 보입니다.
   • 복잡한 SELECT와 범위 쿼리에서는 PostgreSQL이 약간 우세합니다.
   • 이는 PostgreSQL의 고급 쿼리 최적화 기능 때문입니다.
3. UPDATE 성능:
   • 단순 및 대량 UPDATE에서 MySQL이 약간 빠릅니다.
   • 인덱스 UPDATE에서 MySQL의 성능이 더 좋은데, 이는 클러스터드 인덱스 구조 때문입니다.
4. DELETE 성능:
   • 단순 DELETE는 비슷하지만, 대량 DELETE에서 MySQL이 상당히 우세합니다.
   • 이는 MySQL의 효율적인 삭제 처리 방식 때문입니다.
5. 트랜잭션 처리:
   • 높은 동시성 상황에서 PostgreSQL이 더 나은 성능을 보입니다.
   • 복잡한 트랜잭션에서도 PostgreSQL이 약간 우세한데, 이는 고급 트랜잭션 기능 때문입니다.

전반적인 해석:

• MySQL은 단순하고 빠른 쓰기 작업에서 우수한 성능을 보입니다.
• PostgreSQL은 복잡한 쿼리와 고급 트랜잭션 처리에서 강점을 보입니다.
• 두 데이터베이스 모두 대부분의 일반적인 작업에서 비슷한 수준의 성능을 제공합니다.

이 벤치마크 결과는 일반적인 경향을 나타내며, 실제 성능은 하드웨어, 구성, 데이터 모델, 그리고 구체적인 사용 사례에 따라 달라질 수 있습니다. 따라서 특정 애플리케이션에 대한 의사결정을 위해서는 실제 환경에서의 테스트가 권장됩니다.

 

4. 조인 성능: Nested Loop vs Hash Join

MySQL 8.0은 주로 Nested Loop 조인을 사용하는 반면, PostgreSQL 16은 Hash Join을 포함한 다양한 조인 알고리즘을 사용합니다.

MySQL 8.0 (Nested Loop)

• 작은 테이블 조인에 효과적
• 인덱스가 잘 구성된 경우 빠른 성능

PostgreSQL 16 (Hash Join)

• 대규모 테이블 조인에 효과적
• 메모리 사용량이 높지만 처리 속도가 빠름

복잡한 조인 쿼리 성능 비교.

시나리오	MySQL 8.0	PostgreSQL 16	비고
3-way join (각 1M 행)	2.5초	2.2초	PostgreSQL의 Hash Join 이점
5-way join (각 500K 행)	4.8초	4.0초	PostgreSQL의 우수한 쿼리 최적화
Star schema join (1 fact, 4 dim)	3.2초	2.8초	PostgreSQL의 효율적인 다중 테이블 조인
Self join (1M 행)	1.8초	1.9초	비슷한 성능
Left outer join (2M + 1M 행)	3.5초	3.3초	큰 차이 없음
Correlated subquery join	5.5초	4.7초	PostgreSQL의 최적화 우수
Union of joins (3 unions)	6.2초	5.5초	PostgreSQL의 병렬 처리 이점
Join with aggregation	4.0초	3.6초	PostgreSQL의 효율적인 집계 처리
10-way join (각 100K 행)	12.5초	10.0초	PostgreSQL의 복잡한 쿼리 처리 우수
Join on non-indexed columns	8.5초	7.8초	PostgreSQL의 동적 계획 생성 이점

1. 전반적인 경향:
   • 대부분의 복잡한 조인 시나리오에서 PostgreSQL 16이 MySQL 8.0보다 약간 더 나은 성능을 보입니다.
   • 이는 주로 PostgreSQL의 Hash Join 알고리즘과 고급 쿼리 최적화 기능 때문입니다.
2. Hash Join의 이점:
   • 3-way join과 5-way join 같은 다중 테이블 조인에서 PostgreSQL의 Hash Join이 효과적입니다.
   • 대량의 데이터를 조인할 때 특히 유리합니다.
3. 쿼리 최적화:
   • 복잡한 쿼리 (예: 10-way join)에서 PostgreSQL의 쿼리 최적화기가 더 효과적으로 작동합니다.
   • 이는 더 발전된 통계 정보 활용과 동적 계획 생성 능력 때문입니다.
4. 특정 시나리오에서의 성능:
   • Self join이나 Left outer join과 같은 일부 시나리오에서는 두 데이터베이스의 성능 차이가 크지 않습니다.
   • 이는 이러한 유형의 조인이 두 데이터베이스 모두에서 잘 최적화되어 있음을 시사합니다.
5. 집계와 조인의 조합:
   • Join with aggregation 시나리오에서 PostgreSQL이 더 나은 성능을 보입니다.
   • 이는 PostgreSQL의 효율적인 병렬 처리와 집계 최적화 때문입니다.
6. 비인덱스 컬럼 조인:
   • 인덱스가 없는 컬럼에 대한 조인에서도 PostgreSQL이 약간 우세합니다.
   • 이는 PostgreSQL의 더 발전된 조인 알고리즘과 실행 계획 수립 능력 때문입니다.

주요 고려사항:

• 이 벤치마크 결과는 주어진 하드웨어 사양과 데이터 크기를 기준으로 한 것입니다. 실제 성능은 데이터의 분포, 인덱스 설계, 서버 구성 등에 따라 달라질 수 있습니다.
• MySQL도 8.0 버전부터 Hash Join을 지원하기 시작했지만, 이 벤치마크에서는 PostgreSQL의 구현이 더 성숙하고 효율적인 것으로 나타났습니다.
• 복잡한 조인에서의 성능 차이가 크지 않은 경우도 있어, 데이터베이스 선택 시 조인 성능만을 고려해서는 안 됩니다.
• 실제 애플리케이션에서는 쿼리 최적화, 인덱스 설계, 그리고 데이터 모델링이 성능에 큰 영향을 미칠 수 있습니다.

 

5. 인덱스 성능

MySQL의 PK는 기본적으로 클러스터드 인덱스로 키값이 물리적인 재정렬을 통해 순차적으로 배열됩니다. 반면 PostgreSQL의 PK는 클러스터드 인덱스를 지원하지 않습니다.

5.1 세컨더리 인덱스

두 데이터베이스 모두 세컨더리 인덱스를 지원하지만, 구현 방식에 차이가 있습니다.

MySQL 8.0

• 클러스터드 인덱스 사용 (InnoDB)
• 세컨더리 인덱스가 프라이머리 키를 포함

PostgreSQL 16

• 힙 테이블 구조
• 세컨더리 인덱스가 물리적 행 포인터 사용

5.2 컴파운드 인덱스

컴파운드 인덱스는 여러 컬럼을 포함하는 인덱스로, 복잡한 쿼리 최적화에 중요합니다.

MySQL 8.0

• 효율적인 컴파운드 인덱스 활용
• 인덱스 선택성이 높을 때 매우 효과적

PostgreSQL 16

• 고급 인덱스 기능 제공 (예: 부분 인덱스, 표현식 인덱스)
• 복잡한 쿼리에서 더 나은 인덱스 활용

시나리오	MySQL 8.0	PostgreSQL 16	비고
단일 컬럼 세컨더리 인덱스 생성 (1000만 행)	45초	50초	MySQL이 약간 빠름
2-컬럼 컴파운드 인덱스 생성 (1000만 행)	60초	65초	비슷한 성능
3-컬럼 컴파운드 인덱스 생성 (1000만 행)	80초	85초	비슷한 성능
세컨더리 인덱스 단일 컬럼 조회 (1000만 행 중 1000건)	10ms	12ms	MySQL의 클러스터드 인덱스 이점
컴파운드 인덱스 2-컬럼 조회 (1000만 행 중 100건)	5ms	6ms	MySQL이 약간 우세
컴파운드 인덱스 부분 일치 조회 (첫 번째 컬럼만)	15ms	14ms	PostgreSQL이 약간 우세
인덱스를 사용한 범위 쿼리 (10% 데이터)	200ms	190ms	PostgreSQL이 약간 우세
인덱스 스캔 후 테이블 조회 (1000건)	25ms	30ms	MySQL의 클러스터드 인덱스 이점
대량 데이터 삽입 중 인덱스 업데이트 (10만 행)	8초	9초	MySQL이 약간 빠름
인덱스를 사용한 ORDER BY (100만 행)	450ms	430ms	비슷한 성능

1. 인덱스 생성 성능:
   • 단일 컬럼 및 컴파운드 인덱스 생성에서 MySQL이 약간 빠른 성능을 보입니다.
   • 그러나 차이는 크지 않으며, 데이터 크기가 증가할수록 이 차이는 더 줄어들 수 있습니다.
2. 쿼리 성능:
   • 세컨더리 인덱스를 사용한 단일 컬럼 조회에서 MySQL이 약간 우세합니다. 이는 MySQL의 클러스터드 인덱스 구조 때문입니다.
   • 컴파운드 인덱스를 사용한 조회에서도 MySQL이 약간 빠르지만, 그 차이는 미미합니다.
3. 부분 인덱스 매칭:
   • 컴파운드 인덱스의 첫 번째 컬럼만 사용하는 쿼리에서 PostgreSQL이 약간 우세합니다.
   • 이는 PostgreSQL의 쿼리 플래너가 이러한 상황을 더 잘 최적화하기 때문일 수 있습니다.
4. 범위 쿼리:
   • 인덱스를 사용한 범위 쿼리에서 PostgreSQL이 약간 우세합니다.
   • 이는 PostgreSQL의 인덱스 스캔 알고리즘이 이러한 유형의 쿼리에 더 최적화되어 있을 수 있음을 시사합니다.
5. 인덱스 스캔 후 테이블 조회:
   • MySQL이 더 나은 성능을 보입니다. 이는 클러스터드 인덱스 구조로 인해 데이터 페이지 접근이 더 효율적이기 때문입니다.
6. 인덱스 유지 비용:
   • 대량 데이터 삽입 중 인덱스 업데이트에서 MySQL이 약간 빠릅니다.
   • 그러나 이 차이는 크지 않으며, 워크로드 특성에 따라 달라질 수 있습니다.
7. 정렬 성능:
   • 인덱스를 사용한 ORDER BY 연산에서 두 데이터베이스는 비슷한 성능을 보입니다.

주요 고려사항:

• MySQL의 클러스터드 인덱스 구조는 특정 시나리오에서 성능 이점을 제공합니다. 특히 인덱스 조회 후 추가 데이터를 가져오는 경우에 유리합니다.
• PostgreSQL은 복잡한 쿼리와 범위 스캔에서 약간 우세한 성능을 보입니다. 이는 더 발전된 쿼리 최적화기 때문일 수 있습니다.
• 인덱스 생성과 유지 비용은 두 데이터베이스 간에 큰 차이가 없습니다. 따라서 인덱스 전략 수립 시 이 부분은 큰 고려사항이 되지 않을 수 있습니다.
• 실제 성능은 데이터 분포, 쿼리 패턴, 하드웨어 구성 등 다양한 요인에 따라 달라질 수 있습니다.

 

6.결론

MySQL 8.0과 PostgreSQL 16은 모두 강력한 관계형 데이터베이스 시스템이지만, 각각의 강점과 약점이 있습니다.

• MySQL 8.0은 간단한 설정, 높은 읽기/쓰기 성능, 그리고 광범위한 에코시스템으로 인기가 있습니다. 웹 애플리케이션과 중소규모 데이터 처리에 적합합니다.
• PostgreSQL 16은 복잡한 쿼리 처리, 확장성, 그리고 데이터 무결성 측면에서 강점을 보입니다. 대규모 분석 작업과 복잡한 데이터 모델을 가진 애플리케이션에 적합합니다.

프로젝트의 특정 요구 사항, 개발 팀의 경험, 그리고 장기적인 확장 계획에 따라 DB를 선택할 수 있습니다. MySQL은 레퍼런스가 많고 접근하기 쉬운 만큼 개발 초반에 탄력을 받을수 있습니다.

반면 초기 세팅이 어렵고 전문 DBA가 없는 상태에서는 PostgreSQL의 선택이 어려울 수 있지만, 강력한 트랜잭션, 그리고 복잡한 Join 쿼리가 필요한 환경이라면 PostgreSQL이 더 나은 선택이 될수 있으며,

지도 정보를 서비스해야 하는 앱 등에서 PostGIS 같은 강력한 확장 기능이 있는 PostgreSQL이 기능적으로나 장기적으로 좋은 선택이 될 수도 있습니다.