Show HN: 23가지 EC2 인스턴스 유형별 PostgreSQL 성능 및 비용

• 벤치마크와 비용 효율 인스턴스 탐색

  • 여러 조건에서 PostgreSQL을 벤치마크함

    • EC2 인스턴스 여러 종류

    • 디스크 여러 구성

    • 서로 다른 초기 데이터셋

    • 각 인스턴스의 성능 확인

  • 벤치마크 데이터를 시각화하는 도구

  • 평소 필요한 입력값을 넣으면 요구사항에 맞는 비용 효율적 인스턴스 탐색 가능함

    • 입력 예시: 필요한 RPS, 디스크 크기

  • 방법론: https://postgres.saneengineer.com/about

• 현재 테스트 범위와 확장 구조

  • 현재는 한 가지 워크로드와 일부 선택된 구성만 테스트됨

    • 워크로드: 읽기/쓰기 90/10 혼합

  • 구조는 확장 가능하며 벤치마크는 오픈소스로 공개됨

    • 더 많은 구성을 실행해 데이터 추가 반영 가능함

    • 저장소: https://github.com/anivaniuk/sanebench

• AWS PostgreSQL 서버 크기 산정 방식

  • 데이터 크기와 필요한 처리량을 선택하는 방식임

  • 각 점은 벤치마크된 인스턴스 × 디스크 조합을 의미함

  • 목표선 오른쪽 조합은 요구사항을 충족함

    • 요구사항 충족 조합 중 가장 저렴한 조합이 추천 선택지임

^{source https://postgres.saneengineer.com/}

HN에서는 이 벤치마크를 인스턴스별 순위표로만 보지 않았다. PostgreSQL 성능을 비교하려면 vCPU 수, 실제 코어 구성, SMT 방식, 스토리지 조건까지 함께 맞춰야 한다는 문제의식이 더 강했다. ARM에서는 vCPU가 물리 코어에 가깝게 해석될 수 있지만, Intel·AMD 계열에서는 스레드 단위로 보일 수 있다. 최근 AMD 인스턴스처럼 SMT 설정이 다른 세대가 빠져 있으면 같은 vCPU 숫자라도 결과를 그대로 비교하기 어렵다.

스토리지 조건도 중요한 변수로 다뤄졌다. 한 사용자는 Azure에서 비슷한 실험을 했을 때 최대 IOPS보다 디스크 지연 시간이 훨씬 크게 작용했다고 설명했다. io2, huge pages 같은 조건을 별도로 보고 싶다는 요구가 나온 이유도 여기에 있다. 작성자는 EC2에서 직접 운영한 PostgreSQL 기본값과 RDS 기본값이 다르며, huge pages 설정 차이도 방법론에 반영하겠다고 답했다.

관리형 서비스와의 비교를 원하는 반응도 이어졌다. Aurora PostgreSQL이나 RDS를 같은 조건에서 비교해야 실제 선택에 더 도움이 된다는 취지다. 읽기 중심이고 데이터셋이 메모리보다 큰 경우에는 로컬 NVMe 기반 캐시를 쓰는 Optimized Reads 인스턴스가 큰 이점을 줄 수 있다는 경험도 공유됐다. 다만 이번 실험은 RDS가 아니라 EC2 직접 운영을 대상으로 했기 때문에, 관리 비용과 서비스 기능까지 포함한 평가는 아직 남아 있다.

따라서 이 결과는 출발점으로 유용하지만, 그대로 인프라 선택의 결론으로 삼기에는 부족하다. 팀은 읽기와 쓰기의 비중, 데이터셋 크기, 디스크 지연 시간, CPU 세대별 특성, 직접 운영과 RDS 비용의 차이를 함께 확인해야 한다. 같은 PostgreSQL이라도 병목과 운영 모델이 다르면 더 싼 선택과 더 빠른 선택이 달라질 수 있다.