Postgres max_connecties zonder pooler

Postgres gebruikt geen lichtgewicht threadpool voor zijn verbindingen. Elke clientverbinding activeert een volwaardig systeemproces.

Het postmaster-proces maakt voor elke verbindingspoging een nieuwe (“fork”), bestemd voor deze enkele sessie totdat deze wordt gesloten. De officiële projectdocumentatie beschrijft precies dit mechanisme in het hoofdstuk over architecturale grondbeginselen (postgresql.org/docs/current/connect-estab.html, sectie “Verbindingssemantiek”, geraadpleegd op 24 augustus 2026).

Deze keuze heeft een echt voordeel: een crash op één verbinding heeft geen invloed op de andere, omdat elk proces geïsoleerd is van de rest van de server. Er zijn ook directe kosten aan verbonden: elke extra verbinding voegt een heel OS-proces toe aan de planning, met zijn eigen geheugenruimte en zijn eigen context-switching-overhead voor de kernel.

Er zijn twee verschillende mechanismen die van invloed zijn op het geheugen, en het verwarren ervan leidt bijna altijd tot een verkeerde diagnose.

De eerste staat vast. Bij het opstarten reserveert Postgres gedeelde geheugenstructuren (sloten, procestabel) op basis van de waarde van max_connections, ongeacht of deze verbindingen vervolgens wel of niet worden geopend. De officiële documentatie voor de instelling wijst er expliciet op: het verhogen ervan kan meer gedeeld systeemgeheugen vereisen dan de standaardconfiguratie van uw besturingssysteem toestaat (postgresql.org/docs/current/runtime-config-connection.html, geraadpleegd op 24 augustus 2026).

De tweede is variabel en veel gevaarlijker op schaal: work_mem wordt niet één keer per verbinding toegewezen, maar één keer per sorteer- of hashbewerking in het queryplan. De officiële documentatie is expliciet op dit punt: een complexe query kan verschillende van deze bewerkingen parallel starten, en verschillende sessies kunnen hetzelfde tegelijkertijd doen, zodat het werkelijk gebruikte geheugen meerdere malen de moeite waard kan zijn work_mem (postgresql.org/docs/current/runtime-config-resource.html, geraadpleegd op 24 augustus 2026).

De officiële PostgreSQL-projectwiki documenteert een benchmarkformule voor het berekenen van hoeveel actieve -verbindingen uw hardware efficiënt parallel kan verwerken, niet hoeveel verbindingen er in totaal geopend zijn (wiki.postgresql.org/wiki/Number_Of_Database_Connections, geraadpleegd op 24 augustus 2026).

Op een server met 8 fysieke cores en SSD-opslag geeft de formule (8 × 2) + 1 = 17 actieve verbindingen voordat de doorvoer begint af te nemen. Dit cijfer is vaak verrassend: het lijkt klein vergeleken met de honderden verbindingen die een applicatie in de praktijk opent. Dit is precies het onderwerp van de volgende paragraaf.

Het getal dat door de formule wordt berekend, meet de gelijktijdigheid die de CPU en schijf kunnen absorberen, niet het aantal clientverbindingen dat uw toepassing moet openen. Een vloot van 20 applicatieprocessen, elk met een eigen pool van 10 verbindingen, opent 200 gelijktijdige verbindingen met Postgres, zelfs als er op een bepaald moment slechts 17 daarvan actief werken. Zonder een pooler moeten max_connections de 200 dekken, niet de 17. Het is deze kloof die de meeste architecturen ertoe aanzet een pooler toe te voegen in transactiemodus, zelfs als dit betekent dat ze moeten kiezen welke (zie onze vergelijking PgBouncer, Supavisor en PgCat).

max_connections is niet hot-swap. Dit is een contextparameter postmaster: Postgres leest deze één keer bij het opstarten, om het gedeelde geheugen te vergroten. Het opnieuw laden van de configuratie (pg_reload_conf() of SIGHUP) is niet voldoende; u moet de server opnieuw opstarten.

Controleer eerst de huidige waarde en de context ervan, om te bevestigen dat een herstart noodzakelijk is:

SHOW max_connections;

SELECT name, setting, context
FROM pg_settings
WHERE name = 'max_connections';

-- context='postmaster' bevestigt dat opnieuw opstarten vereist is

Pas vervolgens de nieuwe waarde toe en start vervolgens opnieuw:

ALTER SYSTEM SET max_connections = '300';

-- Geschreven in postgresql.auto.conf.
-- Geen effect totdat Postgres opnieuw is opgestart.

# Met systemd
sudo systemctl restart postgresql

