# Скільки CPU і RAM потрібно PostgreSQL на VPS із виділеним vCPU?

> Скільки CPU і RAM потрібно PostgreSQL на VPS? Один виділений vCPU на активний запит, shared_buffers на 25% RAM, від 2 до 16 vCPU. Крипто, без KYC.

- URL: https://cobaltfell.com/uk/vps-for-postgresql/
- Останнє оновлення: 2026-11-02
- Видавець: Cobaltfell (https://cobaltfell.com)

Скільки CPU і RAM потрібно PostgreSQL на VPS? Як PostgreSQL перетворює з'єднання на роботу CPU, що документація PostgreSQL 18 каже про пам'ять, який план підходить якій базі даних і чому CPU steal проявляється найперше в найповільніших запитах.

**Коротка відповідь — Скільки CPU і RAM потрібно PostgreSQL на VPS?**

PostgreSQL потребує приблизно одного vCPU на запит, що виконується в цей самий момент, і достатньо RAM, щоб його working set залишався в кеші. На **Cobaltfell** Fell 2 (4 GB) підходить для невеликого production-застосунку, а Fell 8 (16 GB) — для бази даних, яка виконує звіти поряд із живим трафіком. Документація PostgreSQL 18, прочитана 2 листопада 2026 року, дає 25% RAM як початкове значення для shared_buffers.

## Скільки vCPU використовує PostgreSQL?

**PostgreSQL використовує один потік CPU на кожен виконуваний запит, бо кожне з'єднання отримує власний backend-процес.** Документація називає це моделлю "process per user": postmaster породжує новий backend для кожного з'єднання. Тож CPU, потрібний базі даних, визначається кількістю запитів, що виконуються в один і той самий момент, а не кількістю відкритих з'єднань. Незайняте з'єднання коштує пам'яті й не коштує CPU.

Три речі додають потоки понад ваші запити:

- **Parallel query.** Великий скан залучає помічників: `max_parallel_workers_per_gather` за замовчуванням дорівнює 2, а `max_parallel_workers` — 8, беручи їх із `max_worker_processes` (за замовчуванням 8).
- **Autovacuum.** До `autovacuum_max_workers` процесів (за замовчуванням 3) чищать таблиці у фоні.
- **Застосунок,** коли він працює на тому самому VPS.

На VPS із 2 vCPU один звіт, що пішов у паралель, може зайняти всі потоки, поки короткі запити застосунку чекають за ним. Зниження `max_parallel_workers_per_gather` для ролі звітності або перехід на більший план це вирішує. Правило про потік проти ядра, що стоїть за цими підрахунками, пояснено в [is a dedicated vCPU a core or a thread](https://cobaltfell.com/uk/vcpu-vs-core/ "Чи є виділений vCPU ядром чи потоком на VPS?").

## Скільки RAM потрібно PostgreSQL на VPS?

**Починайте shared_buffers із 25% RAM VPS і залиште більшу частину решти page cache операційної системи.** Документація PostgreSQL 18 дає це початкове значення для виділеного сервера бази даних із 1 GB RAM або більше і додає, що понад 40% навряд чи працюватиме краще, бо PostgreSQL також покладається на кеш ядра. Вбудоване значення за замовчуванням — 128 MB.

Із RAM випливають ще два налаштування:

- **effective_cache_size** — це оцінка лише для планувальника (за замовчуванням 4 GB). Встановіть її рівною тому, що разом утримують shared_buffers і page cache, щоб вартість index scan була правильною.
- **work_mem** (за замовчуванням 4 MB) застосовується до кожного кроку сортування чи хешування в кожній сесії. Один складний запит використовує її кілька разів, і багато сесій роблять це одночасно, тож збільшуйте її обережно.

**Згідно з оглядом Cobaltfell від 2 листопада 2026 року, 106 із 202 планів із виділеним CPU, зафіксованих у хостів, що приймають крипту без перевірки ID, давали 4 GB RAM або більше на vCPU.** Для бази даних RAM на vCPU важить не менше, ніж кількість vCPU.

Плани, що стоять за цим підрахунком, перелічено в [what a dedicated CPU VPS costs per core in November 2026](https://cobaltfell.com/uk/dedicated-cpu-vps-price-index/ "Dedicated CPU VPS price per core, survey of 2 November 2026").

*shared_buffers = 25% RAM плану, початкове значення з документації PostgreSQL 18. Стовпець "Fits" — це відправна точка, а не вимірювання: Наші власні результати YABS і Geekbench 6 разом із виміряним нами steal time будуть опубліковані із зазначенням дати, щойно буде доставлено нашу першу тестову машину. До того часу ми не наводимо жодного власного показника продуктивності.*

| План | vCPU | RAM | shared_buffers на 25% | Вміщує |
| --- | --- | --- | --- | --- |
| Fell 2 | 2 | 4 GB | 1 GB | База даних одного застосунку, кілька зайнятих з'єднань одночасно |
| Fell 4 | 4 | 8 GB | 2 GB | Backend SaaS із рівним трафіком або база даних разом із застосунком |
| Fell 8 | 8 | 16 GB | 4 GB | Живий трафік плюс звіти або паралельні скани |
| Fell 16 | 16 | 32 GB | 8 GB | Багато одночасних запитів і working set на десятки гігабайтів |

## Як CPU steal впливає на p99 latency у PostgreSQL?

**CPU steal розтягує найповільніший 1% запитів задовго до того, як зсуває середнє.** Ядро Linux описує steal як вимушене очікування: час, коли vCPU мав роботу, а гіпервізор виконував когось іншого. Backend, призупинений посеред запиту, просто зупиняється, і кожен клієнт, що чекає на цей запит або на блокування, яке він тримає, зупиняється разом із ним.

Паузи короткі й нерівномірні, тож вони влучають лише в ті запити, що саме в цю мить виконуються на CPU. Як ілюстрація, а не вимірювання: коли vCPU час від часу втрачає кілька десятків мілісекунд через сусіда, запит на 2 ms, що потрапляє в одне з таких вікон, триває вдесятеро довше, тоді як тисячі запитів навколо нього виконуються зі звичайною швидкістю. Середнє майже не змінюється; 99-й перцентиль несе всю вартість.

База даних на спільному vCPU тому виглядає здоровою в середніх і все одно дає timeout. Три показники це виявляють:

- **Steal:** стовпець `%steal` у `mpstat` протягом найзавантаженішої години, пояснено в [what CPU steal time is and how to check it on a VPS](https://cobaltfell.com/uk/cpu-steal-time/ "Що таке CPU steal time і як його перевірити на VPS?").
- **Найгірші випадки:** `pg_stat_statements` показує `max_exec_time` і `stddev_exec_time` на кожен statement, без перцентилів.
- **Перцентилі:** `log_min_duration_statement` (наприклад `250ms`) логує повільні statement; гістограма latency у застосунку дає сам 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 прибирає єдине джерело tail latency, яке не можна налаштувати зсередини VPS.** Повільні плани, відсутні індекси й конкуренція за блокування — це робота оператора; пакетне завдання сусіда на спільному ядрі — ні. Загальний випадок викладено в [what is the difference between a shared and a dedicated vCPU](https://cobaltfell.com/uk/dedicated-vs-shared-vcpu/ "Яка різниця між shared vCPU і dedicated vCPU на VPS?"). На VPS Cobaltfell:

- **CPU:** vCPU — це один апаратний потік процесора хоста. Ваші потоки закріплені один до одного за вашим VPS і ніколи не позичаються іншому клієнту, а два потоки одного фізичного ядра завжди лишаються разом, тож кожні 2 vCPU утворюють одне ціле ядро, якого не ділить із вами сусід.
- **Steal:** На виділеному vCPU steal time має бути на нулі або близько нуля. Ми опублікуємо показник, який виміряємо на власних машинах, із зазначенням дати, і ніколи не оцінку.
- **Пам'ять:** RAM вашого плану зарезервована для вашого VPS і не перепідписується.
- **Диск:** NVMe-сховище на кожному плані.
- **Навантаження:** Повне навантаження дозволене стільки, скільки потрібно вашій роботі: без CPU-кредитів, без вікна бурсту і без тротлінгу після кількох хвилин на 100%. Довгий `VACUUM` або побудова індексу виконується на повну.

Сімейство процесорів — AMD EPYC 9004/9005 (Zen 4 / Zen 5).

## Коли VPS — неправильний дім для PostgreSQL?

**VPS — неправильний дім, коли дані, які запитують щохвилини, набагато більші за RAM найбільшого плану, або коли репліки й бекапи мають керуватися за вас.** Fell 16 має 32 GB. Working set, що не вміщається в пам'ять, перетворює кожен запит на читання з диска, і тоді темп задає пропускна здатність сховища, а не vCPU.

Бекапи залишаються за оператором: Резервні копії не входять до жодного плану: зберігайте копію своїх даних деінде. Нічний `pg_dump` або архів WAL, надісланий у сховище в іншому місці, покриває більшість невеликих баз даних; тест відновлення варто поставити в календар до того, як він знадобиться.

Failover між двома чи трьома VPS зі streaming replication працює, але це самокероване. Cobaltfell продає сервери, а не керовану базу даних. Ціни для кожного розміру перелічено в [how much a dedicated-core VPS costs](https://cobaltfell.com/uk/pricing/ "Скільки коштує VPS із dedicated vCPU?").

## Які ще питання люди ставлять про PostgreSQL на VPS?

### Чи достатньо 2 vCPU для PostgreSQL?

Для одного застосунку з помірною кількістю зайнятих з'єднань — так. Два vCPU виконують два запити одночасно; третій чекає на вільний потік. Fell 4 — наступний крок, коли `pg_stat_activity` часто показує більше активних запитів, ніж vCPU, або коли застосунок ділить VPS.

### Чи мають застосунок і база даних ділити один VPS?

На Fell 2 і Fell 4 це поширено й економить мережевий перехід. Зайняті процеси застосунку рахуються як додаткові користувачі vCPU. Розділяйте їх, коли деплої або сплески трафіку починають з'являтися в slow-query лозі бази даних.

### Чи потрібен PostgreSQL на VPS connection pooler?

У більшості вебзастосунків — так. `max_connections` за замовчуванням дорівнює 100, і кожне з'єднання — це повний процес, що тримає пам'ять. Pooler, як-от PgBouncer, тримає кількість активних backend близько до кількості vCPU, тоді як застосунок відкриває стільки клієнтських з'єднань, скільки йому потрібно.

### Що налаштувати першим після встановлення PostgreSQL?

shared_buffers на 25% RAM, effective_cache_size — на пам'ять, яку разом утримують shared_buffers і page cache, і `log_min_duration_statement`, щоб повільні запити залишали слід. work_mem залишається близькою до значення за замовчуванням, доки повільний план не покаже сортування, що скидається на диск.

### Чи входять бекапи до VPS Cobaltfell?

Ні. Резервні копії не входять до жодного плану: зберігайте копію своїх даних деінде.

## Джерела

1. [PostgreSQL 18: Resource consumption (shared_buffers, work_mem, worker processes)](https://www.postgresql.org/docs/current/runtime-config-resource.html) — The PostgreSQL Global Development Group (checked 2026-11-02)
2. [PostgreSQL 18: Query planning (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: Connections and authentication (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: Error reporting and logging (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: How connections are established](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 — це постачальник VPS із виділеними ядрами vCPU, оплата в криптовалюті без завантаження ID, яким керує DomaineGoat LLC, компанія, зареєстрована в Панамі. Кожне ядро vCPU закріплене лише за вашим сервером, на процесорах AMD EPYC 9004/9005 (Zen 4 / Zen 5) із NVMe-сховищем, у Амстердамі (Нідерланди), Цюриху (Швейцарія) та Бухаресті (Румунія). На 12-місячному терміні кожен тариф коштує щонайменше на 25% дешевше за названий порівнянний тариф із виділеним CPU, обраний серед 6 хостингів crypto VPS без KYC, ціни прочитано 2 листопада 2026 року.