More than a refresh: Conversations with the most interesting people you've never met

In the final part of "When Postgres Is Enough," Michael Cooper and JD discuss how AGLedger is adapting a PostgreSQL-based application for agents that move quickly, anticipate next steps, and may not follow the same process twice. A workflow that works with a simpler agent can expose gaps when a more capable model begins skipping steps.Michael explains why probabilistic agents need deterministic systems around them. PostgreSQL gives AGLedger the flexibility to change schemas as agent behavior evolves while still enforcing consistent rules around the shape of its records and data.They also look at the next stage of AGLedger: storing an agent’s working context in real time. That raises practical questions about what belongs in the encrypted ledger, what should remain available as agent memory, and what can be temporary or deleted.The episode closes by defining what it means for an agent to work faster. It is not simply about using more tokens. The real measure is how quickly an incoming request becomes a completed decision or action.🔗 Michael Cooper: https://www.linkedin.com/in/michaeldc/🔗 AGLedger: https://www.linkedin.com/company/agledger/

Serving a query from cache gets more complicated when PostgreSQL still needs to know which statements have been prepared and bound. For James Nelson, founder and CTO of PgCache, keeping that state consistent is what makes the extended query protocol his Postgres pet peeve.In this installment of Postgres Pet Peeves, James explains how his caching proxy tracks prepared statements and forwards preparation messages to PostgreSQL when they become necessary. A wrong message or response can put the connection out of sync and cause it to be terminated. He and JD explore that coordination work, along with how PgCache falls back to PostgreSQL when needed and exposes its internal behavior through Prometheus metrics.The conversation also turns to PgCache’s source-available license and the trade-off between protecting a business and encouraging outside contributions. James shares why he and his co-founder chose a more restrictive starting point, while JD makes the case for a permissive open source license.

Why does current AI need so much compute to produce an answer?In episode three of “Better AI,” our six-part series from More Than a Refresh Presents: T3D Sessions, Reza Rassool of Kwaai and JD Drake begin a two-part look at faster AI. They compare current neural networks with biological intelligence, which can learn while thinking and make a fast initial decision without processing every detail first.Reza explains that current AI separates training from inference and passes input through multiple layers before producing a result. The connections between those layers can cause computation to grow quadratically as inputs expand, while larger context windows add further load.He also contrasts human memory with LLM weights, where a specific fact cannot be located and edited directly. The episode closes with Kwaai’s research into the “blink transform,” an approach intended to change the relationships within a neural network so computation grows linearly rather than quadratically as the network increases in size.Learn more about Kwaai and its work at https://kwaai.ai.

EXPLAIN shows the query plan, but understanding why PostgreSQL chose it can take more digging. Testing how a database will behave under a real workload brings its own challenges, especially when a benchmark doesn’t reflect the application you support.In this Postgres Wishlist episode, Hunter O’Brien, Junior Systems Administrator and Junior DBA at Command Prompt, joins JD to talk through the tools he wishes were easier to use. His experience adapting pgbench tests leads to a conversation about reproducing application workloads and the complications of using production data in a test environment. On query plans, he wants clearer EXPLAIN documentation and more insight into the planner’s decisions.Hunter also wants a quick way to generate an entity relationship diagram (ERD) when working with unfamiliar schemas, particularly when the best documentation is a busy senior developer. Some of these needs have existing tools or workarounds; the challenge is making them practical for everyday database work.

In Part 2 of "When Postgres Is Enough", Michael Cooper and JD examine what it took for AgLedger to trust PostgreSQL with work previously split between PostgreSQL and Valkey.Supporting two databases meant maintaining separate schemas, backups, restores, and state that had to stay coordinated. PostgreSQL did not need to outperform Valkey at every task. It only needed to handle AgLedger’s workload well enough to make the second system unnecessary.Michael explains how pg-boss allowed him to move queue and rate-limiting work into PostgreSQL, and why managing connections became a more important constraint than memory. He also describes a three-hour test that subjected the system to multiple AI agents, interruptions, mutations, and adversarial attacks. PostgreSQL continued handling the workload without issue.The conversation also covers RDS IOPS, long-running snapshots, database bloat, and vacuum behavior. Once Michael trusted PostgreSQL as more than a place to store data, he began moving more schema and record structure out of application code and into the database, reducing recompilation work and making customer deployments more flexible.This episode explores the point where PostgreSQL stops being only the database and becomes the system coordinating the application around it.