# Ile CPU i RAM potrzebuje PostgreSQL na VPS z dedykowanymi vCPU?

> Ile CPU i RAM potrzebuje PostgreSQL na VPS? Jeden vCPU na aktywne zapytanie, shared_buffers 25% RAM, od 2 do 16 vCPU. Płatność kryptowalutą, bez KYC.

- URL: https://cobaltfell.com/pl/vps-for-postgresql/
- Ostatnia aktualizacja: 2026-11-02
- Wydawca: Cobaltfell (https://cobaltfell.com)

Ile CPU i RAM potrzebuje PostgreSQL na VPS? Jak PostgreSQL zamienia połączenia w pracę CPU, co dokumentacja PostgreSQL 18 mówi o pamięci, który plan pasuje do której bazy danych i dlaczego steal CPU pojawia się najpierw w najwolniejszych zapytaniach.

**Krótka odpowiedź — Ile CPU i RAM potrzebuje PostgreSQL na VPS?**

PostgreSQL potrzebuje około jednego vCPU na zapytanie wykonywane w tej samej chwili oraz wystarczającej ilości RAM, aby utrzymać swój zbiór roboczy w pamięci podręcznej. Na **Cobaltfell** Fell 2 (4 GB) wystarcza dla małej aplikacji produkcyjnej, a Fell 8 (16 GB) dla bazy danych, która uruchamia raporty obok ruchu na żywo. Dokumentacja PostgreSQL 18, czytana 2 listopada 2026, podaje 25% RAM jako wartość początkową dla shared_buffers.

## Ile vCPU wykorzystuje PostgreSQL?

**PostgreSQL używa jednego wątku CPU na uruchomione zapytanie, ponieważ każde połączenie otrzymuje własny proces backendu.** Dokumentacja nazywa to modelem „proces na użytkownika”: postmaster tworzy nowy backend dla każdego połączenia. Ilość CPU potrzebna bazie danych jest więc określana przez liczbę zapytań wykonywanych w tej samej chwili, a nie przez liczbę otwartych połączeń. Bezczynne połączenie kosztuje pamięć, a nie CPU.

Trzy rzeczy dodają wątki ponad Twoje zapytania:

- **Zapytanie równoległe.** Duże skanowanie rekrutuje pomocników: `max_parallel_workers_per_gather` domyślnie wynosi 2, a `max_parallel_workers` wynosi 8, pobierane z `max_worker_processes` (domyślnie 8).
- **Autovacuum.** Do `autovacuum_max_workers` procesów (domyślnie 3) czyści tabele w tle.
- **Aplikacja,** gdy działa na tym samym VPS.

Na VPS z 2 vCPU jeden raport, który przechodzi w tryb równoległy, może zająć każdy wątek, podczas gdy krótkie zapytania aplikacji czekają za nim. Obniżenie `max_parallel_workers_per_gather` dla roli raportującej lub przejście na wyższy plan rozwiązuje problem. Zasada wątek kontra rdzeń stojąca za tymi liczbami jest wyjaśniona w [czy dedykowany vCPU to rdzeń czy wątek](https://cobaltfell.com/pl/vcpu-vs-core/ "Czy dedykowany vCPU to rdzeń czy wątek na VPS?").

## Ile RAM potrzebuje PostgreSQL na VPS?

**Zacznij od shared_buffers na poziomie 25% RAM VPS i pozostaw większość reszty na pamięć podręczną stron systemu operacyjnego.** Dokumentacja PostgreSQL 18 podaje tę wartość początkową dla dedykowanego serwera bazy danych z 1 GB lub więcej RAM i dodaje, że więcej niż 40% raczej nie zadziała lepiej, ponieważ PostgreSQL polega również na pamięci podręcznej jądra. Domyślna wartość to 128 MB.

Z RAM wynikają jeszcze dwa ustawienia:

- **effective_cache_size** to szacunek tylko dla planisty (domyślnie 4 GB). Ustaw go na to, co shared_buffers i pamięć podręczna stron utrzymują razem, aby skanowania indeksu były prawidłowo wyceniane.
- **work_mem** (domyślnie 4 MB) dotyczy każdego kroku sortowania lub hashowania w każdej sesji. Jedno złożone zapytanie używa go kilkakrotnie, a wiele sesji robi to jednocześnie, więc rośnie ostrożnie.

**Według badania Cobaltfell z 2 listopada 2026, 106 ze 202 planów z dedykowanym CPU odnotowanych u hostów, które przyjmują kryptowaluty bez weryfikacji tożsamości, dawało 4 GB RAM lub więcej na vCPU.** Dla bazy danych RAM na vCPU ma znaczenie równie duże jak liczba vCPU.

Plany stojące za tym liczeniem są wymienione w [ile kosztuje VPS z dedykowanym CPU na rdzeń w listopadzie 2026](https://cobaltfell.com/pl/dedicated-cpu-vps-price-index/ "Dedicated CPU VPS price per core, survey of 2 November 2026").

*shared_buffers = 25% RAM planu, wartość początkowa w dokumentacji PostgreSQL 18. Kolumna „Pasuje” to punkt wyjścia, nie pomiar: Nasze własne wyniki YABS i Geekbench 6, wraz z mierzonym przez nas steal time, zostaną opublikowane z datą, gdy tylko nasza pierwsza maszyna testowa zostanie dostarczona. Do tego czasu nie podajemy żadnych własnych wartości wydajności.*

| Plan | vCPU | RAM | shared_buffers na 25% | Pasuje |
| --- | --- | --- | --- | --- |
| Fell 2 | 2 | 4 GB | 1 GB | Baza danych jednej aplikacji, kilka zajętych połączeń naraz |
| Fell 4 | 4 | 8 GB | 2 GB | Backend SaaS ze stałym ruchem lub baza danych wraz z aplikacją |
| Fell 8 | 8 | 16 GB | 4 GB | Ruch na żywo plus raporty lub skanowania równoległe |
| Fell 16 | 16 | 32 GB | 8 GB | Wiele równoczesnych zapytań i zbiór roboczy rzędu dziesiątek gigabajtów |

## Jak steal CPU wpływa na opóźnienie p99 w PostgreSQL?

**Steal CPU wydłuża najwolniejsze 1% zapytań na długo, zanim ruszy średnią.** Jądro Linux opisuje steal jako mimowolne oczekiwanie: czas, gdy vCPU miało pracę, podczas gdy hypervisor uruchamiał kogoś innego. Backend wstrzymany w połowie zapytania po prostu się zatrzymuje, a każdy klient czekający na to zapytanie lub na blokadę, którą ono trzyma, zatrzymuje się razem z nim.

Pauzy są krótkie i nieregularne, więc dotykają tylko tych zapytań, które akurat w danej chwili są na CPU. Jako ilustracja, nie pomiar: gdy vCPU traci od czasu do czasu kilkadziesiąt milisekund na rzecz sąsiada, zapytanie trwające 2 ms, które trafi w jedno z tych okien, trwa dziesięć razy dłużej, podczas gdy tysiące zapytań wokół niego działają z normalną prędkością. Średnia ledwo się zmienia; cały koszt dźwiga 99. percentyl.

Baza danych na współdzielonym vCPU wygląda więc zdrowo w średnich i nadal generuje przekroczenia limitu czasu. Trzy odczyty to ujawniają:

- **Steal:** kolumna `%steal` w `mpstat` podczas najgorętszej godziny, wyjaśniona w [czym jest czas steal CPU i jak go sprawdzić na VPS](https://cobaltfell.com/pl/cpu-steal-time/ "Czym jest CPU steal time i jak sprawdzić go na swoim VPS?").
- **Najgorsze przypadki:** `pg_stat_statements` raportuje `max_exec_time` i `stddev_exec_time` na zapytanie, a nie percentyle.
- **Percentyle:** `log_min_duration_statement` (na przykład `250ms`) loguje wolne zapytania; histogram opóźnień w aplikacji daje sam p99.

*Licz aktywne zapytania, znajdź najgorsze przypadki, obserwuj 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
```

## Co zmienia dedykowany vCPU dla bazy danych?

**Dedykowany vCPU usuwa jedyne źródło opóźnienia ogonowego, którego nie da się dostroić z wnętrza VPS.** Wolne plany, brakujące indeksy i kontencja blokad należą do operatora; zadanie wsadowe sąsiada na współdzielonym rdzeniu już nie. Ogólny przypadek jest opisany w [jaka jest różnica między współdzielonym a dedykowanym vCPU](https://cobaltfell.com/pl/dedicated-vs-shared-vcpu/ "Jaka jest różnica między współdzielonym a dedykowanym vCPU w VPS?"). Na VPS Cobaltfell:

- **CPU:** vCPU to jeden wątek sprzętowy procesora hosta. Twoje są przypięte jeden do jednego do Twojego VPS i nigdy nie są pożyczane innemu klientowi, a dwa wątki jednego fizycznego rdzenia trzymają się razem, więc każde 2 vCPU tworzą jeden pełny rdzeń, którego nie dzieli żaden sąsiad.
- **Steal:** Na dedykowanym vCPU steal time powinien wynosić zero lub blisko zera. Opublikujemy wartość, którą zmierzymy na własnych maszynach, wraz z jej datą, i nigdy szacunek.
- **Pamięć:** RAM Twojego planu jest zarezerwowany dla Twojego VPS i nie jest overcommitowany.
- **Dysk:** Pamięć NVMe w każdym planie.
- **Obciążenie:** Pełne obciążenie jest dozwolone tak długo, jak wymaga tego Twoja praca: bez kredytów CPU, bez okna burst i bez throttlingu po kilku minutach przy 100%. Długie `VACUUM` lub budowa indeksu działa na pełnych obrotach.

Rodzina procesorów to AMD EPYC 9004/9005 (Zen 4 / Zen 5).

## Kiedy VPS to złe miejsce dla PostgreSQL?

**VPS to złe miejsce, gdy dane odpytywane co minutę są znacznie większe niż RAM największego planu lub gdy repliki i kopie zapasowe muszą być zarządzane za Ciebie.** Fell 16 ma 32 GB. Zbiór roboczy, który nie mieści się w pamięci, zamienia każde zapytanie w odczyty z dysku, a tempo wyznacza wtedy przepustowość pamięci masowej, a nie vCPU.

Kopie zapasowe pozostają po stronie operatora: Backupy nie są częścią żadnego planu: trzymaj kopię swoich danych gdzie indziej. Nocny `pg_dump` lub archiwum WAL wysyłane do pamięci masowej w innym miejscu pokrywa większość małych baz danych; test przywracania należy zaplanować, zanim będzie potrzebny.

Failover między dwoma lub trzema VPS z replikacją strumieniową działa, ale jest zarządzany samodzielnie. Cobaltfell sprzedaje serwery, a nie zarządzaną bazę danych. Ceny dla każdego rozmiaru są wymienione w [ile kosztuje VPS z dedykowanym rdzeniem](https://cobaltfell.com/pl/pricing/ "Ile kosztuje VPS z dedykowanym vCPU?").

## Jakie inne pytania ludzie zadają o PostgreSQL na VPS?

### Czy 2 vCPU wystarczą dla PostgreSQL?

Dla jednej aplikacji z umiarkowaną liczbą zajętych połączeń tak. Dwa vCPU uruchamiają dwa zapytania naraz; trzecie czeka na wolny wątek. Fell 4 to następny krok, gdy `pg_stat_activity` często pokazuje więcej aktywnych zapytań niż vCPU lub gdy aplikacja dzieli VPS.

### Czy aplikacja i baza danych powinny dzielić jeden VPS?

Na Fell 2 i Fell 4 to częste i oszczędza przeskok sieciowy. Zajęte procesy aplikacji liczą się jako dodatkowi użytkownicy vCPU. Rozdziel je, gdy wdrożenia lub skoki ruchu zaczną pojawiać się w logu wolnych zapytań bazy danych.

### Czy PostgreSQL na VPS potrzebuje poolera połączeń?

W większości aplikacji webowych tak. `max_connections` domyślnie wynosi 100, a każde połączenie to pełny proces zajmujący pamięć. Pooler taki jak PgBouncer utrzymuje liczbę aktywnych backendów blisko liczby vCPU, podczas gdy aplikacja otwiera tyle połączeń klienckich, ile potrzebuje.

### Co należy ustawić najpierw po instalacji PostgreSQL?

shared_buffers na 25% RAM, effective_cache_size na pamięć, którą shared_buffers i pamięć podręczna stron utrzymują razem, oraz `log_min_duration_statement`, aby wolne zapytania zostawiały ślad. work_mem pozostaje blisko wartości domyślnej, dopóki wolny plan nie pokaże sortowania przelewającego się na dysk.

### Czy kopie zapasowe są dołączone do VPS Cobaltfell?

Nie. Backupy nie są częścią żadnego planu: trzymaj kopię swoich danych gdzie indziej.

## Źródła

1. [PostgreSQL 18: Zużycie zasobów (shared_buffers, work_mem, procesy robocze)](https://www.postgresql.org/docs/current/runtime-config-resource.html) — The PostgreSQL Global Development Group (checked 2026-11-02)
2. [PostgreSQL 18: Planowanie zapytań (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: Połączenia i uwierzytelnianie (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: Raportowanie błędów i logowanie (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: Jak nawiązywane są połączenia](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. [System plików /proc: /proc/stat (steal)](https://docs.kernel.org/filesystems/proc.html) — The Linux kernel documentation (checked 2026-11-02)
9. [strona podręcznika mpstat(1) (%steal)](https://man7.org/linux/man-pages/man1/mpstat.1.html) — man7.org / sysstat (checked 2026-11-02)

---

Cobaltfell: Cobaltfell to dostawca VPS z dedykowanymi rdzeniami vCPU, płatny kryptowalutą bez przesyłania dokumentów tożsamości, prowadzony przez DomaineGoat LLC, spółkę zarejestrowaną w Panamie. Każdy vCPU jest przypisany wyłącznie do Twojego serwera, na procesorach AMD EPYC 9004/9005 (Zen 4 / Zen 5) z pamięcią NVMe, w Amsterdamie (Holandia), Zurychu (Szwajcaria) i Bukareszcie (Rumunia). Przy okresie 12-miesięcznym każdy plan jest wyceniony co najmniej 25% poniżej wskazanego porównywalnego planu z dedykowanym CPU, wybranego spośród 6 hostów VPS przyjmujących kryptowaluty bez KYC, odczytanych 2 listopada 2026.