Please use this identifier to cite or link to this item: https://repositorio.ufu.br/handle/123456789/49993
Full metadata record
DC FieldValueLanguage
dc.creatorMoreira, Jean Souto Galvão-
dc.date.accessioned2026-09-01T14:56:11Z-
dc.date.available2026-09-01T14:56:11Z-
dc.date.issued2026-07-31-
dc.identifier.citationMOREIRA, Jean Souto Galvão. Connection pooling em PostgreSQL: caracterização empírica do ponto de equilíbrio entre sobrecarga e contenção. 2026. 63 f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) – Universidade Federal de Uberlândia, Uberlândia, 2026.pt_BR
dc.identifier.urihttps://repositorio.ufu.br/handle/123456789/49993-
dc.descriptionCódigo-fonte, infraestrutura e informações do experimento disponíveis em: https://github.com/jean-souto/postgres-pooler-benchmark-tccpt_BR
dc.description.abstractPostgreSQL database systems suffer severe performance degradation under high connection concurrency, owing to their process-per-connection model and contention in internal locking structures. Connection poolers are the industry-standard mitigation, but the decision to adopt one usually rests on heuristics rather than quantitative evidence, since there is no public characterization of the concurrency point beyond which a pooler offsets the overhead it introduces. This work investigates that transition through a controlled empirical analysis of six connection configurations over PostgreSQL 18 in an AWS cloud environment: a direct connection (baseline), PgBouncer and PgCat in transaction and session modes, and AWS RDS Proxy. Across 1,332 trials, the workload, query mode, concurrency, and pool size were varied, with instrumentation of both the client and the server internals. The results indicate a break-even point: at low concurrency the pooler merely adds latency; beyond a few dozen clients (about 30 under the write workload), the direct connection collapses under contention while the pooler keeps throughput stable. Server-side instrumentation attributes this gain to reduced internal lock contention rather than to a lower connection cost. The multi-threaded pooler (PgCat) outperforms the single-threaded one (PgBouncer) only when the pooler itself becomes the critical resource, and managed pooling (RDS Proxy) shows a lower throughput ceiling than the self-hosted alternatives. The study provides an open, reproducible characterization of this break-even for PostgreSQL, grounded in causal evidence collected at the server.pt_BR
dc.languageporpt_BR
dc.language.isopt_BRpt_BR
dc.publisherUniversidade Federal de Uberlândiapt_BR
dc.rightsAcesso Abertopt_BR
dc.subjectPostgreSQLpt_BR
dc.subjectConnection poolingpt_BR
dc.subjectPgBouncerpt_BR
dc.subjectPgCatpt_BR
dc.subjectContenção de lockspt_BR
dc.subjectComputação em nuvempt_BR
dc.subjectLock contentionpt_BR
dc.subjectCloud computingpt_BR
dc.titleConnection pooling em postgresql: caracterização empírica do ponto de equilíbrio entre sobrecarga e contençãopt_BR
dc.title.alternativeconnection pooling in postgresql: empirical characterization of the break-even point between overhead and contentionpt_BR
dc.typeTrabalho de Conclusão de Cursopt_BR
dc.contributor.advisor1Lima, Maria Adriana Vidigal de-
dc.contributor.advisor1Latteshttp://lattes.cnpq.br/0532686872124118pt_BR
dc.contributor.referee1Fernandes, Márcia Aparecida-
dc.contributor.referee1Latteshttp://lattes.cnpq.br/8946715881289701pt_BR
dc.contributor.referee2Araújo, Rafael Dias-
dc.contributor.referee2Latteshttp://lattes.cnpq.br/3067137114142725pt_BR
dc.description.degreenameTrabalho de Conclusão de Curso (Graduação)pt_BR
dc.description.resumoSistemas de banco de dados PostgreSQL sofrem degradação severa de desempenho sob alta concorrência de conexões, em razão do modelo process-per-connection e da contenção em estruturas internas de locking. Os connection poolers são a mitigação padrão da indústria, mas a decisão de adotá-los costuma se apoiar em heurísticas, e não em evidência quantitativa, pois falta uma caracterização pública do ponto de concorrência a partir do qual o pooler compensa a sobrecarga que introduz. Este trabalho investiga essa transição por meio de uma análise empírica controlada de seis configurações de conexão sobre PostgreSQL 18 em nuvem AWS: conexão direta (baseline), PgBouncer e PgCat nos modos transaction e session, e o AWS RDS Proxy. Ao longo de 1.332 ensaios, variaram-se a carga de trabalho, o modo de query, a concorrência e o tamanho do pool, com instrumentação não apenas do cliente, mas também do interior do servidor. Os resultados indicam a existência de um ponto de equilíbrio: em baixa concorrência, o pooler apenas acrescenta latência; acima de algumas dezenas de clientes (cerca de 30 na carga de escrita), a conexão direta colapsa por contenção, enquanto o pooler mantém a vazão estável. A instrumentação do servidor atribui esse ganho à redução da contenção interna de locks, e não a um custo de conexão menor. A arquitetura multi-thread (PgCat) só supera a single-thread (PgBouncer) quando o próprio pooler se torna o recurso crítico, e o pooling gerenciado (RDS Proxy) apresenta teto de vazão inferior ao das alternativas auto-hospedadas. O estudo oferece uma caracterização aberta e reprodutível desse ponto de equilíbrio para PostgreSQL, sustentada por evidência causal coletada no servidor.pt_BR
dc.publisher.countryBrasilpt_BR
dc.publisher.courseCiência da Computaçãopt_BR
dc.sizeorduration63pt_BR
dc.subject.cnpqCNPQ::CIENCIAS EXATAS E DA TERRA::CIENCIA DA COMPUTACAO::METODOLOGIA E TECNICAS DA COMPUTACAO::BANCO DE DADOSpt_BR
Appears in Collections:TCC - Ciência da Computação

Files in This Item:
File SizeFormat 
connection-pooling-postgresql (1).pdf6.35 MBAdobe PDFView/Open


Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.