最終更新日 2024年05月31日(金)

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

プランの層

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

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

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

ダウンタイムの許容範囲は 30 日の月に基づいています。

共有される機能

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

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

• Postgres 拡張機能
• フル機能を備えた Web UI
• ディスクに書き込まれたすべてのデータを自動で保存時暗号化

Essential 層

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

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

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

Mini および Basic の非推奨の詳細

Heroku Postgres mini と Basic プランがサポート終了 (EOL) に達しました​。すべての mini データベースと Basic データベースの廃止と移行のスケジュールは次のとおりですが、今後変更される場合があります。

• 2024 年 5 月 29 日: ​mini​ と basic​ プランが EOL に達します。
  • mini​ および basic​ のデータベースを作成できません。既存の mini​ および basic​ のデータベースは引き続き使用できます。
  • mini​ プランを essential-0​ に、basic​ プランを essential-1​ に移行し始めます。移行の開始時と終了時にメール通知が送信されます。移行には約 15 分かかります。mini​ および basic​ のデータベースが PostgreSQL バージョン 12 または 13 を使用している場合、essential-*​ データベースへの移行によって、そのバージョンも 14 にアップグレードされます。
• 2024 年 7 月 31 日: データベースアクセスの制限を開始し、この日までに移行されていない mini​ および basic​ のデータベースを削除します。移行されていないデータベースがまだある場合は、メール通知が送信されます。

mini​ と basic​ データベースも addons:upgrade​ によって新規 Essential 層プランに移行できます。mini​ および basic​ データベースが PostgreSQL バージョン 12 または 13 を使用している場合、データベースへの移行によって、PostgreSQL のバージョンも 14 にアップグレードされます。

レビューアプリ​や CI アプリ​が app.json 内で mini​ または basic​ のデータベースを使用している場合、それらを新しい 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 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 プランの変更

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