最終更新日 2025年02月26日(水)

Heroku Postgres​ には、個人的なブログから大きなデータセット、高トランザクションアプリケーションまでの各種サイズのユースケースを処理するためのさまざまなプランが用意されています。適切なプランの選択は、そのアプリの固有の使用特性 (可用性や稼働時間に対する要件など) によって異なります。

プランの層

Heroku Postgres の多くのプラン​は、 次の 5 つの高レベルの層​に分類されます。各層の主な違いは、その層で許容されるデータベースの毎月のダウンタイムの量です。5 つの層は次のとおりです。

• Essential 層​ — 1 か月あたり最大 4 時間のダウンタイムを許容できるアプリ向け
• Standard 層​ — 1 か月あたり最大 1 時間のダウンタイムを許容できるアプリ向け
• Premium 層​ — 1 か月あたり最大 15 分のダウンタイムを許容できるアプリ向け
• Private 層​ - 検証済み​の Heroku Teams​ および Heroku Enterprise​ のお客様向け
• Shield 層​ - 検証済み​の Heroku Teams​ およびコンプライアンスに対応したデータベースを必要とする Heroku Enterprise​ のお客様向け

各層の違いの内訳を次に示します。

共有される機能

Heroku Postgres プランのすべての層で次の機能が共有されます。

• 自動ヘルスチェックによって完全に管理されたデータベースサービス
• 60 秒ごとのログ先行書き込み (WAL) オフプレミスストレージ (重大な障害が発生した場合のデータ損失が最小限に抑えられる)
• PG バックアップ​を使用した日次論理データベースバックアップ (無料のオプション)
• データクリップ​ (データやクエリの簡単かつ安全な共有のため)
• SSL で保護された psql/libpq アクセス
• 変更されていない PostgreSQL 14、15、16 の実行
• Postgres 拡張機能
• フル機能を備えた Web UI
• ディスクに書き込まれたすべてのデータを自動で保存時暗号化

Essential 層

Essential 層には essential-0​、essential-1​、essential-2​ のプラン​が含まれています。この層には以下の制限があります。

• フォーク/フォロー​のサポートなし: レプリカデータベースやリーダー/フォロワー設定を作成するために使用されるフォークとフォローはサポートされません。
• 高コストのクエリ​のサポートなし
• 月ごとに 99.5% の予測される稼働時間
• 予告なしのメンテナンスおよび Postgres バージョンの自動アップグレード
• Postgres ログなし
• 追加の資格情報なし

Essential 層​の各プランは次のとおりです。

プランの制限の適用

プランの制限は次のメカニズムで適用されます。

1. Essential データベースが使用制限の 90% に達すると、所有者に警告メールが送信されます。
2. データベースがプランの制限を超えると、所有者に追加の通知が送信されます。この時点で、データベースには制限に準拠するか別のプランに移行する​ための 7 日間の猶予期間が与えられます。データベースがプラン上限の 200% を超えた場合は、猶予期間をスキップし、直ちにアクセスが取り消されます。
3. 7 日後にもデータベースがプランの制限を超過しているか、プランの制限の 200% を超えている場合、INSERT と UPDATE の権限を取り消し、データベースへの接続数を 1 に制限します。データベースのデータの読み取り、更新、削除は引き続き実行できるため、データベースを準拠状態になるようにして、データへのアクセスを維持できます。
4. さらに 7 日経過してもデータベースが依然としてプランの制限に違反している場合は、データベースへのアクセスが取り消されます。データベースへのアクセスを回復するためには、所有者はサポートチケット​を作成する必要があります​。
5. 使用量がプランの制限に準拠するようになると、データベースの権限と接続が自動的に復元されます。権限の復元には時間がかかることがあります。
6. サポートチケットでの連絡がなく、使用量がプランの制限を超えている状態が続く場合は、ポリシー​に準拠していないことを根拠にデータベースに削除のフラグが付けられます。

Standard 層

Standard 層は、1 か月あたり最大 1 時間のダウンタイムを許容するアプリケーション向けに設計されています。すべての Standard 層データベースには、以下のものが含まれます。

• 行数制限なし
• インメモリキャッシュの段階的な拡張
• フォークとフォロー​のサポート
• 最大 4 日間のロールバック​
• データベースメトリクス​をさらに分析するためのアプリケーションログストリームへの公開
• 中断時の優先サービスの復元
• 資格情報管理

Standard 層​の各プランは次のとおりです。

Premium 層

Premium 層は、1 か月あたり最大 15 分のダウンタイムを許容するアプリケーション向けに設計されています。すべての Premium 層データベースには、以下のものが含まれます。

