Google tells database devs to lean hard on AI for PostgreSQL work

Justy Okay so Google just came out and said their database team is going heavy on AI coding tools for PostgreSQL work, and I actually think there's something interesting here.

Cody I'm sure they did.

Justy No, listen — the VP basically said the sweet spot is when you have a well-understood academic idea and a well-understood codebase and you're building something isolated. That is such a honest take for a cloud VP.

Cody Right, right. And also conveniently the thing that's hardest to mess up.

Justy Exactly. So anyway — how was your week? You mentioned something about a server thing?

Cody Oh, the usual. Spent three hours debugging a replication lag issue that turned out to be a config typo. Super glamorous stuff.

Justy Classic. Okay so back to this — what do you make of the accountability framing? Because that feels like the actual substance here.

Cody It does, yeah. So Krishnamurthy's line is that individual engineers take accountability whether the code was fully AI-drafted or just partially assisted. And look, on the surface that sounds responsible.

Justy Mm-hm.

Cody But here's where it gets murky. If you're shipping code to an open source project like PostgreSQL and something breaks in production, who actually gets blamed? The individual engineer who approved it, or the project maintainers who merged it?

Justy That's a fair point.

Cody Accountability sounds great until you try to enforce it. And

Cody I'm just saying — 'heavily' and 'judiciously' are doing a lot of work in that quote and they kind of cancel each other out.

Justy Okay that's fair. But the open source training data point — that's actually technically sound, right? Like public codebases are just better inputs for these models?

Cody Yeah, that part holds up. If you've got a model trained on Postgres internals and the commit history and the mailing list discussions, it has way more context to work with than some proprietary blob behind a firewall.

Justy Right, right.

Cody So credit where it's due — that reasoning is sound. The sweet spot framing is also more nuanced than I expected. They're basically saying use AI for extensions, not for touching the core storage engine.

Justy Which — as someone who's watched people try to vibe code their way through a distributed system — is exactly right.

Cody Yeah, the blast radius matters.

Justy The article also mentions Google working on logical replication improvements specifically. That's not nothing — that's actual hard engineering.

Cody True. And if AI is helping them get more contributors onto that kind of work faster, that's a legitimate win. I'm just skeptical of the framing as a whole.

Justy Which is your whole thing.

Cody I know, I know.

Justy But seriously — who should actually care about this? Because it's Google PR, but there's a real trend underneath it.

Cody Database engineers at companies contributing to Postgres, 100%. Also anyone maintaining an extension ecosystem. If AI is going to lower the barrier to entry for contributing, that's a real shift.

Justy Yeah. And the Microsoft stuff they mention — the BSON extensions, the MongoDB-compatible layer — that's the kind of thing that becomes possible when more teams can participate.

Cody Agreed. That's concrete and useful.

Justy Alright so — is this a meaningful signal or just cloud PR? What's your read?

Cody Both, honestly. The accountability framing is PR. The technical reasoning about open source codebases and the sweet spot for isolated work — that's real insight.

Justy That's a fair split. Alright, I'll take it.

Cody You're getting easier to convince.

Justy Only when you're right. See you next week, Cody.

Cody Later, Justy.