For anyone who hasn't come across it, PostgreSQL is one of the most widely used open-source databases in the world. It's also one of the most carefully reviewed. So when its developers say the review process has changed under them, it's worth listening.

What actually happened

According to The Register, somewhere between eight and ten significant features have been pulled from PostgreSQL 19 after beta began. Many are expected to come back in a later version. The general availability date is now planned for 19 November 2026, with a second release candidate due on 12 November, according to the official PostgreSQL announcement.

One of the project's long-standing committers wrote a candid blog post about why. He lists several causes: some features turned out to be harder than expected, senior developers spent months on security fixes, and PostgreSQL is so complex that every feature has to work with everything else. But one cause stood out. With LLM-assisted code review, he says, these kinds of things can now be found much faster.

Some of what turned up were proper architectural problems. A lot of it was a long tail of edge cases that, in the past, might not have surfaced until years after release. His summary of where that leaves you is the line I keep coming back to:

"the effective quality bar has been raised"

He also points out that this wasn't vibe coding. The code in question was written well before that was even possible. It was written by experienced people, reviewed the old way, and it still had more in it than anyone knew.

The bit nobody warns you about

Most of the talk about AI code review is about finding bugs. Far less is said about what happens next. The Register quotes the same developer describing the reality as staring at a list of forty defect reports. Every one of them needs someone to read it, decide whether it's real, decide how much it matters, fix it and test the fix. Even small fixes take time, and the calendar doesn't move.

That's the honest picture. AI can now read code faster than any human team. It can't decide what your business can live with, and it can't give you more hours in the week.

If a project with the resources and experience of PostgreSQL can be caught out by that, a small firm with one app and no in-house developer certainly can.

What this means if you run an AI review on your own code

None of this is a reason not to do it. The PostgreSQL developers clearly think the release will be better for the extra scrutiny, and I'd agree. Finding problems before your customers do is the whole point. But go in with your eyes open.

  • Expect a long list. If an AI tool reviews a codebase that's been around a while, it will find things. That doesn't mean the code is rubbish. It means the bar has moved.
  • Sort before you fix. A data leak or a missing permission check is not the same as an odd result when someone enters a date in 1899. Rank everything by what it could actually cost you, and deal with the top of the list first.
  • Separate design problems from small bugs. PostgreSQL pulled features because some problems were too deep to fix quickly during beta. Small bugs get patched. Design problems sometimes mean stepping back, and it's better to know which is which early.
  • Taking something out is a valid answer. Pulling a feature that isn't ready is not failure. It's often the most sensible call, and PostgreSQL has just shown that the best projects do it too.
  • Keep a person in charge of the verdict. AI reviewers raise false alarms as well as real ones. Someone who understands the system needs to decide what's genuine and what matters.
  • Budget the time to fix, not just to look. The review is the quick part. If you've got a launch date, leave room after the review to act on it.

Where we fit in

This is pretty much how we think about AI in our own work. We treat it as a very fast reviewer and a very fast typist, with a human making the decisions. There's more on that on our how we use AI page.

Our AI Code Audit is built around exactly the problem PostgreSQL ran into. A developer goes through your app's security, database structure, scalability and maintainability, and you get a written report in plain English within five working days. Every finding has a severity rating, and there's a prioritised plan with effort estimates, so you're not left staring at forty items wondering where to start.

If you'd rather someone just looked after it from then on, our software support and maintenance plans cover security updates, backups, monitoring and a set number of developer hours each month to work through the list.

The takeaway

AI review is raising the bar for everyone, including some of the most experienced developers around. That's good news, as long as you plan for what comes after the report. Finding the problems is now the easy part. Deciding which ones matter, and having the time to fix them, is where the work is.

If you've got an app you're not sure about and would like a straight answer on what's worth fixing first, give us a ring on 01474 639 089 or drop us a line.

Cheers, Rob