Last Phriday we explored just where Postgres could end up in the future. One possible question which may have occurred to a reader was probably something along the lines of “That doesn’t even really sound like Postgres anymore. Why not just write another database?”
Let’s just be outright about it: Postgres is the best RDBMS engine currently available. It’s certainly bold to claim that any database engine is “the best”, and as the saying goes, “Extraordinary claims require extraordinary evidence.
With my newfound “free time”, I’ve spent a lot of time catching up on my writing. Two PG Phridays in a row, and I have ideas for many more to come. I finally decided to “Open Source” my homelab setup, and since that’s a work-in-progress, it should see many commits in the future. And I finally started earnestly working on the ol’ home lab. Definitely keeping myself busy!
What is High Availability to Postgres? I’ve staked my career on the answer to that question since I first presented an HA stack to Postgres Open in 2012, and I still don’t feel like there’s an acceptable answer. No matter how the HA techniques have advanced since then, there’s always been a nagging suspicion in my mind that something is missing.
But I’m here to say that a bit of research has uncovered an approach that many different Postgres cloud vendors appear to be converging upon.
Postgres is one of those database engines that carves out a niche and garners adherents with various levels of religious zeal. The community, while relatively small when compared to that of something like MongoDB, is helpful almost to a fault. Members from the freshest minted newb to the most battle tested veteran will often trip over themselves to answer questions found in the various dedicated forums, mailing lists, and chat rooms.
The Postgres system catalog is a voluminous tome of intriguing metadata both obvious and stupendously esoteric. When inheriting a Postgres database infrastructure from another DBA, sometimes it falls upon us to dig into the writhing confines to derive a working knowledge of its lurking denizens. The trick is to do this before they burst forth and douse us with the database’s sticky innards and it experiences a horrible untimely demise.
