PostgreSQL의 MVCC(다중 버전 동시성 제어) 구현 방식이 쓰기 증폭, 테이블 팽창(bloat), VACUUM(진공 청소) 부담, 그리고 32비트 XID(트랜잭션 ID) 랩어라운드(wraparound) 문제로 종종 비판받아왔습니다. 하지만 최근 보링SQL(boringsql.com)의 분석에 따르면, 이러한 문제들은 MVCC 자체의 결함이라기보다는 과거 데이터를 테이블 내부에 남기고 나중에 정리하는 PostgreSQL의 특정 설계 선택에서 비롯된 것이라고 합니다. 리더가 라이터 작업을 방해하지 않으려면 모든 데이터베이스는 과거 버전의 데이터를 어딘가에 보관해야 하며, 그 방식의 차이일 뿐 MVCC의 비용은 본질적으로 사라지지 않는다는 설명입니다.
PostgreSQL의 UPDATE 작업은 기존 행을 직접 수정하는 대신, 새로운 행 버전을 힙(heap)에 추가하고 이전 버전에는 t_xmax를 기록하여 두 버전을 모두 디스크에 남깁니다. 어떤 버전이 보이는지는 읽기 시점에 판단하며, 더 이상 필요 없는 버전은 나중에 VACUUM 프로세스가 정리합니다. 이러한 방식은 인덱스가 물리적 행 위치(ctid)를 가리키므로, 인덱스되지 않은 컬럼이 변경되어도 새 행 버전을 위한 인덱스 엔트리가 필요할 수 있어 쓰기 증폭을 유발합니다. 또한, UPDATE는 사실상 INSERT와 지연된 DELETE와 같아 테이블 팽창을 일으키고, 오래 열린 트랜잭션은 VACUUM이 과거 튜플을 제거하는 것을 막아 데이터베이스 전체의 XID 가시성(xmin horizon)을 뒤로 밀어낼 수 있습니다. 32비트 XID는 약 40억 개의 트랜잭션 후 랩어라운드 문제를 일으켜 주기적인 튜플 프리징(freezing)이 필요합니다.
반면 오라클(Oracle)과 MySQL의 InnoDB는 과거 버전을 테이블 외부의 언두 로그(undo log)에 저장합니다. 이 방식은 테이블에 최신 행만 남겨 힙 팽창을 피하고, 세컨더리 인덱스가 프라이머리 키를 가리키므로 인덱스 업데이트 비용이 적습니다. SQL Server는 READ_COMMITTED_SNAPSHOT이나 SNAPSHOT 옵션을 켜면 임시 데이터베이스(tempdb)의 버전 스토어(version store)에 과거 버전을 저장하며, 몽고DB(MongoDB)의 WiredTiger는 주로 메모리 내 델타 체인(delta chain)으로 과거 버전을 관리합니다. 이들 시스템은 PostgreSQL의 문제를 피하는 대신, 롤백 비용 증가, 과거 버전 읽기 비용 증가, '스냅샷 투 올드(snapshot too old)' 오류, 임시 데이터베이스 팽창, 캐시 압력 증가 등 다른 형태의 비용을 지불합니다.
결론적으로 MVCC의 비용은 사라지지 않고 다른 곳으로 이동할 뿐입니다. PostgreSQL은 가비지(garbage)가 눈에 보이고 VACUUM을 직접 관리해야 하는 대신, 리더를 막지 않고 오래된 스냅샷을 기본적으로 취소하지 않으며, 큰 트랜잭션도 거의 즉시 롤백할 수 있는 장점을 선택했습니다. 각 데이터베이스 시스템은 특정 워크로드와 운영 철학에 맞춰 MVCC 구현 방식을 선택하며, 이는 운영자가 각 시스템의 특성을 이해하고 적절히 관리해야 하는 이유를 보여줍니다. 특정 시스템이 '나쁘다'기보다는, 각자의 설계 트레이드오프(trade-off)를 이해하는 것이 중요합니다.