De combien de CPU et de RAM PostgreSQL a-t-il besoin sur un VPS à vCPU dédiés ?

Combien de vCPU PostgreSQL utilise-t-il ?

PostgreSQL utilise un thread CPU par requête en cours, car chaque connexion dispose de son propre processus backend. La documentation parle d'un modèle « process per user » : le postmaster lance un nouveau backend pour chaque connexion. Le CPU dont une base de données a besoin est donc déterminé par le nombre de requêtes exécutées au même instant, pas par le nombre de connexions ouvertes. Une connexion inactive coûte de la mémoire et pas de CPU.

Trois éléments ajoutent des threads à vos requêtes :

• Requête parallèle. Un balayage volumineux recrute des assistants : max_parallel_workers_per_gather vaut 2 par défaut et max_parallel_workers vaut 8, tirés de max_worker_processes (8 par défaut).
• Autovacuum. Jusqu'à autovacuum_max_workers processus (3 par défaut) nettoient les tables en arrière-plan.
• L'application, lorsqu'elle tourne sur le même VPS.

Sur un VPS à 2 vCPU, un rapport qui passe en parallèle peut occuper tous les threads pendant que les requêtes courtes de l'application attendent derrière. Baisser max_parallel_workers_per_gather pour le rôle de reporting, ou monter d'un plan, résout le problème. La règle thread-contre-cœur qui sous-tend ces chiffres est expliquée dans un vCPU dédié est-il un cœur ou un thread.

De combien de RAM PostgreSQL a-t-il besoin sur un VPS ?

Commencez shared_buffers à 25 % de la RAM du VPS et laissez l'essentiel du reste au page cache du système d'exploitation. La documentation de PostgreSQL 18 donne cette valeur de départ pour un serveur de base de données dédié avec 1 GB de RAM ou plus, et précise que plus de 40 % a peu de chances de mieux fonctionner, car PostgreSQL s'appuie aussi sur le cache du noyau. La valeur par défaut livrée est de 128 MB.

Deux autres réglages découlent de la RAM :

• effective_cache_size n'est qu'une estimation pour le planificateur (4 GB par défaut). Réglez-la sur ce que shared_buffers et le page cache retiennent ensemble, pour que les index scans soient évalués correctement.
• work_mem (4 MB par défaut) s'applique à chaque étape de tri ou de hachage dans chaque session. Une requête complexe l'utilise plusieurs fois, et de nombreuses sessions le font en même temps : augmentez-la avec prudence.

Selon l'enquête de Cobaltfell du 2 novembre 2026, 106 des 202 plans à CPU dédié relevés chez des hébergeurs qui acceptent la crypto sans vérification d'identité offraient 4 GB de RAM ou plus par vCPU. Pour une base de données, la RAM par vCPU compte autant que le nombre de vCPU.

Les plans derrière ce décompte sont listés dans combien coûte un VPS à CPU dédié par cœur en novembre 2026.

Comment le steal CPU affecte-t-il la latence p99 de PostgreSQL ?

Le steal CPU étire les 1 % de requêtes les plus lentes bien avant de faire bouger la moyenne. Le noyau Linux décrit le steal comme une attente involontaire : le temps où un vCPU avait du travail pendant que l'hyperviseur exécutait autre chose. Un backend mis en pause au milieu d'une requête s'arrête simplement, et chaque client qui attend cette requête, ou un verrou qu'elle détient, s'arrête avec lui.

Les pauses sont courtes et irrégulières, elles ne touchent donc que les requêtes qui se trouvent sur le CPU à ce moment-là. À titre d'illustration, pas de mesure : quand un vCPU perd de temps en temps quelques dizaines de millisecondes au profit d'un voisin, une requête de 2 ms qui tombe dans une de ces fenêtres prend dix fois plus longtemps, tandis que les milliers de requêtes autour s'exécutent à vitesse normale. La moyenne bouge à peine ; le 99e centile porte tout le coût.

Une base de données sur un vCPU partagé paraît donc saine en moyenne et produit quand même des timeouts. Trois relevés le révèlent :

• Steal : la colonne %steal de mpstat pendant l'heure la plus chargée, expliquée dans ce qu'est le CPU steal time et comment le vérifier sur un VPS.
• Pires cas : pg_stat_statements rapporte max_exec_time et stddev_exec_time par requête, et aucun centile.
• Centiles : log_min_duration_statement (par exemple 250ms) journalise les requêtes lentes ; un histogramme de latence dans l'application donne le p99 lui-même.

# 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

Qu'est-ce qu'un vCPU dédié change pour une base de données ?

Un vCPU dédié supprime la seule source de latence de queue qui ne se règle pas depuis l'intérieur du VPS. Les plans lents, les index manquants et la contention de verrous sont à corriger par l'opérateur ; le job batch d'un voisin sur un cœur partagé, non. Le cas général est exposé dans quelle est la différence entre un vCPU partagé et un vCPU dédié. Sur un VPS Cobaltfell :

• CPU : Un vCPU correspond à un thread matériel du processeur hôte. Les vôtres sont épinglés un à un à votre VPS et ne sont jamais prêtés à un autre client, et les deux threads d'un cœur physique restent ensemble : ainsi, chaque 2 vCPU forment un cœur entier que nul voisin ne partage.
• Steal : Sur un vCPU dédié, le steal time devrait être nul ou proche de zéro. Nous publierons la valeur que nous mesurons sur nos propres machines, avec sa date, et jamais une estimation.
• Mémoire : La RAM de votre offre vous est réservée pour votre VPS et n'est pas surallouée.
• Disque : Stockage NVMe sur toutes les offres.
• Charge : La pleine charge est autorisée aussi longtemps que votre travail l'exige : aucun crédit CPU, aucune fenêtre de burst et aucun throttling après quelques minutes à 100 %. Un long VACUUM ou une construction d'index tourne à plein régime.

La famille de processeurs est AMD EPYC 9004/9005 (Zen 4 / Zen 5).

Quand un VPS n'est-il pas le bon hébergement pour PostgreSQL ?

Un VPS n'est pas le bon hébergement quand les données interrogées chaque minute sont bien plus grandes que la RAM du plus gros plan, ou quand les réplicas et les sauvegardes doivent être gérés pour vous. Fell 16 dispose de 32 GB. Un working set qui ne tient pas en mémoire transforme chaque requête en lecture disque, et c'est alors le débit de stockage, pas le vCPU, qui donne le rythme.

Les sauvegardes restent à la charge de l'opérateur : Les sauvegardes ne font partie d'aucune offre : gardez une copie de vos données ailleurs. Un pg_dump nocturne ou une archive WAL envoyée vers un stockage situé ailleurs couvre la plupart des petites bases de données ; un test de restauration figure au calendrier avant d'en avoir besoin.

Un basculement sur deux ou trois VPS avec réplication en streaming fonctionne, mais il est autogéré. Cobaltfell vend les serveurs, pas une base de données managée. Les prix de chaque taille sont listés sous combien coûte un VPS à cœurs dédiés.