TechOps Examples

Hey — It's Govardhana MK 👋

Welcome to another technical edition.

Every Tuesday – You’ll receive a free edition with a byte-size use case, remote job opportunities, top news, tools, and articles.

Every Thursday and Saturday – You’ll receive a special edition with a deep dive use case, remote job opportunities, and articles.

👋 👋 A big thank you to today's sponsor THE DEEP VIEW

If you’re a decision maker at your company, you need to be on the bleeding edge of, well, everything. But before you go signing up for seminars, conferences, lunch ‘n learns, and all that jazz, just know there’s a far better (and simpler) way: Subscribing to The Deep View.

This daily newsletter condenses everything you need to know about the latest and greatest AI developments into a 5-minute read. Squeeze it into your morning coffee break and before you know it, you’ll be an expert too.

Subscribe right here. It’s totally free, wildly informative, and trusted by 600,000+ readers at Google, Meta, Microsoft, and beyond.

Powered by: Jobsurface.com

Browse 691 Worldwide Jobs Here →

Looking to promote your company, product, service, or event to 48,000+ Cloud Native Professionals? Let's work together. Advertise With Us

Every database has a hard limit on how many simultaneous connections it can hold open. PostgreSQL defaults to 100. MySQL defaults to 151. These numbers sound comfortable until you deploy a microservices architecture on Kubernetes with 50 pods each maintaining their own connection pool of 10 connections. Suddenly you are at 500 connections before a single user has made a request. The database starts rejecting connections. Pods log cryptic errors. The on-call engineer spends their evening reading connection timeout stack traces.

It is the default outcome when teams deploy to Kubernetes without understanding how database connections behave in a containerized, horizontally scaling environment.

A database connection is a persistent, stateful network socket between your application process and the database server. Establishing one is expensive. The client and server perform a TCP handshake, the database authenticates the credentials, negotiates the session parameters, allocates memory for the connection context on the server side, and registers the connection in its internal process table. On PostgreSQL, each connection spawns a dedicated backend process. This overhead takes 20 to 50 milliseconds under normal conditions, which is an eternity in the context of a query that should take 2 milliseconds.

If every database query opened a fresh connection, used it once, and closed it, your application would spend more time establishing connections than executing queries. Connection pooling solves this by keeping a set of connections open and reusing them across multiple requests.

A connection pool is a cache of open database connections maintained so that they can be reused when future requests need database access. Instead of opening and closing a connection for every query, the application borrows a connection from the pool, uses it, and returns it when finished. The connection stays open and available for the next borrower.

When a client makes an API call, the application checks the pool for a free connection. If one is available, it is borrowed immediately. If no free connection exists, the pool manager either creates a new connection up to the configured maximum or queues the request to wait for a connection to be returned. Once the query completes, the connection returns to the pool marked as free.

Here are four patterns you’ll often see in production:

🔴 Get my DevOps & Kubernetes ebooks! (free for Premium Club and Personal Tier newsletter subscribers)