PostgreSQLは専用vCPUのVPSでどれくらいのCPUとRAMを必要としますか？

PostgreSQLはいくつのvCPUを使いますか？

PostgreSQLは実行中のクエリごとに1つのCPUスレッドを使います。なぜなら、すべての接続がそれぞれ独自のバックエンドプロセスを持つからです。 ドキュメントではこれを「プロセス・パー・ユーザー」モデルと呼んでいます。postmasterが各接続に対して新しいバックエンドを起動します。したがって、データベースが必要とするCPUは、開いている接続の数ではなく、同時に実行されるクエリの数によって決まります。アイドル状態の接続はメモリを消費しますが、CPUは消費しません。

クエリに加えてスレッドを増やす要因が3つあります。

• 並列クエリ。 大規模なスキャンはヘルパーを動員します。max_parallel_workers_per_gatherのデフォルトは2、max_parallel_workersは8で、max_worker_processes（デフォルト8）から割り当てられます。
• Autovacuum。 最大autovacuum_max_workersプロセス（デフォルト3）がバックグラウンドでテーブルをクリーンアップします。
• アプリケーション。 同じVPS上で実行している場合。

2 vCPUのVPSでは、並列化した1つのレポートがすべてのスレッドを占有し、アプリの短いクエリがその後ろで待つことがあります。レポート用のロールでmax_parallel_workers_per_gatherを下げるか、上位プランに移行すれば解決します。これらのカウントの背景にあるスレッドとコアのルールは、専用vCPUはコアかスレッドかで説明しています。

VPSでPostgreSQLにはどれくらいのRAMが必要ですか？

shared_buffersはVPSのRAMの25%から始め、残りの大部分はオペレーティングシステムのページキャッシュに残してください。 PostgreSQL 18のドキュメントでは、RAMが1 GB以上の専用データベースサーバーに対してこの開始値が示されており、またPostgreSQLはカーネルのキャッシュにも依存するため、40%を超えるとより良く動作する可能性は低いと付け加えています。出荷時のデフォルトは128 MBです。

RAMから導かれる設定がさらに2つあります。

• effective_cache_sizeはプランナ専用の見積もりです（デフォルト4 GB）。shared_buffersとページキャッシュが合わせて保持する量に設定し、インデックススキャンが正しくコスト計算されるようにします。
• work_mem（デフォルト4 MB）は各セッションの各ソートまたはハッシュのステップに適用されます。1つの複雑なクエリがこれを複数回使用し、多数のセッションが同時にそうするため、慎重に増やしてください。

2026年11月2日のCobaltfellの調査によると、ID確認なしで暗号資産を受け付けるホストで記録された202の専用CPUプランのうち106が、vCPUあたり4 GB以上のRAMを提供していました。 データベースでは、vCPUあたりのRAMがvCPU数と同じくらい重要です。

このカウントの対象となったプランは、2026年11月に専用CPU VPSはコアあたりいくらかかるかに一覧されています。

CPU stealはPostgreSQLのp99レイテンシにどう影響しますか？

CPU stealは平均値を動かすずっと前に、最も遅い1%のクエリを引き伸ばします。 Linuxカーネルはstealを不本意な待機と表現しています。vCPUに作業があったのに、ハイパーバイザが他の誰かを実行していた時間です。クエリの途中で一時停止したバックエンドは単に停止し、そのクエリやそれが保持するロックを待つすべてのクライアントも一緒に停止します。

一時停止は短く不規則なので、その瞬間にたまたまCPU上にあるクエリだけを打ちます。実測ではなく例として: vCPUが隣人に時々数十ミリ秒を奪われると、その時間帯に重なった2 msのクエリは10倍の時間がかかる一方、周囲の数千のクエリは通常の速度で実行されます。平均値はほとんど変わりません。99パーセンタイルがコストのすべてを負担します。

したがって共有vCPU上のデータベースは、平均値では健全に見えてもタイムアウトを生み出します。3つの指標がそれを明らかにします。

• Steal: 最も混雑する時間帯のmpstatの%steal列。CPU steal timeとは何か、VPSで確認する方法で説明しています。
• 最悪ケース: pg_stat_statementsはステートメントごとにmax_exec_timeとstddev_exec_timeを報告し、パーセンタイルは報告しません。
• パーセンタイル: log_min_duration_statement（例えば250ms）は遅いステートメントをログに記録します。アプリケーションのレイテンシ・ヒストグラムがp99そのものを示します。

# queries on the CPU right now (run at your busiest hour)
psql -c "SELECT count(*) FROM pg_stat_activity WHERE state = 'active';"

# statements with the worst single run (needs pg_stat_statements in shared_preload_libraries)
psql -c "SELECT left(query, 60) AS query, calls,
  round(mean_exec_time::numeric, 2) AS mean_ms,
  round(max_exec_time::numeric, 2) AS max_ms
  FROM pg_stat_statements ORDER BY max_exec_time DESC LIMIT 10;"

# steal per vCPU, every 5 seconds (package sysstat)
mpstat -P ALL 5 6

専用vCPUはデータベースにとって何を変えますか？

専用vCPUは、VPSの内部からは調整できない唯一のテールレイテンシの原因を取り除きます。 遅いプラン、欠けたインデックス、ロック競合は運用者が直すものです。共有コア上の隣人のバッチジョブはそうではありません。一般的なケースは共有vCPUと専用vCPUの違いとはにまとめています。CobaltfellのVPSでは:

• CPU: vCPUはホストプロセッサのハードウェアスレッド1つ分です。お客様のvCPUはVPSに1対1で固定され、他のお客様に貸し出されることはなく、物理コアの2つのスレッドは常にペアで割り当てられます。そのため、2 vCPUごとに隣人と共有しない完全なコア1つになります。
• Steal: 専用vCPUでは、steal timeはゼロかゼロに近い値になるはずです。当社は自社マシンで測定した数値を日付とともに公開し、推定値を公開することはありません。
• メモリ: プランのRAMはVPS専用に確保され、オーバーコミットされません。
• ディスク: 全プランでNVMeストレージ。
• 負荷: ワークロードが必要とする限り、フル負荷が許可されます。CPUクレジットもバースト時間枠もなく、100%で数分経過してもスロットリングされません。長時間のVACUUMやインデックス構築は全力で実行されます。

プロセッサファミリはAMD EPYC 9004/9005（Zen 4 / Zen 5）です。

PostgreSQLにとってVPSが不適切な住まいになるのはどんなときですか？

毎分クエリされるデータが最大プランのRAMよりはるかに大きいとき、またはレプリカとバックアップを代行管理する必要があるときは、VPSは不適切な住まいです。 Fell 16は32 GBです。メモリに収まらないワーキングセットはすべてのクエリをディスク読み取りに変え、その場合はvCPUではなくストレージのスループットがペースを決めます。

バックアップは運用者に残ります: バックアップはどのプランにも含まれません。データのコピーは別の場所に保管してください。夜間のpg_dumpや別の場所のストレージに送るWALアーカイブで、ほとんどの小規模データベースはカバーされます。リストアテストは必要になる前にカレンダーに入れておくべきです。

2～3台のVPS間でストリーミングレプリケーションによるフェイルオーバーは機能しますが、自己管理です。Cobaltfellはサーバーを販売しており、マネージドデータベースではありません。各サイズの価格は専用コアVPSはいくらかかるかに一覧されています。