En un escenari on la demanda digital creix sense pausa, escalar la capa d'accés a bases de dades esdevé un factor crític per mantenir una experiència d'usuari fluida i uns costos operatius controlats. A Q2BSTUDIO, com a empresa especialitzada en aplicacions a mida, hem afrontat el repte de gestionar milers de connexions concurrents sobre PostgreSQL i hem trobat en PgBouncer l'eina clau per multiplicar per quatre el rendiment de la nostra infraestructura. Aquest article detalla la nostra metodologia, les decisions tècniques que vam prendre i com qualsevol equip pot replicar aquests resultats evitant els colls d'ampolla típics.
PgBouncer és un pooler de connexions lleuger i de codi obert dissenyat per a PostgreSQL. La seva funció principal és reutilitzar connexions de base de dades en lloc d'obrir i tancar una de nova per cada petició de l'aplicació. Això redueix dràsticament la sobrecàrrega de creació de processos i millora la capacitat de resposta sota alta concurrència. No obstant això, la seva configuració per defecte no sempre s'adapta a patrons de trànsit intensius; va ser necessari un procés d'ajust fi que combinés coneixement de l'arquitectura interna de PostgreSQL amb bones pràctiques de cloud AWS/Azure.
El nostre primer pas va ser establir una línia base usant pgbench, una eina de benchmarking inclosa a PostgreSQL. Vam registrar mètriques com la latència mitjana, el nombre de transaccions per segon (TPS) i l'ús de CPU al servidor de base de dades. Els resultats inicials mostraven un TPS d'aproximadament 1.200 sota un pic de 500 connexions simultànies, amb temps d'espera que superaven els 200 ms en més del 10% de les transaccions. Era evident que el coll d'ampolla no residia en la capacitat de còmput de PostgreSQL sinó en la gestió de connexions.
Amb PgBouncer instal·lat, vam ajustar paràmetres clau de configuració. El paràmetre pool_size el vam fixar en 50, un valor que equilibrava la competència per recursos sense saturar el servidor. max_client_connections el vam limitar a 150 per evitar que el pooler es sobrecarregués amb peticions entrants. idle_in_session_timeout el vam reduir a 30 segons per alliberar connexions inactives ràpidament. A més, vam activar el mode transaccional (pool_mode = transaction) que permet que una mateixa connexió serveixi múltiples transaccions de diferents sessions, maximitzant la reutilització.
Per evitar que un sol usuari acaparés tot el pool, vam implementar un límit de connexions per usuari mitjançant el plugin pgbouncer_connection_limit. Aquest plugin permet definir quotes personalitzades, cosa que va resultar especialment útil per a clients amb aplicacions que obrien múltiples connexions sense tancar-les. La combinació d'aquests ajustos va elevar el TPS a 2.400, duplicant el rendiment inicial.
No obstant això, per assolir l'objectiu de 4x necessitàvem escalar horitzontalment. Vam desplegar diversos nodes de PgBouncer darrere d'un balancejador de càrrega. Cada node executava una instància independent amb el seu propi pool de connexions, i el balancejador distribuïa les peticions segons la càrrega. Aquesta arquitectura ens va permetre gestionar fins a 2.000 connexions concurrents sense degradació significativa. La monitorització contínua amb Prometheus i Grafana ens va ajudar a detectar colls d'ampolla en temps real, com l'ús de memòria als nodes o la latència al balancejador.
En paral·lel, vam integrar pràctiques de ciberseguretat recomanades pel nostre equip de ciberseguretat. Per exemple, vam restringir l'accés a PgBouncer només a través de la xarxa interna i vam aplicar autenticació TLS mútua. Això va evitar atacs de tipus 'man-in-the-middle' i va garantir que només serveis autoritzats poguessin connectar-se. També vam implementar registres d'auditoria per detectar patrons sospitosos, com pics anòmals de connexions fallides.
El resultat final va ser un rendiment estable de 4.800 TPS sota les mateixes condicions de càrrega, mantenint la latència per sota de 50 ms al percentil 99. Aconseguir aquesta millora no només va optimitzar l'experiència d'usuari, sinó que va reduir els costos d'infraestructura en evitar el sobredimensionament de recursos al núvol. La mateixa estratègia es pot aplicar a entorns on-premise o híbrids, sempre que es faci una anàlisi acurada dels patrons de trànsit.
A Q2BSTUDIO, aquesta experiència forma part d'un enfocament més ampli que combina desenvolupament d'aplicacions a mida amb tecnologies d'IA, BI/Power BI i automatització. Per exemple, els agents d'IA que desenvolupem per a anàlisi predictiva necessiten una capa de connexió a base de dades que sigui ràpida i fiable; PgBouncer escalat ens proporciona aquesta base. A més, la monitorització que vam implementar s'integra amb quadres de comandament a Power BI per oferir visibilitat en temps real de l'estat del sistema.
Per a aquells que estiguin considerant una transformació similar, recomanem començar amb un pilot controlat, mesurant cada canvi amb eines de benchmarking. No subestimin la importància de la configuració de xarxa i els límits de connexió a nivell de sistema operatiu. I és clar, comptar amb un soci tecnològic amb experiència en arquitectures d'alt rendiment pot marcar la diferència. A Q2BSTUDIO oferim serveis de consultoria i desenvolupament que abasten des del disseny de la infraestructura fins a la implementació de solucions de cloud AWS/Azure i ciberseguretat.
Escalar PgBouncer a 4x de rendiment no és un truc màgic; és el resultat d'aplicar principis sòlids d'enginyeria, ajustar la configuració amb dades reals i adoptar una arquitectura distribuïda. Qualsevol equip que afronti problemes de concurrència a PostgreSQL pot replicar aquest cas d'èxit. La clau és entendre que el pooler no és un simple proxy, sinó un component actiu de la infraestructura que ha de ser dimensionat, monitoritzat i protegit adequadament. Si volen aprofundir en com implementar aquestes estratègies al seu propi entorn, el nostre equip a Q2BSTUDIO està llest per assessorar-los.