# Zonder systemd, direct met pg_ctl
pg_ctl restart -D $PGDATA -m fast

Het dimensioneren van max_connections is niet alleen een theoretische oefening. Hier ziet u hoe Aurabase het budgetteert op de beheerde Postgres-clusters:

Toegewijde clusters: één Postgres-cluster per project

Op dit niveau (zie onze vergelijking dedicated versus gedeelde basis), ontvangt elk project zijn eigen CloudNativePG-cluster en zijn eigen max_connections budget, afgestemd op de grootte van de instantie:

Gedeelde clusters: meerdere projecten van een organisatie, een gedeeld budget

Op dit tweede pad zijn alle projecten van dezelfde organisatie verbonden via een CNPG-pooler (PgBouncer, transaction-modus) voor een gedeelde primaire:

Alle projecten in een organisatie zijn met elkaar verbonden via een gedeelde applicatierol. max_user_connections alleen al beperkt daarom het totale aantal serververbindingen dat deze rol in het hele cluster kan openen: dit is de echte cluster-globale beveiliging, niet max_client_conn, die alleen clientverbindingen met de pooler zelf beperkt.

Deze pooler bedient echter alleen SDK-applicatieverkeer. PostgREST blijft op zijn beurt rechtstreeks verbonden met de primaire (-rwservice): poolen in de transactiemodus zou het herlaadmechanisme van het schema verbreken, dat luistert naar een speciaal LISTEN kanaal met de naam pgrst. De eigen verbindingen (2 per replica op het gedeelde niveau, 10 per replica op het speciale niveau) tellen daarom direct mee in het max_connections budget van de primaire, buiten welke pooler dan ook, precies het soort “vergeten” verbinding dat stap 1 van de onderstaande procedure moet omvatten.

Deze procedure is niet afhankelijk van een bepaald hulpmiddel: het is van toepassing op elke Postgres-server, beheerd of zelfgehost.

1. Tel uw daadwerkelijke clientverbindingen. Aantal applicatieprocessen vermenigvuldigd met de grootte van hun interne pool, plus beheertools, replicatie en monitoring. Het is dit getal, en niet de formule, dat de max_connections-vloer bepaalt.
2. Bereken de ideale gelijktijdigheid van uw hardware met de formule uit de PostgreSQL-wiki: (fysieke kernen × 2) + efficiënte schijven. Dit cijfer geeft aan hoeveel van deze verbindingen feitelijk parallel kunnen werken zonder de doorvoer te verminderen.
3. Stel max_connections in boven de daadwerkelijke behoefte voor stap 1, met marge voor superuser_reserved_connections en voor eventuele beheerderstools die hun eigen verbindingen buiten de applicatie openen.
4. Pas de wijziging toe met ALTER SYSTEM SET en start vervolgens de server opnieuw op. Dit is een postmasterparameter: eenvoudig herladen is niet voldoende, zoals hierboven beschreven.
5. Controleer pg_stat_activiteit in de loop van de tijd. Als het aantal inactieve verbindingen het aantal actieve verbindingen aanzienlijk overschrijdt, is dit geen max_connections-probleem: het is het signaal dat u een pooler vóór de server nodig heeft, niet een hoger aantal.

Het monitoringverzoek uit stap 5, direct bruikbaar:

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

Drie signalen keren systematisch terug wanneer max_connections alleen niet langer voldoende is, wat de waarde ervan ook is.

1. De FATAL: sorry, too many clients already-fout verschijnt tijdens piekbelasting, terwijl de meerderheid van de verbindingen die door pg_stat_activity worden weergegeven zich in de inactieve status bevinden.
2. De applicatie draait in een serverloze omgeving of met tijdelijke werkers (edge-functies, korte taken), die verbindingen veel sneller openen en sluiten dan waarvoor het proces-per-verbinding-model van Postgres was ontworpen.
3. De bovenstaande formule en procedure zijn al toegepast, en de werkelijke behoefte aan clientverbindingen blijft groter dan wat het beschikbare geheugen kan toewijzen zonder werkgeheugen of gedeelde buffers in gevaar te brengen.

In deze drie gevallen is het juiste antwoord bijna altijd een pooler die tussen de applicatie en Postgres is geplaatst, en niet een hogere max_connections. Onze vergelijking PgBouncer, Supavisor en PgCat beschrijft de drie opties, en onze gids voor transactiemodus legt de meest voorkomende compromissen uit zodra de pooler eenmaal is geïnstalleerd. Voor alle Postgres-tuning die verder gaat dan verbindingen, zie onze productie Postgres-tuningchecklist.