PostgreSQL의 MVCC는 나쁘다. 다른 DB도 마찬가지다

(news.hada.io)

GeekNews2026년 8월 10일개발자 도구

PostgreSQL의 MVCC 설계가 초기 성능 저하를 일으키는 것은 기술적 결함이라기보다 비용을 어디에 지불할 것인가에 대한 설계적 선택의 문제이며, 이는 다른 데이터베이스들도 각기 다른 형태로 동일한 비용을 치르고 있다는 점이 핵심입니다.

이 글의 핵심 포인트

1PostgreSQL의 MVCC는 과거 버전을 테이블 내부에 남겨 쓰기 증폭과 테이블 팽창(Bloat) 문제를 발생시킴
2다른 DB(Oracle, InnoDB 등)도 비용을 제거하는 것이 아니라 Undo 로그나 버전 스토어 등 다른 영역으로 이동시킨 것임
3PostgreSQL은 읽기 작업이 쓰기를 막지 않고 큰 트랜잭션의 즉각적인 롤백이 가능하다는 이점을 위해 VACUUM 관리라는 비용을 선택함
4InnoDB 방식은 테이블 팽창을 줄일 수 있지만, 대신 롤백 시간 증가와 오래된 스냅샷 읽기 시의 성능 저하(Read amplification)를 초래함
5PostgreSQL의 HOT(Heap-Only Tuple) 업데이트 기능을 활용하면 적절한 fillfactor 설정을 통해 인덱스 업데이트 비용을 절감할 수 있음

이 글에 대한 공공지능 분석

왜 중요한가?

데이터베이스 성능 최적화는 단순히 '좋은 엔진'을 찾는 과정이 아니라, 서비스 워크로드에 가장 적합한 '비용 구조'를 선택하는 전략적 의사결정임을 시사하기 때문입니다. 인프라 비용과 운영 복잡도 사이의 트레이드오프를 이해하는 것은 대규모 트래픽을 다루는 엔지니어에게 필수적인 역량입니다.

어떤 배경과 맥락이 있나?

MVCC(Multi-Version Concurrency Control)는 데이터 일관성을 유지하면서 읽기와 쓰기가 서로를 방해하지 않게 하는 핵심 기술입니다. PostgreSQL은 과거 버전을 테이블(Heap) 내부에 저장하는 방식을, Oracle이나 MySQL InnoDB는 별도의 Undo 로그에 저장하는 방식을 채택하며 각기 다른 성능적 특징과 관리 포인트를 가집니다.

업계에 어떤 영향을 주나?

서비스 규모가 커짐에 따라 발생하는 쓰기 증폭(Write Amplification)이나 테이블 팽창(Bloat) 문제는 단순한 쿼리 최적화를 넘어 DB 엔진의 설계 철학에 따른 대응을 요구합니다. 이는 Uber와 같은 글로벌 기업들이 특정 워크로드에서 왜 데이터베이스 교체를 심각하게 고려하는지에 대한 기술적 근거를 제공합니다.

한국 시장에 어떤 시사점이 있나?

많은 한국 스타트업이 PostgreSQL을 기본 스택으로 사용하고 있으나, 트래픽 급증 시 발생하는 VACUUM 부하나 팽창 문제를 단순한 '버그'가 아닌 '설계된 비용'으로 인식해야 합니다. 따라서 서비스 특성에 맞춰 fillfactor 조절이나 적절한 인프라 설계 등 선제적인 운영 전략을 수립하는 것이 중요합니다.

이 글에 대한 큐레이터 의견

PostgreSQL의 MVCC 이슈를 단순한 기술적 결함으로 치부하는 것은 위험합니다. 이 글은 데이터베이스 엔지니어링이 결국 '어디에서 비용을 지불할 것인가'에 대한 결정론적 문제임을 명확히 보여줍니다. PostgreSQL은 운영자의 관리 부담(VACUUM)을 대가로 읽기 성능의 안정성과 큰 트랜잭션의 즉각적인 롤백이라는 강력한 이점을 얻었습니다.

스타트업 창업자나 CTO 관점에서는 서비스의 성격이 '쓰기 중심'인지 '읽기 중심'인지를 먼저 파악해야 합니다. 만약 업데이트가 빈번하고 인덱스가 많은 워크로드라면 PostgreSQL의 쓰기 증폭 문제는 운영 비용(인프라 및 엔지니어링 공수)을 급격히 상승시킬 수 있는 위협 요소입니다. 반면, 데이터 정합성이 중요하고 읽기 패턴이 복잡한 서비스라면 PostgreSQL의 설계는 매우 합리적인 선택지가 됩니다.

다만, '모든 DB가 마찬가지'라는 결론에 안주해서는 안 됩니다. 비용이 이동했을 뿐 사라진 것이 아니기에, InnoDB의 Undo 로그 증가나 Oracle의 Snapshot too old 오류 역시 서비스 가용성을 해칠 수 있는 잠재적 리스크입니다. 따라서 기술 스택 결정 시 특정 엔진의 장점뿐만 아니라, 우리 서비스가 감당할 수 있는 '비용의 형태'가 무엇인지 냉철하게 판단해야 합니다.

원문 보기 →