Philly Postgres

We've all seen a little too much AI in LinkedIn posts; AI slop has even become a new classification option on LinkedIn.
AI is an amazing tool to make things in your life better, but it has serious consequences and problems.
This talk will show some of the good things, bad things, and how we should move forward to improve human connection in the future.
If you have felt a little overwhelmed recently with AI in your world come join us for a great discussion on things you can do to feel better.

Coding agents don’t need better instructions. They need a tighter feedback loop.

This session shows how to build that loop directly into Postgres. We’ll use `pgpm`, a Postgres package manager, to turn schemas into composable, versioned modules with deterministic dependencies, then test them against the real database with `pgsql-test` — including roles, permissions, functions, constraints, and RLS.

From there, we close the loop: write → test → fix → push → CI/CD.

That changes the role of testing. Tests are no longer just something humans run before shipping; they become the control system for coding agents. An agent can generate code quickly, but the database provides the deterministic signal for whether that code is actually correct.

| We’ll build a modular schema live, let an agent extend it, and let the tests decide what ships |
| ---------------------------------------------------------------------------------------------- |
|

What new PostgreSQL features are you exploring, and which ones are actually changing how you work?
Join the conversation to compare what people are testing, adopting, or still figuring out across newer Postgres releases.

Trusting Postgres to store data is one thing; trusting it to coordinate work is another. This talk walks through the design we settled on — commit the durable fact inside the transaction, fire side effects after commit, and rebuild the job queue from committed rows so the chain is always the source of truth — and the real failure modes we hit getting there: an advisory-lock self-deadlock that Postgres's own detector couldn't see (half the wait cycle lived in the application), pg-boss semantics that didn't mean what we assumed, and MVCC read-then-write races. For each: the reproduction, the root cause, and the structural guard that keeps it from recurring. Because AI agents wrote and tested much of this, the talk also covers where that helped, where it quietly didn't, and the testing discipline we adopted as a result.
What you'll take away:

• A durable coordinator pattern: commit-in-transaction, side-effects-after-commit, queue reconstructable from committed rows
• Concrete concurrency failure modes on Postgres — advisory-lock scope, pg-boss singleton/priority semantics, MVCC visibility — and how to design them out
• Why the structural guard, not the one-off fix, is what makes correctness stick
• What building and testing with AI agents got right, and what needed guardrails