One of the job prospects I was interviewing with presented me with a question last week:

“We’d like to schedule a final culture interview with you, but before we do, we were wondering if you would entertain a contractor role?”

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?”

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.

When it comes to reordering the items in a list, databases have long had a kind of Faustian Bargain to accomplish the task. Nobody really liked any of the more common solutions, least of all the poor database tasked with serving up the inevitable resulting hack.

Postgres is no different in this regard. Consider a list_item table like this, demonstrating five items in a to-do list: