Gebruikt iemand Postgres zonder PgBouncer?

Ik kreeg afgelopen weekend een leuke shout-out van Ben Dicken over een oud artikel dat ik had geschreven over het beheren van databaseverbindingen. (Deze man is blijkbaar de Mick Jagger van de databases, want ik kan me niet herinneren dat ik ooit zoveel LinkedIn-uitnodigingen op één dag heb ontvangen.)

Wat me hard raakte, is dat ik dit artikel bijna tien jaar geleden schreef.

Wat minstens zo opvallend is, is dat ik bij het teruglezen merkte dat het, ondanks de leeftijd van een decennium, nog steeds vrijwel actueel is. Postgres is nog steeds, laten we zeggen, niet geweldig in het beheren van veel verbindingen. Je wilt daarom gebruikmaken van lokale connection pools, korte check-out tijden en een pooler zoals PgBouncer.

Het deed me afvragen: hoe standaard is het gebruik van een pooler eigenlijk? Om die vraag te beantwoorden, heb ik een tabel gemaakt van alle bekende managed Postgres-aanbieders en of zij PgBouncer ondersteunen, iets dat erop lijkt, of helemaal geen connection pooling aanbieden.

Niet alleen is de ondersteuning voor PgBouncer wijdverspreid, maar we zien hierboven dat de overgrote meerderheid van de aanbieders het standaard meelevert. Ik zou zelfs een stap verder gaan: aangezien noch IBM noch Oracle diensten zijn die een zelfbewust persoon die geen deel uitmaakt van een enterprise sales-cyclus daadwerkelijk zou gebruiken, levert honderd procent van de plausibele managed Postgres-aanbieders een pooler mee.

Als iedereen het nodig heeft, is het dan echt een niet-kernfunctie?

In zekere zin zou je kunnen beargumenteren dat deze status quo acceptabel is. Gebruikers die een connection pooler nodig hebben, hebben er toegang toe en kunnen dit gebruiken om de productieomgeving stabiel te houden.

Maar er gaat ongetwijfeld veel moeite verloren. Elke aanbieder heeft zijn eigen zelfgebouwde mechanisme moeten bedenken om meerdere componenten op te zetten en te configureren, en een conventie moeten vaststellen voor waar men Postgres vindt ten opzichte van de bouncer. Elke gebruiker moet een handleiding raadplegen die de beperkingen van PgBouncer uitlegt (bijv. geen listen/notify) en lezen over de pooling-modi en de bijbehorende trade-offs.

Stel je voor dat je naar je lokale autodealer gaat en zij verkopen je een auto zonder voorruit. Onderweg had je gemerkt dat 100% van de voertuigen op de weg inderdaad voorruiten hebben, en met een goede reden: het blijkt namelijk behoorlijk gevaarlijk te zijn om zonder één te rijden. Omdat jij degene was die de auto kocht, is het moeilijk om te beargumenteren dat het nu niet jouw verantwoordelijkheid is om hem van een voorruit te voorzien voordat hij wegrijdklaar is, maar het zou ook redelijk zijn om je later doodergernerd te voelen tegenover de dealer omdat hij een voertuig verkocht dat niet simpelweg van het terrein gereden kon worden.

Reïntegratie

Hoe zou het zijn in een wereld waarin je naar je favoriete Postgres-aanbieder gaat en één database-URL krijgt, één poort, en geen extra configuraties of kanttekeningen waar je je zorgen over hoeft te maken? Je managed provider hoeft dan geen voorruit achteraf toe te voegen, omdat deze al bij de auto zat. We weten dat zo'n plek kan bestaan, want zo werken de dingen al in de wereld van MySQL en Mongo.

Er zijn redenen waarom dit niet gebeurt, zoals het nieuw leven inroepen van het eeuwenoude debat over processen versus threads — een discussie waar maar weinig contributors genoeg aanzien voor hebben om vooruitgang af te dwingen. Maar gezien de hoeveelheid ontwikkelaarsjaren aan inspanningen om de beperkingen van Postgres op het gebied van connection pooling te omzeilen, is het moeilijk om te ontkennen dat dit een van de meest impactvolle operationele verbeteringen zou zijn die mogelijk zijn.