백엔드 시스템을 구축하거나 새로운 프로젝트를 시작할 때 가장 고민되는 순간 중 하나가 바로 데이터베이스(RDBMS) 선택입니다.
그중에서도 가장 대중적이면서도 끊임없이 비교되는 라이벌이 바로 MySQL(InnoDB 엔진 기준)과 PostgreSQL인데요.
“그냥 둘 다 비슷비섭한 거 아닌가?” 싶지만, 내부 동작 아키텍처를 들여다보면 데이터를 다루는 방식과 서버 자원을 쓰는 결이 완전히 다릅니다.
트랜잭션 처리 방식부터 동시성 제어, 인덱스 구조와 메모리 사용량 관점까지 두 DB의 결정적인 차이점을 쉽게 풀어서 정리해 보았습니다.
1. MVCC 동작 방식의 차이: 언두 로그 vs 튜플 복사본
두 데이터베이스 모두 여러 사용자가 동시에 데이터를 읽고 쓸 때 서로 간섭하지 않도록 MVCC(Multi-Version Concurrency Control, 다중 버전 동시성 제어) 기술을 사용합니다. 하지만 구현 방식에서 아주 큰 차이가 납니다.
- MySQL (InnoDB): 언두 로그(Undo Log) 방식
MySQL은 데이터를 수정할 때 기존 테이블 공간의 원본 데이터를 직접 새로 바뀐 값으로 덮어씁니다. 대신 “변경되기 전 옛날 데이터”는 별도의 공간인 언두 로그(Undo Log) 영역에 차곡차곡 기록해 둡니다. 다른 트랜잭션이 읽기 작업을 요청하면 이 언두 로그를 역추적해서 과거 시점의 데이터를 보여줍니다.
- 장점: 데이터 테이블 자체의 크기가 커지지 않아 깔끔합니다.
- 단점: 오랫동안 켜져 있는 트랜잭션이 있으면 언두 로그가 미친 듯이 스택처럼 쌓여 서버 디스크 공간을 압박할 수 있습니다.
- PostgreSQL: Append-Only (튜플 복사본) 방식
PostgreSQL은 원본 데이터를 건드리지 않습니다. 데이터를 수정(Update)하면 기존 줄(튜플)을 ‘죽은 상태(Dead Tuple)’로 표시하고, 테이블 맨 아래에 새로운 데이터 줄을 통째로 추가해 버립니다.
- 장점: 언두 로그를 조율할 필요가 없어 구조가 단순하고 읽기 작업 속도가 쾌적합니다.
- 단점: 수정을 자주 하면 쓸모없는 옛날 데이터(Dead Tuple)가 테이블에 수없이 쌓입니다. 이 쓰레기 데이터들을 주기적으로 치워주는 VACUUM(청소) 작업이 필수적이며, 제대로 안 해주면 디스크 용량이 폭증하고 성능이 떨어지는 ‘테이블 부풀림(Bloat)’ 현상이 생깁니다.
2. 동시성 처리와 프로세스 아키텍처
트랜잭션이 몰릴 때 서버의 CPU와 메모리를 어떻게 다루는지도 두 DB의 중요한 차이점입니다.
- MySQL: 스레드(Thread) 기반 아키텍처
MySQL은 하나의 커다란 프로세스 안에서 클라이언트 요청이 올 때마다 가벼운 스레드(Thread)를 생성해서 처리합니다.
스레드 방식은 메모리를 공유하기 때문에 접속자 수(Connection)가 갑자기 늘어나도 오버헤드가 적고 서버 메모리 자원을 아주 알뜰하게 사용합니다. 중소규모 서비스나 일반적인 웹 애플리케이션에 적합합니다. - PostgreSQL: 프로세스(Process) 기반 아키텍처
PostgreSQL은 요청이 올 때마다 독립된 별도의 프로세스(Process)를 하나씩 띄웁니다.
프로세스끼리는 독립된 메모리 공간을 쓰기 때문에 한 요청이 뻗어도 전체 DB가 죽지 않는 안정성이 장점입니다. 다만 클라이언트 접속이 수천 개로 폭증하면 메모리 소모가 극심해지므로, 실무에서는 커넥션 풀러(PgBouncer 같은 도구)를 앞에 붙여서 사용하는 것이 반강제됩니다.
3. 인덱스 구조와 메모리 사용량 분석
데이터 검색 성능을 좌우하는 인덱스 구조에서도 메모리 효율 차이가 발생합니다.
- MySQL의 클러스터드 인덱스 (Clustered Index)
MySQL은 기본키(PK)를 기준으로 데이터 자체가 B-Tree 구조로 정렬되어 저장됩니다. 세컨더리 인덱스(보조 인덱스)들은 실제 데이터 위치가 아니라 기본키(PK) 값만을 가리킵니다.
따라서 인덱스가 차지하는 메모리 용량이 상대적으로 작고, PK 기반 조회 속도가 압도적으로 빠릅니다. - PostgreSQL의 힙 페이지(Heap Page)와 HOT 기술
PostgreSQL은 테이블 데이터를 순서 없이 ‘힙(Heap)’이라는 공간에 차곡차곡 던져두고, 모든 인덱스가 데이터의 실제 물리적 위치(TID)를 가리킵니다.
인덱스 개수가 많아질수록 메모리를 더 많이 먹는 경향이 있습니다. 다만 수정을 할 때 인덱스를 매번 갱신하지 않고 힙 페이지 내에서 해결하는 HOT(Heap-Only Tuple) 기법이나, JSONB 등 복잡한 데이터 구조를 처리하는 GIN/GiST 같은 강력한 특수 인덱스들을 기본 제공합니다.
4. 그래서 내 프로젝트에는 뭘 골라야 할까?
- MySQL을 추천하는 경우:
- 단순 읽기/쓰기(CRUD) 비중이 높고 트랜잭션이 빈번한 일반적인 웹 서비스
- 서버 자원(RAM)이 한정되어 있어 메모리를 효율적으로 아껴야 하는 환경
- 복잡한 연산보다는 빠른 응답 속도가 최우선인 쇼핑몰, 게시판 등
- PostgreSQL을 추천하는 경우:
- 금융, 결제, 물류 시스템처럼 복잡한 트랜잭션 처리와 엄격한 데이터 완전성이 필요한 경우
- 위치 기반 서비스(PostGIS), JSON 비정형 데이터 분석, 대용량 데이터 복합 쿼리를 자주 실행하는 경우
- 데이터베이스 레벨에서 높은 정교함과 확장성을 챙기고 싶은 경우
두 DB 모두 세계 최고 수준으로 발전해 왔기 때문에 소규모 서비스에서는 둘 중 무엇을 써도 훌륭합니다. 하지만 서비스 규모가 커질수록 이 같은 아키텍처 특성이 서버 비용과 장애 대처 능력을 좌우하므로, 서비스의 데이터 성격을 명확히 파악한 뒤 신중하게 선택해 보시길 권해드립니다.