#Aurora
3개의 포스트
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장.
AWS RDS 완전 정복: 데이터베이스 관리라는 '야간 당직'에서 해방되는 법
새벽 3시에 DB 장애 알림을 받고 출근하던 시대에서, 백업·패치·복구·스케일링이 자동화된 시대로. RDS가 왜 탄생했고, 어떻게 DBA의 일상을 바꿨으며, Aurora는 왜 '재발명'이라 불리는지를 실전 사례와 함께 풀어본다.
Amazon Aurora 완전 정복: AWS가 관계형 데이터베이스를 '재발명'한 방법
MySQL의 5배, PostgreSQL의 3배 성능. 6개 복제본 자동 유지. 128TB 자동 확장. RDS의 편리함 위에 '클라우드 네이티브' 스토리지를 올린 Aurora — 왜 만들어졌고, 어떻게 다르며, 언제 써야 하는지를 SIGMOD 논문부터 실전 사례까지 풀어본다.