• 行数制限なし
• インメモリキャッシュの段階的な拡張
• フォークとフォロー​のサポート
• 最大 7 日間のロールバック​
• データベースメトリクス​をさらに分析するためのアプリケーションログストリームへの公開
• 中断時の優先サービスの復元
• 資格情報管理
• 高可用性

Premium 層​の各プランは次のとおりです。

Private および Shield 層

Heroku は、検証済み​の Heroku Teams​ および Heroku Enterprise​ のお客様に Private Spaces​ 内の Heroku Postgres を提供します。さらに、コンプライアンスに対応したデータベースが必要なお客様は Postgres Shield プランをご使用いただけます。Private および Shield プランについての詳細は、Heroku Postgres および Private Spaces​ の記事を参照してください。

キャッシュサイズ

Essential 層でないデータベース​の場合、RAM サイズは、基礎となるインスタンスのハードウェア上のシステムメモリの合計量を示します。このほとんどは、Postgres に割り当てられ、キャッシングに使用されます。少量の RAM は接続やその他のタスクの管理に使用されますが、Postgres では、この RAM のほぼすべてがそのキャッシュのために利用されます。キャッシュの詳細な機能については、この記事​を参照してください。

Postgres は、書き込まれた行、作成されたインデックス、Postgres が保持しているメタデータなどのデータのキャッシュを常に管理しています。クエリに必要なデータがキャッシュ内に完全に含まれている場合、パフォーマンスは高速です。キャッシュされたデータから作成されたクエリは多くの場合、完全なデータセットから作成されたクエリに比べて 100 ～ 1000 倍高速です。

逆に、ディスクへのフォールバックが必要になると、少なくとも 1 桁低速になります。さらに、大きなデータ型 (大きなテキスト列など) を含む列は TOAST​ を使用して行の外で保存されるため、TOAST 化された大量のデータへのアクセスは低速になる場合があります。

一般的なガイドライン

アクセスパターンは、アプリケーションごとに大きく異なります。多くのアプリケーションは、そのデータ全体の中の小さな、最近変更された部分にのみアクセスします。Postgres は、時間が経過しても常にその部分をキャッシュ内に保持できるため、これらのアプリケーションは小さめのプランでは適切に実行できます。

すべての​データに頻繁にアクセスするアプリケーションにこの好条件はありません。これらのアプリでは、そのデータセット全体が確実にメモリに収まるようにすることにより、パフォーマンスを大幅に向上させることができます。データセットの合計サイズを確認するには、heroku pg:info​ コマンドを使用し、Data Size​ 行を探します。

$ heroku pg:info
=== HEROKU_POSTGRESQL_CHARCOAL_URL (DATABASE_URL)
Plan:        Standard 0
Status:      Available
Data Size:   9.4 MB
...

大まかな尺度ではありますが、合計のデータセットのサイズと少なくとも同じ量のインメモリキャッシュを使用できるプランを選択すると、高いキャッシュ比率が確保されます。ただし、最終的には最大のプランよりデータ量が多くなるポイントに達するため、シャードすることが必要になります。シャーディングを前もって計画してください。シャーディング方式の実行には長い時間がかかります。

必要なキャッシュサイズの特定

適切なキャッシュサイズを特定するには、本番稼働トラフィックでのアプリケーションのデータベース要求を観察することが最適です。理想的には、キャッシュヒット率は 99% 以上の範囲に入ります。一般的でないクエリには 100 ミリ秒未満が、一般的なクエリには 10 ミリ秒未満が必要です。

テーブルのキャッシュヒット率を測定するには、次のようにします。

SELECT
    'cache hit rate' AS name,
     sum(heap_blks_hit) / (sum(heap_blks_hit) + sum(heap_blks_read)) AS ratio
FROM pg_statio_user_tables;

インデックスのキャッシュヒット率の場合は、次のようにします。

SELECT
    'index hit rate' AS name,
    (sum(idx_blks_hit)) / sum(idx_blks_hit + idx_blks_read) AS ratio
FROM pg_statio_user_indexes

どちらのクエリも 0.99​ に近い ratio​ を示します。

heap_read | heap_hit |         ratio
-----------+----------+------------------------
       171 |   503551 | 0.99966041175571094090

キャッシュヒット率が低下し始めたら、一般には、データベースのアップグレードによりこの比率が 99% に戻ります。

Heroku Postgres プランの変更

データベースのプランは作成後に変更できます。プランを変更するオプションの詳細については、こちら​を参照してください。