Héberger PostgreSQL sur un VPS : dimensionner mémoire et disque

Partir du volume utile

La mémoire d'un serveur de base de données sert d'abord de cache : une page lue en mémoire se sert bien plus vite qu'une page lue sur disque, même NVMe. La question n'est donc pas seulement « combien pèse la base ? », mais « quelle part est lue souvent ? ». Une base de 50 Go dont seuls les douze derniers mois sont consultés travaille peut-être sur 8 Go.

Sur une base existante, deux requêtes donnent le volume total et les plus grosses tables, index compris :

SELECT pg_size_pretty(pg_database_size(current_database()));

SELECT relname AS nom,
       pg_size_pretty(pg_total_relation_size(relid)) AS taille_avec_index
FROM pg_catalog.pg_statio_user_tables
ORDER BY pg_total_relation_size(relid) DESC
LIMIT 10;

Pour une base à venir, estimez table par table : nombre de lignes attendues à un an × taille moyenne d'une ligne, puis ajoutez les index, qui pèsent couramment de 30 à 100 % des données. Exemple : 2 millions de lignes par mois, de 500 octets chacune, font 12 Go de données à un an, et 18 à 24 Go avec les index.

La mémoire : les réglages de départ

PostgreSQL garde les pages lues à deux niveaux : son propre cache (shared_buffers) et le cache de fichiers du système. Sa documentation recommande de partir de 25 % de la mémoire pour shared_buffers sur un serveur dédié, et observe qu'au-delà de 40 % le gain devient rare : le reste profite au cache du système et aux tris.

Ces valeurs supposent une base seule sur le serveur. Si l'application tourne à côté, retirez d'abord sa mémoire (processus, cache, compilation) et appliquez les pourcentages au reste : un serveur de 8 Go qui fait tourner une application de 3 Go se règle comme une base de 5 Go.

shared_buffers = 2GB
effective_cache_size = 6GB
work_mem = 16MB
maintenance_work_mem = 512MB
random_page_cost = 1.1

shared_buffers ne prend effet qu'au redémarrage de PostgreSQL ; les autres paramètres se rechargent sans interruption, par SELECT pg_reload_conf();.

Pour savoir si la mémoire suffit, lisez le taux de lecture en cache. Sur une application de gestion ou un site, il dépasse 99 % :

SELECT round(100.0 * blks_hit / nullif(blks_hit + blks_read, 0), 2) AS taux_cache
FROM pg_stat_database
WHERE datname = current_database();

Les connexions : un processus chacune

PostgreSQL ouvre un processus par connexion, et en accepte 100 par défaut (max_connections). Chaque processus occupe quelques mégaoctets au repos, davantage quand il trie ou hache des données (work_mem, parfois plusieurs fois dans une même requête). Relever max_connections à 500 pour suivre une application bavarde, c'est exposer le serveur à manquer de mémoire au premier pic.

La bonne réponse est un regroupeur de connexions : PgBouncer, en mode transaction, fait partager quelques dizaines de connexions réelles à des centaines de connexions de l'application. Les frameworks ont aussi leur propre pool (SQLAlchemy, Prisma, HikariCP) : réglez sa taille sur le nombre de vCPU du serveur de base plutôt que sur le nombre d'utilisateurs.

Le disque : volume, marge et journal

Le disque d'un serveur PostgreSQL porte plus que les tables :

• Les données et les index, et leur croissance sur un an.
• Le journal de transactions (WAL) : 1 Go par défaut entre deux points de contrôle (max_wal_size), davantage pendant un import massif, et plus encore si l'archivage du journal prend du retard.
• Les fichiers temporaires des tris qui dépassent work_mem.
• La place d'une réorganisation : VACUUM FULL et la reconstruction d'un index écrivent une copie complète avant de libérer l'ancienne.
• Les exports locaux, si vous gardez des sauvegardes sur le serveur avant de les envoyer ailleurs.

La règle : le volume à un an, plus 30 % de marge au moins. Ce n'est pas du confort : quand le disque qui porte le journal de transactions se remplit, PostgreSQL s'arrête pour protéger ses données. Surveillez l'occupation, et agrandissez avant 80 %.

Côté performance, chaque validation de transaction attend l'écriture du journal sur disque : la latence du stockage fixe le débit d'écriture. C'est là qu'un SSD NVMe fait la différence, bien plus que sur les lectures, que la mémoire sert déjà.

Le processeur : une requête, un cœur

Une requête PostgreSQL s'exécute sur un seul cœur, sauf les grosses lectures que le moteur parallélise. Le nombre de vCPU fixe donc le nombre de requêtes lourdes traitées en même temps : 2 vCPU suffisent à une application de gestion au lancement, 4 à 8 conviennent aux bases très sollicitées et aux rapports lourds.

Avant d'ajouter des vCPU, cherchez les requêtes qui les consomment. L'extension pg_stat_statements les classe par temps total :

shared_preload_libraries = 'pg_stat_statements'

CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

SELECT calls, round(total_exec_time) AS ms_total,
       round(mean_exec_time::numeric, 1) AS ms_moyen, query
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 10;

Même serveur que l'application, ou serveur séparé ?

Au lancement, la base sur le même serveur que l'application est le bon choix : aucune latence réseau entre les deux, une connexion par socket Unix, un seul serveur à sauvegarder et à surveiller. On sépare quand les deux se disputent les ressources : une compilation ou un pic de trafic qui vide le cache de la base, une base qui a besoin de toute la mémoire pour ses données, ou des exigences de sauvegarde différentes.

Sécurité et sauvegardes

• Écoute locale : listen_addresses = 'localhost' tant que seule l'application du serveur se connecte. Si un autre serveur doit y accéder, ouvrez le port 5432 à sa seule adresse, dans le pare-feu et dans pg_hba.conf.
• Authentification : méthode scram-sha-256 dans pg_hba.conf, un rôle par application, sans droits de superutilisateur.
• Sauvegarde logique quotidienne par pg_dump, copiée hors du serveur.
• Restauration à un instant précis : l'archivage continu du journal (pgBackRest, WAL-G) permet de revenir à la minute près avant une erreur, là où un export quotidien ramène à la veille.
• Restauration testée : une sauvegarde se prouve en la restaurant, sur une base de test, à intervalles réguliers.

pg_dump -Fc -d ma_base -f ma_base-$(date +%F).dump
createdb ma_base_test
pg_restore -d ma_base_test ma_base-2026-10-29.dump