Skip to content

Newsletter

Was it the model, or just a fresh pass?

So I started a newsletter. The short version: I needed a place to keep my writing muscle from atrophying, and somewhere to put the takes that don't have an obvious home anywhere else. This isn't a Tiger Data thing, it's just me. Let's get into it.


Everybody's got a multi-model review workflow now. You write the code with one model, then you hand it to a different one and tell it to review. Or you run it through three of them and let them argue. And it works. Stuff gets caught. Bugs you'd have shipped get flagged before they ever leave your machine. The going theory is that different models have different blind spots, so swapping models swaps the blind spots, and the second model sees what the first one couldn't.

Maybe. But I'm not convinced it's the model switch doing the work.

I've run the same model twice. Once to write, once to review, with a prompt that says "your job is to find what's wrong here." Fresh agent, fresh context, no memory of having just confidently written the thing. And it catches stuff. Same model. The only thing that changed was the framing and the clean context window. So when a different model surfaces a problem, was it the different model? Or was it just a second pass with fresh eyes and a different job? Switching models doesn't remove the fresh-context variable. It rides on top of it. Which is exactly why the workflow keeps working and why nobody questions the story they're telling about why.

I've seen this movie before.

Back in the config management days, there was a whole genre of conference talk that went "we moved from Chef to Ansible and everything got better, because Ansible is good and Chef is bad." And no, dude. It got better because the Ansible rollout was version two of your config management strategy, and you were smarter the second time. You'd already made the mistakes once. You could've gotten the same wins without changing platforms. The tool got the credit that the second attempt earned. Same story with half the DevOps transformations I watched, and most of the database migrations where the new engine "fixed everything." Sometimes it did. Often you just rebuilt the thing with everything you learned the first time.

To be clear, I'm not saying don't switch models. The workflows are good. Keep using them. If swapping to a second model is what makes you actually run the review, then the swap is doing real work, just not the work you think.

Be honest about what's actually doing the lifting. Because if you believe it's the model, you'll pay for three of them when a fresh context window and a different prompt would've gotten you most of the way there.


Staged Changes

Postgres 19, quietly: Everybody wants the headline feature and PG19's real wins are the boring operational ones. The 32-bit MultiXact ceiling that has taken down actual production clusters is just gone. REPACK CONCURRENTLY kills the "schedule a window and pray" maintenance dance. And pg_plan_advice finally lets you pin a query plan without bolting on third-party tooling. None of it will trend on Hacker News. All of it will save somebody's weekend. (Bytebase has a good rundown.)

The "AI era" thing: Microsoft published a piece called "PostgreSQL enters its AI era," and look, Postgres didn't enter anything. People started putting vectors in the database they already had, which is the most Postgres thing that could possibly happen. The genuinely useful news buried in that post is unglamorous infra: decoupled storage IOPS and cascading read replicas. The vectors were always going to end up in Postgres. The storage getting cheaper to run is the part worth reading.

Pick the constraint, not the algorithm: There's a Tiger Data post on vector index tradeoffs (full disclosure, that's us) that gets one thing very right: you don't choose HNSW vs IVFFlat vs DiskANN by which algorithm is coolest. You choose by whichever constraint your workload hits first, memory or recall or write volume or filter selectivity. The algorithm beauty contest is a distraction. The binding constraint is the actual question.


Untracked

This is shaping up to be a stupidly good stretch of live music. I caught Weird Al this week, saw Panic Shack a couple weeks back, and September is going to be a full-on pileup. My wife and I have Bikini Kill, Sleater-Kinney with Liz Phair, Lambrini Girls, and then Riot Fest on top of all of it. That is a lot of righteous noise crammed into one month, and I regret nothing. If my voice is shot by October, you'll know why.


That's the first one. If something in here annoyed you enough to reply, even better. More next month.

Newsletter

Uncommitted

Monthly dispatches on Postgres internals, performance, and whatever else is rattling around in my head.