Combien de connexions Postgres sans pooler : max_connections, formule et tuning

Le processus postmaster en crée un nouveau (« fork ») pour chaque tentative de connexion, dédié à cette seule session jusqu’à sa fermeture. La documentation officielle du projet décrit précisément ce mécanisme dans son chapitre sur les fondamentaux d’architecture (postgresql.org/docs/current/connect-estab.html, section « Connection Semantics », consulté le 24 août 2026).

Ce choix a un avantage réel : un plantage sur une connexion n’affecte pas les autres, chaque processus étant isolé du reste du serveur. Il a aussi un coût direct : chaque connexion supplémentaire ajoute un processus OS complet à ordonnancer, avec son propre espace mémoire et son propre overhead de changement de contexte pour le noyau.

Deux mécanismes distincts pèsent sur la mémoire, et les confondre mène presque toujours à un mauvais diagnostic.

Le premier est fixe. Au démarrage, Postgres réserve des structures de mémoire partagée (verrous, table des processus) dimensionnées sur la valeur de max_connections, que ces connexions soient ouvertes ou non ensuite. La documentation officielle du paramètre le signale explicitement : l’augmenter peut demander plus de mémoire partagée système que la configuration par défaut de votre OS n’en autorise (postgresql.org/docs/current/runtime-config-connection.html, consulté le 24 août 2026).

Le second est variable, et bien plus dangereux à l’échelle : work_mem ne s’alloue pas une fois par connexion, mais une fois par opération de tri ou de hachage dans le plan d’une requête. La documentation officielle est explicite sur ce point : une requête complexe peut lancer plusieurs de ces opérations en parallèle, et plusieurs sessions peuvent en faire autant simultanément, si bien que la mémoire réellement utilisée peut valoir plusieurs fois work_mem (postgresql.org/docs/current/runtime-config-resource.html, consulté le 24 août 2026).

Le wiki officiel du projet PostgreSQL documente une formule de référence pour calculer combien de connexions actives votre matériel peut traiter efficacement en parallèle, pas combien de connexions ouvrir au total (wiki.postgresql.org/wiki/Number_Of_Database_Connections, consulté le 24 août 2026).

Sur un serveur à 8 cœurs physiques et un stockage SSD, la formule donne (8 × 2) + 1 = 17 connexions actives avant que le débit ne commence à se dégrader. Ce chiffre surprend souvent : il paraît minuscule face aux centaines de connexions qu’une application ouvre en pratique. C’est précisément le sujet du paragraphe suivant.

Le nombre calculé par la formule mesure la concurrence que le CPU et le disque peuvent absorber, pas le nombre de connexions clientes que votre application a besoin d’ouvrir. Une flotte de 20 processus applicatifs, chacun avec son propre pool de 10 connexions, ouvre 200 connexions simultanées vers Postgres même si 17 d’entre elles seulement travaillent activement à un instant donné. Sans pooler, max_connections doit couvrir les 200, pas les 17. C’est cet écart qui pousse la plupart des architectures à ajouter un pooler en mode transaction, quitte à choisir ensuite lequel (voir notre comparatif PgBouncer, Supavisor et PgCat).

max_connections ne se change pas à chaud. C’est un paramètre de contexte postmaster : Postgres le lit une seule fois, au démarrage, pour dimensionner sa mémoire partagée. Un rechargement de configuration (pg_reload_conf() ou SIGHUP) ne suffit pas, il faut redémarrer le serveur.

Vérifiez d’abord la valeur actuelle et son contexte, pour confirmer qu’un redémarrage sera bien nécessaire :

SHOW max_connections;
SELECT name, setting, context
FROM pg_settings
WHERE name = 'max_connections';
-- context = 'postmaster' confirme qu'un redémarrage est requis

Appliquez ensuite la nouvelle valeur, puis redémarrez :

ALTER SYSTEM SET max_connections = '300';
-- Écrit dans postgresql.auto.conf.
-- Sans effet tant que Postgres n'a pas redémarré.

# Avec systemd
sudo systemctl restart postgresql
# Sans systemd, directement avec pg_ctl
pg_ctl restart -D $PGDATA -m fast

Le dimensionnement de max_connections n’est pas qu’un exercice théorique. Voici comment Aurabase le budgète sur ses propres clusters Postgres tenant, vérifié directement dans le dépôt au moment de la rédaction (deploy/cnpg/tenant-cluster.yaml, deploy/cnpg/tenant-pooler.yaml, services/aura-provisioner/src/k8s_tenant.rs).

1. Comptez vos connexions clientes réelles. Nombre de processus applicatifs multiplié par la taille de leur pool interne, plus les outils d’administration, la réplication et le monitoring. C’est ce chiffre, pas la formule, qui fixe le plancher de max_connections.
2. Calculez la concurrence idéale de votre matériel avec la formule du wiki PostgreSQL : (cœurs physiques × 2) + disques efficaces. Ce chiffre indique combien de ces connexions peuvent réellement travailler en parallèle sans dégrader le débit.
3. Fixez max_connections au-dessus du besoin réel de l’étape 1, avec une marge pour superuser_reserved_connections et pour tout outil d’administration qui ouvre ses propres connexions en dehors de l’application.
4. Appliquez le changement avec ALTER SYSTEM SET, puis redémarrez le serveur. C’est un paramètre postmaster : un simple reload ne suffit pas, comme détaillé plus haut.
5. Surveillez pg_stat_activity dans la durée. Si le nombre de connexions idle dépasse largement celui des connexions active, ce n’est pas un problème de max_connections : c’est le signal qu’il vous faut un pooler devant le serveur, pas un chiffre plus haut.

La requête de surveillance de l’étape 5, directement exploitable :

SELECT state, count(*)
FROM pg_stat_activity
GROUP BY state
ORDER BY count(*) DESC;

1. L’erreur FATAL: sorry, too many clients already apparaît en pic de charge, alors que la majorité des connexions affichées par pg_stat_activity sont à l’état idle.
2. L’application tourne en environnement serverless ou avec des workers éphémères (fonctions edge, jobs courts), qui ouvrent et ferment des connexions bien plus vite que le modèle processus-par-connexion de Postgres n’a été conçu pour absorber.
3. La formule et la procédure ci-dessus ont déjà été appliquées, et le besoin réel en connexions clientes continue de dépasser ce que la mémoire disponible permet d’allouer sans mettre en danger work_mem ou shared_buffers.

Dans ces trois cas, la bonne réponse est presque toujours un pooler positionné entre l’application et Postgres, pas un max_connections plus élevé. Notre comparatif PgBouncer, Supavisor et PgCat détaille les trois options, et notre guide sur le mode transaction explique le compromis le plus fréquent une fois le pooler en place. Pour l’ensemble des réglages Postgres au-delà des connexions, voir notre checklist de tuning Postgres en production.