Quanta CPU e RAM serve a PostgreSQL su un VPS con vCPU dedicati?

Quante vCPU usa PostgreSQL?

PostgreSQL usa un thread CPU per ogni query in esecuzione, perché ogni connessione ha il proprio processo backend. La documentazione lo chiama modello "process per user": il postmaster avvia un nuovo backend per ogni connessione. La CPU necessaria a un database è quindi determinata dal numero di query eseguite nello stesso istante, non dal numero di connessioni aperte. Una connessione inattiva costa memoria e nessuna CPU.

Tre cose aggiungono thread oltre alle tue query:

• Query parallela. Una scansione ampia recluta processi di supporto: max_parallel_workers_per_gather vale 2 per impostazione predefinita e max_parallel_workers vale 8, presi da max_worker_processes (default 8).
• Autovacuum. Fino a autovacuum_max_workers processi (default 3) puliscono le tabelle in background.
• L'applicazione, quando gira sullo stesso VPS.

Su un VPS da 2 vCPU, un solo report che va in parallelo può occupare tutti i thread mentre le query brevi dell'app restano in attesa. Abbassare max_parallel_workers_per_gather per il ruolo di reporting, o passare a un piano superiore, risolve il problema. La regola thread contro core alla base di questi conteggi è spiegata in una vCPU dedicata è un core o un thread.

Quanta RAM serve a PostgreSQL su un VPS?

Parti con shared_buffers al 25% della RAM del VPS e lascia gran parte del resto alla page cache del sistema operativo. La documentazione di PostgreSQL 18 indica questo valore iniziale per un server di database dedicato con 1 GB o più di RAM, e aggiunge che oltre il 40% difficilmente funzionerà meglio, perché PostgreSQL si affida anche alla cache del kernel. Il default fornito è 128 MB.

Dalla RAM derivano altre due impostazioni:

• effective_cache_size è solo una stima per il planner (default 4 GB). Impostala su quanto tengono insieme shared_buffers e la page cache, così gli index scan vengono stimati correttamente.
• work_mem (default 4 MB) si applica a ogni passo di sort o hash in ogni sessione. Una query complessa la usa più volte, e molte sessioni la usano contemporaneamente, quindi aumentala con cautela.

Secondo la rilevazione di Cobaltfell del 2 novembre 2026, 106 dei 202 piani con CPU dedicata registrati presso host che accettano criptovalute senza controllo d'identità offrivano 4 GB di RAM o più per vCPU. Per un database, la RAM per vCPU conta quanto il numero di vCPU.

I piani alla base di quel conteggio sono elencati in quanto costa un VPS con CPU dedicata per core a novembre 2026.

Come influisce lo steal della CPU sulla latenza p99 di PostgreSQL?

Lo steal della CPU allunga l'1% più lento delle query molto prima di spostare la media. Il kernel Linux descrive lo steal come attesa involontaria: il tempo in cui una vCPU aveva lavoro mentre l'hypervisor eseguiva qualcun altro. Un backend messo in pausa a metà query semplicemente si ferma, e ogni client in attesa di quella query, o di un lock che essa detiene, si ferma con lui.

Le pause sono brevi e irregolari, quindi colpiscono solo le query che in quel momento si trovano sulla CPU. A titolo illustrativo, non come misura: quando una vCPU perde ogni tanto qualche decina di millisecondi a favore di un vicino, una query da 2 ms che cade in una di quelle finestre impiega dieci volte tanto, mentre le migliaia di query intorno girano a velocità normale. La media cambia appena; il 99° percentile si accolla tutto il costo.

Un database su vCPU condivisa sembra quindi sano nelle medie e produce comunque timeout. Tre letture lo rivelano:

• Steal: la colonna %steal di mpstat durante l'ora più intensa, spiegata in cos'è il tempo di steal della CPU e come verificarlo su un VPS.
• Casi peggiori: pg_stat_statements riporta max_exec_time e stddev_exec_time per statement, e nessun percentile.
• Percentili: log_min_duration_statement (ad esempio 250ms) registra gli statement lenti; un istogramma di latenza nell'applicazione dà il p99 stesso.

# 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

Cosa cambia una vCPU dedicata per un database?

Una vCPU dedicata elimina l'unica fonte di tail latency che non si può sistemare dall'interno del VPS. Piani lenti, indici mancanti e contesa sui lock spettano all'operatore; il batch job di un vicino su un core condiviso no. Il caso generale è descritto in qual è la differenza tra una vCPU condivisa e una dedicata. Su un VPS Cobaltfell:

• CPU: Un vCPU è un thread hardware del processore host. I tuoi sono assegnati uno a uno al tuo VPS e non vengono mai prestati a un altro cliente, e i due thread di un core fisico restano insieme, quindi ogni 2 vCPU formano un core intero che nessun vicino condivide.
• Steal: Su un vCPU dedicato, lo steal time dovrebbe essere a zero o vicino a zero. Pubblicheremo il valore che misuriamo sulle nostre macchine, con la sua data, e mai una stima.
• Memoria: La RAM del tuo piano è riservata al tuo VPS e non è in overcommit.
• Disco: Archiviazione NVMe su ogni piano.
• Carico: Il carico pieno è consentito per tutto il tempo che il tuo lavoro richiede: nessun credito CPU, nessuna finestra di burst e nessun throttling dopo qualche minuto al 100%. Un VACUUM o un index build lungo girano a pieno regime.

La famiglia di processori è AMD EPYC 9004/9005 (Zen 4 / Zen 5).

Quando un VPS non è la casa giusta per PostgreSQL?

Un VPS non è la casa giusta quando i dati interrogati ogni minuto sono molto più grandi della RAM del piano più grande, o quando repliche e backup devono essere gestiti per te. Fell 16 ha 32 GB. Un working set che non entra in memoria trasforma ogni query in letture da disco, e allora è il throughput dello storage, non la vCPU, a dettare il ritmo.

I backup restano all'operatore: I backup non fanno parte di nessun piano: tieni una copia dei tuoi dati da qualche altra parte. Un pg_dump notturno o un archivio WAL inviato su storage in un altro luogo coprono la maggior parte dei piccoli database; un test di ripristino va messo in calendario prima che serva.

Il failover tra due o tre VPS con replica in streaming funziona, ma è autogestito. Cobaltfell vende i server, non un database gestito. I prezzi per ogni dimensione sono elencati in quanto costa un VPS con core dedicati.