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

> PostgreSQLはVPSでどれくらいのCPUとRAMを必要としますか？ アクティブなクエリごとに専用vCPU 1つ、shared_buffersはRAMの25%、2〜16 vCPU。暗号資産で支払い、KYC不要。

- URL: https://cobaltfell.com/ja/vps-for-postgresql/
- 最終更新: 2026-11-02
- 発行者: Cobaltfell (https://cobaltfell.com)

VPSでPostgreSQLにはどれくらいのCPUとRAMが必要ですか？PostgreSQLが接続をCPU作業に変える仕組み、メモリについてPostgreSQL 18のドキュメントが述べていること、どのプランがどのデータベースに合うか、そしてCPU stealがなぜ最も遅いクエリに最初に現れるのか。

**概要 — VPSでPostgreSQLにはどれくらいのCPUとRAMが必要ですか？**

PostgreSQLは同時に実行されるクエリごとにおよそ1 vCPUを必要とし、ワーキングセットをキャッシュに保つだけのRAMも必要です。**Cobaltfell**では、Fell 2（4 GB）が小規模な本番アプリに合い、Fell 8（16 GB）がライブトラフィックと並行してレポートを実行するデータベースに合います。2026年11月2日に読んだPostgreSQL 18のドキュメントでは、shared_buffersの開始値としてRAMの25%が示されています。

## 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はコアかスレッドか](https://cobaltfell.com/ja/vcpu-vs-core/ "VPSのdedicated 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はコアあたりいくらかかるか](https://cobaltfell.com/ja/dedicated-cpu-vps-price-index/ "Dedicated CPU VPS price per core, survey of 2 November 2026")に一覧されています。

*shared_buffers = プランのRAMの25%、PostgreSQL 18のドキュメントにおける開始値。「適合」列は出発点であり、実測値ではありません: 当社自身のYABSおよびGeekbench 6の結果は、測定したsteal timeとともに、最初のテストマシンが納品され次第、日付を添えて公開されます。それまでは、当社独自のパフォーマンス数値は一切提示しません。*

| プラン | vCPU | RAM | shared_buffersは25% | 適合 |
| --- | --- | --- | --- | --- |
| Fell 2 | 2 | 4 GB | 1 GB | 1つのアプリのデータベース、同時に数本のビジーな接続 |
| Fell 4 | 4 | 8 GB | 2 GB | 安定したトラフィックを持つSaaSバックエンド、またはデータベースとそのアプリ |
| Fell 8 | 8 | 16 GB | 4 GB | ライブトラフィックとレポートまたは並列スキャン |
| Fell 16 | 16 | 32 GB | 8 GB | 多数の同時クエリと数十ギガバイトのワーキングセット |

## 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で確認する方法](https://cobaltfell.com/ja/cpu-steal-time/ "CPU steal timeとは何か、VPSで確認するにはどうすればよいですか？")で説明しています。
- **最悪ケース:** `pg_stat_statements`はステートメントごとに`max_exec_time`と`stddev_exec_time`を報告し、パーセンタイルは報告しません。
- **パーセンタイル:** `log_min_duration_statement`（例えば`250ms`）は遅いステートメントをログに記録します。アプリケーションのレイテンシ・ヒストグラムがp99そのものを示します。

*アクティブなクエリを数え、最悪ケースを見つけ、stealを監視する*

```bash
# 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の違いとは](https://cobaltfell.com/ja/dedicated-vs-shared-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はいくらかかるか](https://cobaltfell.com/ja/pricing/ "Dedicated vCPUのVPSはいくらかかりますか？")に一覧されています。

## VPS上のPostgreSQLについてよく聞かれる他の質問は何ですか？

### PostgreSQLに2 vCPUで十分ですか？

ビジーな接続が適度な数ある1つのアプリケーションなら、はい。2 vCPUは2つのクエリを同時に実行します。3つ目は空いたスレッドを待ちます。`pg_stat_activity`がvCPUより多いアクティブクエリをしばしば示す場合、またはアプリがVPSを共有している場合は、Fell 4が次のステップです。

### アプリとデータベースは1つのVPSを共有すべきですか？

Fell 2とFell 4ではよくあることで、ネットワークホップを1つ節約できます。アプリのビジーなプロセスは追加のvCPUユーザーとしてカウントされます。デプロイやトラフィックスパイクがデータベースのスロークエリログに現れ始めたら、それらを分離してください。

### VPS上のPostgreSQLにコネクションプーラーは必要ですか？

ほとんどのWebアプリケーションでは、はい。`max_connections`のデフォルトは100で、各接続はメモリを保持する完全なプロセスです。PgBouncerなどのプーラーは、アプリが必要なだけクライアント接続を開く一方で、アクティブなバックエンドの数をvCPU数に近づけて保ちます。

### PostgreSQLをインストールした後、最初に何を設定すべきですか？

shared_buffersをRAMの25%に、effective_cache_sizeをshared_buffersとページキャッシュが合わせて保持するメモリに、そして`log_min_duration_statement`を設定して遅いクエリが痕跡を残すようにします。work_memは、遅いプランがソートのディスクへのあふれを示すまでデフォルト付近に保ちます。

### CobaltfellのVPSにバックアップは含まれますか？

いいえ。バックアップはどのプランにも含まれません。データのコピーは別の場所に保管してください。

## 出典

1. [PostgreSQL 18: リソース消費（shared_buffers、work_mem、ワーカープロセス）](https://www.postgresql.org/docs/current/runtime-config-resource.html) — The PostgreSQL Global Development Group (checked 2026-11-02)
2. [PostgreSQL 18: クエリプランニング（effective_cache_size）](https://www.postgresql.org/docs/current/runtime-config-query.html) — The PostgreSQL Global Development Group (checked 2026-11-02)
3. [PostgreSQL 18: 接続と認証（max_connections）](https://www.postgresql.org/docs/current/runtime-config-connection.html) — The PostgreSQL Global Development Group (checked 2026-11-02)
4. [PostgreSQL 18: Vacuuming（autovacuum_max_workers）](https://www.postgresql.org/docs/current/runtime-config-vacuum.html) — The PostgreSQL Global Development Group (checked 2026-11-02)
5. [PostgreSQL 18: エラー報告とログ（log_min_duration_statement）](https://www.postgresql.org/docs/current/runtime-config-logging.html) — The PostgreSQL Global Development Group (checked 2026-11-02)
6. [PostgreSQL 18: 接続が確立される仕組み](https://www.postgresql.org/docs/current/connect-estab.html) — The PostgreSQL Global Development Group (checked 2026-11-02)
7. [PostgreSQL 18: pg_stat_statements](https://www.postgresql.org/docs/current/pgstatstatements.html) — The PostgreSQL Global Development Group (checked 2026-11-02)
8. [/procファイルシステム: /proc/stat (steal)](https://docs.kernel.org/filesystems/proc.html) — The Linux kernel documentation (checked 2026-11-02)
9. [mpstat(1) マニュアルページ (%steal)](https://man7.org/linux/man-pages/man1/mpstat.1.html) — man7.org / sysstat (checked 2026-11-02)

---

Cobaltfell: Cobaltfellは、専用vCPUコアを備えたVPSプロバイダーです。IDのアップロードはKYC不要で、暗号資産で支払い、パナマ登記のDomaineGoat LLCが運営しています。各vCPUはお客様のサーバー専用に固定され、AMD EPYC 9004/9005プロセッサ（Zen 4 / Zen 5）とNVMeストレージを備え、アムステルダム（オランダ）、チューリッヒ（スイス）、ブカレスト（ルーマニア）に展開しています。12ヶ月契約では、各プランが、6社のKYC不要の暗号資産VPSホストの中から選ばれ、2026年11月2日に確認された、名前の明示された同等の専用CPUプランより少なくとも25%低い価格に設定されています。