The last few PG Phriday articles have been somewhat dense content, so how about something a bit more irreverent? Rather than wax on about AI, HA architectures, or conceptual advancements to Postgres clusters, why not write a game instead? To keep things simple, let’s just build a no-frills Tamagotchi virtual pet for bored database professionals.
There’s a lot of SQL in this article, so check out the git page for this blog if you want to follow along.
Has it really come to this?
AI is everywhere these days
Postgres and AI go together like elephants and chocolate. At first glance, it seems like a silly combination. Postgres is an RDBMS for storing data with ACID compliance, functions, views, and maybe some extensions or foreign data wrappers. Where is room for AI in that? It may be trendy to take something, rub some AI on it, and then declare it a breakthrough technology, but that isn’t necessarily reality.
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.
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.
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:
