PostgreSQLベンチマーク：AWS RDS vs. Hetzner上のセルフホスト（2026年）

まず短い回答です。同じサイズ（2 vCPU / 4 GB、PostgreSQL 16）で、HostimはAWS RDS db.t4g.mediumの約2.5倍、Hetzner上のデフォルトのセルフホストPostgresの約2.1倍の書き込みスループットを達成しました。Hetznerは、生CPU速度において最も速い読み込み速度を示しました。RDSは両方で最も遅いかそれに近い結果となり、その表示価格は実際の請求額の最小部分に過ぎません。この記事では、すべての数値、再現するための正確なコマンド、そして（結論を変えるため）高可用性が各プラットフォームで実際にいくらかかるかを示します。ベンチマークは2026年7月にPostgreSQL 16で、中央ヨーロッパ地域で実行されました。価格は頻繁に変更されるため、コミットする前に各プロバイダーのライブ価格ページを確認してください。結果の形状は、正確な数値よりもはるかに変化しません。 比較したもの 中央ヨーロッパ地域で、すべて2 vCPU / 4 GB RAM、PostgreSQL 16で、小規模な本番環境Postgresを実行する3つの方法を比較しました。 提供サービス | インスタンス | 月額表示価格 | レプリケーション（フェイルオーバー）あり？ ---|---|---|--- Hostim マネージドPostgres | drp-50 (2 vCPU / 4 GB) | €50 | はい、デフォルトで AWS RDS | db.t4g.medium (2 vCPU / 4 GB) | ~$48 (インスタンスのみ) | いいえ（シングルAZ） セルフホスト | Hetzner CPX22 (2 vCPU AMD / 4 GB, 共有) | €19.49 | いいえ（シングルノード） 「レプリケーション」列は、価格とパフォーマンスの両方で非常に重要です。これは後で独自のセクションで扱います。 方法論 目標は、公平なテストであり、有利なものではないことでした。ルールは以下の通りです。 * 同じDBサイズ：すべてのターゲットで2 vCPU / 4 GB。 * 同じPostgresメジャーバージョン：16。 * 各ターゲットごとに個別のロードジェネレーターを使用し、データベースからネットワークホップ1つ分離れた同じリージョンに配置し、データベースボックス上には配置しない。 * 各クライアントは4 vCPUを持ち、クライアントがボトルネックにならないようにした（mpstatで確認済み）。 * 同じワークロード：pgbench、スケールファクター50（約750 MB、RAMに収まるため、テストはCPUとコミットパスを測定し、コールドディスク読み取りは測定しない）、実行時間300秒。 クライアント設定： sudo apt-get install -y postgresql-contrib nmap sysstat # pgbench + nping pgbench --version 各データベースに対して同一に実行されたワークロード： # 初期化（約750 MB） pgbench -i -s 50 # 書き込み負荷が高い、TPC-Bライク、4クライアント、5分間 pgbench -c 4 -j 4 -T 300 # 読み取り専用、8クライアント、5分間 pgbench -c 8 -j 4 -T 300 -S # シングル接続、書き込み、1分間（コミット/fsyncレイテンシを分離） pgbench -c 1 -T 60 ネットワークレイテンシは、ポート5432へのTCP ping（nping --tcp -p 5432）とSELECT 1ラウンドトリップで測定しました。これは、ICMPがすべてのプラットフォームで開いているわけではないためです。 設定の整合性、明確に記載：セルフホストのHetznerノードは、標準のPostgresデフォルト（shared_buffers 128 MB、チューニングなし）で実行されました。これは、現実的な「Postgresをインストールしてすぐに使う」ベースラインです。RDSはAWSがインスタンスサイズに合わせてチューニングしたデフォルトのパラメータグループで実行されました。Hostimは独自のマネージドチューニングを実行しています。つまり、2つのマネージドオプションは箱から出してすぐにチューニングされており、セルフホストのデフォルトはそうではない、という違いが比較対象の一部となります。 結果 すべての実行は、トランザクション失敗ゼロで完了しました。 書き込みスループット（4クライアント、TPC-B） ターゲット | TPS | 平均レイテンシ ---|---|--- Hostim drp-50 | 2,708 | 1.48 ms Hetzner (デフォルト) | 1,303 | 3.07 ms AWS RDS t4g.medium | 1,080 | 3.71 ms Hostimは、RDSの約2.5倍、デフォルトのHetznerノードの約2.1倍の書き込みスループットを達成しました。 シングル接続書き込みレイテンシ（1クライアント） これはコミットパスを分離します。すべてのトランザクションはWALフラッシュ（デフォルトはsynchronous_commit = on）を待つため、主にストレージのfsyncレイテンシを測定します。 ターゲット | TPS | 平均レイテンシ ---|---|--- Hostim drp-50 | 871 | 1.15 ms AWS RDS t4g.medium | 416 | 2.41 ms Hetzner (デフォルト) | 276 | 3.63 ms セルフホストとRDSの両方で、コミットパス上のネットワーク接続ストレージブロックストレージに料金が発生します。これが書き込みスループットのギャップの最大の要因です。 読み込みスループット（8クライアント、SELECTのみ） ターゲット | TPS | 平均レイテンシ ---|---|--- Hetzner (デフォルト) | 20,068 | 0.40 ms Hostim drp-50 | 14,333 | 0.56 ms AWS RDS t4g.medium | 13,261 | 0.60 ms 読み込みはCPUに比例します。Hetznerボックスは、オーケストレーションレイヤーがパスにない生のコアあたりのAMD速度でこれを制しました。HostimとRDSは近く、RDSが最後でした。db.t4g.mediumはバースト可能なインスタンスであり、300秒の持続的な実行ではCPUクレジットのベースラインに低下する可能性があることに注意してください。これは~$48ティアが提供するように設計されているものです。持続的なCPUを必要とするワークロードは、mクラスのRDSインスタンスに移行しますが、これは約2倍のコストがかかります。 ネットワークレイテンシ ターゲット | TCP RTT (平均) | SELECT 1 ---|---|--- Hostim drp-50 | 0.48 ms | ~0.29 ms Hetzner (デフォルト) | 0.71 ms | ~0.39 ms AWS RDS t4g.medium | 1.50 ms | ~0.58 ms 実際に支払う価格 ここで表示されている数値は役に立たなくなります。 AWS RDS: $48は請求額ではありません ~$48はインスタンスのみ、シングルAZ、オンデマンドです。それに加えて、別途課金されます。 * ストレージ：gp3はGB月額で請求されます。gp3のベースラインを超えるIOPSとスループット：プロビジョニングした場合に請求されます。 * バックアップ：ボリュームサイズを超える保持バックアップストレージは請求されます。 * データ転送：エグレスおよびクロスAZトラフィックはGBあたりで請求されます。 1つのストレージドロップダウンがこれを具体的にします。データベース作成ウィザードでプロビジョンドIOPS SSDを選択すると、RDSはデフォルトで月額約$300（io1 ≈ $0.10/IOPS、io2 ≈ $0.125/IOPS）で3000プロビジョンドIOPSになり、これはインスタンスとGBストレージに加えて請求されます。gp3のデフォルトには、400 GBまで無料の同じ3000 IOPSと125 MB/sが含まれているため、そこでは費用はかかりません。同じデータベースで、1つのドロップダウンから月額約$300の差が出ます。控えめなボリュームと通常のトラフィックを持つ現実的なシングルAZ db.t4g.mediumは、ストレージ、IOPS、バックアップ、エグレスを考慮すると、ステッカー価格を大幅に上回ります。正確な金額は月ごとに変動します。 $48をフロアとして扱い、価格としては扱わないでください。（この従量課金パターンの詳細は、Cloud Rent in ActionおよびUsage-Based Pricingで説明しています。） 高可用性が比較を変える 上記の С結果は、レジリエンスにおいては直接比較できるものではなく、これが重要な部分です。Hostim drp-50はデフォルトでレプリケーションされています。€50にはスタンバイと自動フェイルオーバーが含まれています。設定は不要です。AWS RDSは、スタンバイとフェイルオーバーのためにMulti-AZが必要です。Multi-AZはセカンドインスタンスを実行し、インスタンスとストレージのコストをほぼ倍増させます。また、コミットが同期スタンバイを待つため、書き込みが遅くなります。したがって、公平なHA対HAの比較では、RDSの書き込みは上記のシングルAZの数値よりも低くなります。 セルフホストのHetznerは、1ノードではフェイルオーバーが全くありません。Hostimに合わせるには、セカンドVPS（さらに€20）を追加し、レプリケーションとフェイルオーバー（ストリーミングレプリケーションとPatroniやrepmgrのようなツール、およびルーティングレイヤー）を自分で構築・運用する必要があります。そして、すべてのインシデントの責任を負います。 「自動フェイルオーバー付きレプリケーションされたPostgres」に正規化すると： 提供サービス | HAの月額概算費用 | 追加作業 ---|---|--- Hostim drp-50 | €50、含まれる | なし AWS RDS Multi-AZ | インスタンス＋ストレージの約2倍、加えてエグレスとバックアップ | なし、ただし書き込みは遅くなる Hetzner, 2ノード | ハードウェア約€40 | フェイルオーバーを自分で構築・実行する したがって、€50のHostimの数値には、AWSの価格を倍増させ、Hetznerオプションを運用プロジェクトに変えるものがすでに含まれています。 注意点 * db.t4g.mediumはバースト可能なARMであり、持続的な実行ではCPUクレジットのベースラインに達する可能性があります。これは価格マッチングされたティアの動作であり、設定ミスではありません。 * セルフホストノードは意図的に標準のPostgresデフォルトを使用しました。shared_buffersなどをチューニングすると数値は向上しますが、セルフホストの場合はそのチューニングはあなたの仕事です。 * RDSは生のベンチマークではシングルAZでした。Multi-AZは前述の通り、より遅く、より高価です。 * データセットはRAMに収まりました（スケール50）。これはコンピューティングを分離します。RAMを超えるデータセットは、ストレージへの負荷を増やし、書き込みのギャップを広げることはあっても、縮めることはありません。 * アーキテクチャは異なります（RDSはARM Graviton、他はx86）。これは各プロバイダーがこの価格で販売しているものであり、そのまま報告されています。 結論 * このサイズの書き込み負荷の高いワークロードでは、Hostimがストレージfsyncレイテンシがコミットパスで主な要因となり、明確なマージンで最速でした。 * 読み込み負荷の高いワークロードでは、チューニングと運用を行う意思があれば、セルフホストボックスが生のコアあたりのCPUエッジを持っていました。 * 価格マッチングされたティアのAWS RDSは、両方で最も遅いかそれに近い結果となり、その実際のコスト（ストレージ、IOPS、エグレス、およびフェイルオーバーのためのMulti-AZ）は、表示されたインスタンス価格の数倍になります。 * 自分で運用せずにレプリケーションされたPostgresを望む場合、HAが含まれたフラットな価格がその数値です。