AI 요약
Postgres에서 대규모 데이터를 삭제하기 위해 일반적인 DELETE 명령을 사용하는 것은 데이터베이스의 쓰기 작업량과 복제 부하를 증가시켜 오히려 성능을 저하시킵니다. 이는 Postgres의 핵심 설계 원칙인 다중 버전 동시성 제어(MVCC) 때문으로, 삭제된 행을 '데드 튜플(dead tuples)'로 보존하고 오토진공(Autovacuum)을 통해서만 재사용 가능하게 만들기 때문에 물리적 디스크 공간이 운영체제(OS)로 즉시 반환되지 않습니다. 또한 인덱스 영역에서도 삭제된 행의 유효성을 읽기 작업 시 검증해야 하므로 전반적인 조회 속도가 느려집니다. 반면, DROP TABLE과 TRUNCATE는 비록 테이블에 무거운 AccessExclusiveLock 잠금을 걸지만, 데이터 크기에 무관하게 물리 파일 자체를 OS에서 즉시 제거하므로 가장 확실하고 확장성 있는 데이터 삭제 방법이 됩니다.
핵심 인사이트
- 게시일 및 저자: 2026년 6월 11일, PlanetScale의 톰 팡(Tom Pang)이 작성한 분석 아티클입니다.
- MVCC의 설계적 한계: Postgres는 일관성 제공을 위해 삭제되거나 수정된 행을 즉시 지우지 않고 물리 페이지 내에 남겨두어 쓰기 및 복제 부하를 가중시킵니다.
- 디스크 공간 미반환: 일반
DELETE실행 후 수행되는 진공(Vacuum) 프로세스는 공간을 OS에 반환하지 않으며, 이를 강제하는VACUUM FULL은 비용이 많이 드는 잠금을 유발합니다. - 유일한 확장성 대안:
DROP TABLE과TRUNCATE명령은 물리적 레이어에서 파일을 완전히 삭제하므로 대규모 데이터 삭제 작업에서 가장 뛰어난 성능을 발휘합니다.
주요 디테일
- 데드 튜플의 관리: Postgres는 트랜잭션 ID와 가시성 맵(Visibility map)을 사용해 쓰레기 데이터를 관리하며, 나중에 진공 프로세스가 해당 공간을 새로운 쓰기 작업(
INSERT)에 재사용할 수 있도록 표시하는 방식을 취합니다. - 복제 부하 가중: 대규모
DELETE역시 동일한 쓰기 트랜잭션이므로 동기 및 준동기 복제 아키텍처 환경에서는 다른 데이터 쓰기 쿼리가 복제 완료를 대기하도록 만들어 앱 전체 성능을 떨어뜨립니다. - 인덱스 스캔 영향: 행 삭제 시 인덱스 데이터는 즉시 지워지지 않으며, 인덱스 스캔을 수행하는 리더(Reader) 프로세스가 직접 데드 튜플 여부를 실시간으로 판단하는 비효율성이 존재합니다.
- CASCADE 옵션의 위험성: 외래 키(Foreign Key) 관계에서
CASCADE옵션과 단일 행 삭제를 결합하면 의도치 않게 수 기가바이트(GB)의 데이터를 삭제하는 동일한 성능 문제를 초래할 수 있습니다.
향후 전망
- 스키마 설계 패러다임 변화: 주기적인 대량 데이터 정리가 필요한 대규모 서비스 애플리케이션의 경우, 설계 단계부터 테이블 파티셔닝(Partitioning)을 도입하여 손쉽게
DROP TABLE이나TRUNCATE할 수 있도록 데이터 모델링을 유도하게 될 것입니다. - Postgres 관리 최적화: 불필요한 디스크 사용량 증가 및
VACUUM FULL로 인한 서비스 잠금 현상을 피하고자 성능 튜닝 가이드라인에서DELETE자제 권고안이 더욱 강화될 것으로 보입니다.
출처:hackernews