#VACUUM
2개의 포스트
Postgres는 느리지 않다, 느린 건 저장장치다 — 37ms 영수증으로 읽는 데이터베이스와 디스크의 50년
2026년 8월 ClickHouse가 공개한 발표 요약 「Postgres는 느리지 않다, 느린 건 저장장치다」가 10월 해커뉴스에서 174점·댓글 185개를 받으며 다시 불붙었습니다. 같은 기계, 같은 Postgres, 같은 쿼리에서 저장장치만 네트워크 디스크(EBS gp3)에서 서버에 꽂힌 NVMe로 바꿨더니 처리량이 9.24배가 됐다는 실험입니다. 이 글은 그 37ms짜리 지연 영수증을 항목별로 뜯어보고, CPU가 왜 놀고 있었는지, 3,000 IOPS가 어떻게 정확히 1,734 TPS가 되는지 리틀의 법칙으로 계산합니다. UPDATE 한 줄이 Postgres 안에서 지나가는 아홉 정거장(B-트리, MVCC, WAL, fsync, 체크포인트, 논리 복제)을 따라가고, 하드디스크와 5분 규칙에서 EBS, Aurora, 다시 로컬 NVMe로 돌아오기까지 50년의 역사를 논문으로 짚습니다. 'gp3 기본값은 허수아비'라는 반론과 판매 맥락까지 공정하게 다루고, 디스크가 사라지는 세계에서 데이터를 지키는 운영 구조를 장애 훈련으로 확인한 뒤, 2026년 내 데이터베이스를 진단하는 체크리스트로 끝냅니다. 인터랙티브 6개와 삽화 9장.
Postgres 하나로 어디까지 ① 작업 큐 — SKIP LOCKED로 Redis·RabbitMQ 없이 시작하기
메일 발송·썸네일 생성·외부 API 호출처럼 '나중에 해도 되는 일'을 맡길 큐가 필요할 때, Redis나 RabbitMQ를 새로 띄우기 전에 이미 쓰고 있는 PostgreSQL로 충분한지 따져 봅니다. 큐 테이블 하나와 쿼리 세 개로 시작해 SKIP LOCKED로 여러 워커가 겹치지 않게 일을 나누고, 리스(lease)로 죽은 워커의 일을 되살리고, 재시도·백오프·데드레터를 붙이고, LISTEN/NOTIFY로 즉시 깨우는 법까지. 큐 테이블이 부푸는 MVCC의 함정과 파티션으로 피하는 법, 언어별 라이브러리, 그리고 언제 전용 브로커로 떠나야 하는지도 다룹니다. 데모 두 개는 여러분의 브라우저 안에서 진짜 PostgreSQL 18을 띄워 실행됩니다.