When it comes to putting Postgres through its paces, we often turn to benchmarks to absolutely bury it under a torrent of oppressive activity. It’s a great way to obtain maximum performance metrics and also observe how Postgres reacts and breaks down under such pressure. But these kinds of tests aren’t really practical, are they? After all, many such simulated workloads are nothing but bragging rights measured against previous Postgres releases, or for hardware comparisons.

There seem to be quite a few popular Postgres conferences peppering the globe these days. This year, Simon Riggs of 2ndQuadrant gave the sponsored keynote at Postgres Open. I’m not entirely sure it was intentional since it wasn’t the title of his presentation, but he uttered the words “working together to make Postgres better for everyone” at one point. The phrase “Working Together” really stood out, because that’s a significant part of what makes Postgres so great.

There’s a bit of loneliness in the world, I think. But not the kind we’ve all come to recognize. Not the feeling that we are alone, unknowable, or otherwise separated from our peers. It’s something I never expected to encounter, and yet that’s exactly what makes it so penetrating. It’s a kind of emotional nostalgia, and the realization that the novelty of life itself is fleeting. I used to wonder what adults thought to themselves as they watched us play and grow, forever discovering, always surprised and delighted or perturbed.

Say hi to Princess Kittybutt. She’ll be our mascot (and subject) for today. We’ll get to her in a minute. When the only tool you have is a hammer, everything becomes a nail, right? With Postgres becoming more of an environment than simply a database engine, this colloquialism is starting to resemble reality. Of course, that’s not necessarily a bad thing! As Postgres accumulates copious and varied extensions, its role as an adaptive middleware solidifies.

It’s no surprise Postgres does more than merely store data; you can’t do everything with SQL. Often, it’s often more beneficial to process data locally without transmitting it to a client interface. Local manipulation can save hours in network traffic alone, let alone client-side allocation and per-row processing. Databases like Postgres are specifically for bulk data operations, so why not take advantage? But doing that requires functions—anonymous or otherwise—and a Turing-complete language to write them with.