# connection pool A connection pool maintains reusable database connections so applications or threads can obtain and return them as needed. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Connection pool sizing is a queueing theory problem, not a tuning knob DevFeed: [Connection pool sizing is a queueing theory problem, not a tuning knob]() Original publisher: [Read original article]() Author: hello@ankit-rana.com Published: 2026-08-22T00:00:00Z Content type: article Language: en Sources: [Ankit Rana | Mechanical Sympathy]() Topics: [connection pool](), [queueing theory](), [Latency](), [Database](), [Concurrency]() Tags: [capacity-planning](), [concurrency](), [connection-pool](), [cpu](), [database](), [database-performance](), [hikaricp](), [inference](), [latency](), [network](), [postgresql](), [query](), [queueing-theory]() ### AI overview This article explains how to size a connection pool using Little's law: concurrency equals throughput multiplied by connection holding time. It argues that increasing the pool beyond the database's parallel execution capacity can move the queue, increase latency, and leave throughput flat. It also identifies excessive holding time from network round trips, N+1 queries, long transactions, and model inference calls as common causes of pool exhaustion. ### Source excerpt Pool size follows from Little's law: concurrency equals throughput multiplied by holding time, so 500 requests per second each holding a connection for 20ms needs ten connections rather than a round number someone picked. Past the point where the database can execute requests in parallel, adding connections moves the queue rather than removing it, and latency grows while throughput stays flat. The number that actually reaches the database is the pool size multiplied by the instance count, which is usually the number nobody has calculated. ## Promotions are Proactive: The 3P Framework for Pitching Your Next Level DevFeed: [Promotions are Proactive: The 3P Framework for Pitching Your Next Level]() Original publisher: [Read original article]() Author: hello@ankit-rana.com Published: 2026-08-02T00:00:00Z Content type: opinion Language: en Sources: [Ankit Rana | Mechanical Sympathy]() Topics: [Back end](), [Latency](), [Caching](), [connection pool](), [migration]() Tags: [backend](), [caching](), [career](), [career-growth](), [connection-pool](), [engineering](), [latency](), [leadership](), [migration](), [scope](), [system-design]() ### AI overview This article presents the 3P framework--Problem, Proof, and Proactive pitch--for making an engineer's promotion case legible before review. It argues that promotion reflects the scope or blast radius of decisions, supported by system evidence and an explicit pitch. ### Source excerpt Promotion committees do not promote effort, they promote scope, and scope has to be legible before the vote rather than explained after it fails. Strip the leveling-guide language and the question is blast radius: a mid-level engineer's bad call fails one deploy unit, a senior's saturates a pool at 2 AM across teams. The 3P framework makes that visible: Problem at org scale, Proof in system metrics, and a Proactive pitch. ## AI agents break connection pooling by holding the slot while they think DevFeed: [AI agents break connection pooling by holding the slot while they think]() Original publisher: [Read original article]() Author: hello@ankit-rana.com Published: 2026-03-21T00:00:00Z Content type: article Language: en Sources: [Ankit Rana | Mechanical Sympathy]() Topics: [connection pool](), [Artificial Intelligence](), [Large Language Model](), [Latency](), [Databases](), [PostgreSQL](), [Back end]() Tags: [agents](), [ai](), [ai-agents](), [concurrent](), [connection-pool](), [connection-pooling](), [databases](), [latency](), [llm](), [performance](), [postgresql]() ### AI overview This article explains how AI agents can exhaust database connection pools by holding connections during LLM inference. It describes the resulting queueing and latency problems, including cases where the database remains lightly loaded, and recommends releasing the connection before calling the model. ### Source excerpt Connection pooling assumes an implicit contract that transactions stay microscopic, roughly 50 ms of database time per request. An agent that holds a pooled connection while waiting 3 to 5 seconds for LLM inference breaks that assumption: 100 concurrent agents can occupy every slot in a 100-connection pool while the database sits at 2 percent CPU. Fetch, release the connection immediately, then call the model asynchronously. ## Postgres and Connection Pooling DevFeed: [Postgres and Connection Pooling]() Original publisher: [Read original article]() Author: Map Published: 2014-05-22T20:55:56Z Content type: tutorial Language: en Sources: [Craig Kerstiens]() Topics: [connection pool](), [Databases](), [Object-relational mapping](), [SQLAlchemy](), [Django](), [Rails](), [Ruby](), [SSL]() Tags: [connection-pool](), [connection-pooling](), [database](), [django](), [orm](), [postgres](), [postgresql](), [python](), [rails](), [ruby](), [sqlalchemy](), [ssl]() ### AI overview A primer on database connection pooling explains how pooled, persistent, and standalone connections reduce connection-establishment overhead, including SSL negotiation. It discusses framework support in Ruby, Python, Rails, and Django, and notes Postgres connection and memory considerations. ### Source excerpt Connection pooling is quickly becoming one of the more frequent questions I hear. So here's a primer on it. If there's enough demand I'll follow up a bit further with some detail on specific Postgres connection poolers and setting them up. The basics For those unfamiliar, a connection pool is a group of database connections sitting around that are waiting to be handed out and used. This means when a request comes in a connection is already there whether in your framework or some other pooling process, and then given to your application for that specific request or transaction. In contrast, without any connection pooling your application will have to reach out to your database to establish a connection. While in the most basic sense you may thinking connecting to a database is quick, often theres some overhead here. An example is SSL negotiation that may have to occur which means you're looking at not 1-2 ms but often closer to 30-50. The options There's really two major options when it comes to connection pooling: Framework pooling Standalone pooler Persistent connections Framework pooling Today many modern application frameworks have at least some basic level of connection pooling. This means as your application server starts up it will create a pool of connections to use. It's worth noting that while most modern frameworks have pooling, not all do, and further it may not be enabled by default. If you're using the Sequel ORM for Ruby or SQLAlchemy for Python you're well covered here. Further Rails is in pretty good shape also, though you may want to configure the pool size. For Django it's a bit of a mixed story. For some time Django did not have pooling at all. As of Django 1.6 you now have persistent connections by default and the ability to enable a pool. Persistent connections Persistent connections don't offer all of the benefits of pooling, but can often work well enough. Persistent connections is the act of maintaining a connection to your database once it's