Voice of the DBA

Tag: Database Weekly

  • PostgreSQL 19 Is Late

    “All software contains bugs.”

    That’s a quote from Robert Haas’s “Postgres 19 is late” post. He goes on to say that PostgreSQL has lots of bugs in it. It’s the way it’s been for a codebase that’s over 40 years old. He goes on to note that it’s easier to find bugs with LLMs, and easier to fix them. It’s not, however, as easy to do the latter as the former.

    The impact on PostgreSQL 19 is that they’ve had to revert a number of features much later in the process because the humans were reviewing and fixing bugs found by LLMs. This effort delayed other work and has affected the release.

    As someone who primarily works with SQL Server, I’m not that worried about delays in PostgreSQL or other platforms. I think it’s a fine choice, but I’m focused on SQL Server, which I think is more of a joy to work with.

    However, there are a few interesting things in here. First, I think SQL Server has had a lot of bugs found lately (likely by AI LLMs). I recently wrote about the frequency of patches, which is higher in 2026. This is probably due to LLM code review, and that’s good. It also means we likely will have more patches coming, not just in SQL Server or PostgreSQL but also in our other systems. What’s the likelihood that someone will run an AI review and find bugs in other COTS software, internal apps, or even those no-code/lo-code systems people have been deployed? That’s not even mentioning the vibe-coded prototypes that are suddenly important enough to put into production.

    The other interesting thing was that Robert accepts that LLMs are likely to find more bugs in the future. How will they find time to work on them? After all, from the article, fixes “still need to be reviewed and committed by humans.”

    Maybe the best part of the last paragraph. He says LLMs are going to require every developer to raise their game. Every feature is going to be scrutinized by AI. That’s a challenge and an opportunity, but the key is that developers need to get better. AI can help you and write code at amazing speeds, but it doesn’t think.

    We need sharp developers that think in order to cope with AI.

    Steve Jones

  • The New World Of AI Robots

    It’s been a good time for robots. While on vacation last week I caught this video of a robot running. It’s impressive for a bit, and then it devolves into the inspiration for lots humorous comments as it crashes into a wall. There are some funny comments, but some pedantic ones that note the robot can’t beat a human record because it’s not a human.

    That’s correct, but …

    The comments miss the point. The robot will improve it’s capabilities, and much faster than a human can. The AI/ML advances of the last few years mean that we don’t have to program robots to be precise and exact. The fact that a robot can balance and run and stay inside the lanes is incredible. I suspect these robots, both humanoid and other form factors will start to become more commonplace in our world.

    Which is scary.

    Not for us tech people, though certainly AI advances are worrisome. More, I worry about other jobs. Think about the industrial robots of the last 30 years that have been used in places like car manufacturing. They are bespoke, designed to do certain jobs, and in a certain way. They are programmed with fairly tight tolerances to perform a specific task, often at a quicker and more reliable (and repeatable) way than a human can. There were plenty of false starts here, but today many robots are used alongside humans to assemble cars. You can see them working here, doing tasks that would be slower and harder for humans, even with mechanical aids.

    There is talk of humanoid robots being used in place of some humans, reducing the slow and complex setup . This also lets the robots work in the same places and spaces, moving the same way, as humans do. This might reduce some of the labor costs in the future. That might not seem like a big change overall, as lots of manufacturing uses automation in some way today, but think past this.

    You can purchase a humanoid robot for under $5000. That might not be very capable now, but as LLMs get more capable and perhaps specialized models for different purposes like image recognition, this is an issue. Imagine you own an oil change business. You pay 5 people to do most of the work on cars. Those people likely cost you $2000-2500 a month each. That’s the cost of 2 robots, without the hassles of hiring, termination, breaks, etc. An AI LLM can already identify items from a camera image. Is it a far stretch to think that a robot could identify the oil drain plug and the oil filter on a car by moving around it? How hard would it be for a robot to grab a human ratchet, pick the right socket after a database lookup, and remove the plug. They could tell when the oil finished draining and then replace the plug, tightening it to the correct torque. And being a robot, they might do this without forgetting to position the drain or replace the plug.

    In my mind, a $5k robot quickly becomes capable of a lot of human jobs. There might still be the need for some humans, but we might easily replace 50%+ of them in a lot of common jobs. Stocking shelves, acting as cashiers, who knows what else these AI driven systems might accomplish. That’s truly a scary world, where human labor in many cases might be devalued.

    In the software world, it seems the people having the most success have the best judgment. People who are above average software engineers get above average results from LLMs, and I suspect this will be the case for a long time. Very average, or worse, engineers get worse results and I think are the source of many of the stories of AI coding failures.

    I don’t know what a lot of manual labor jobs will do when management starts to experiment with robots, but I know that in our world you can compete and succeed against AI coding agents by learning to work with them, apply your judgment and use them as tools that make you more effective.

    Steve Jones

  • The SQL Server 2016 Plan

    SQL Server 2016 went out of support this week, on Jul 14, 2026. This is the end of the Extended support, according to the Support Lifecycle page. Microsoft posted an article on next steps for SQL Server 2016, which looks like the AI read of an article at the top. There’s a lot of header info, so scroll down. I’m sure none of you want to listen to 10 minutes of an AI voice reading an article.

    I know some of you still run SQL Server 2016. In fact, I still run into some companies on older versions, and the last (ever) update from Brent also showed 6% on 2014 and older. There are probably still plenty, albeit a minority, of systems on older versions. I know when I worked in a non-regulated industry, we weren’t in a hurry to upgrade as many of our applications ran fine on older versions. Especially with VMs these days, I could see people sticking with 2016 for a while if it’s running well. Just be sure your server is well protected by firewalls.

    The blog gives 3 upgrade paths: Azure (IaaS or PaaS), SQL Server 2025, or Extended Security Updates. That latter one goes until 2029 if you want to pay for it. This is certainly a marketing post more than a technical one. Moving to Azure PaaS isn’t necessarily easy or quick. IaaS doesn’t help you here, so I’m sure whoever wrote this post (or whatever AI) isn’t thinking this through. An Azure VM isn’t going to get me any support.

    SQL Server 2025 is likely the easiest if you want to upgrade, as you could continue to use an older compatibility level in your database on SQL Server 2025. It will cost something, but it does give you 9-ish years of support and updates. I’d certainly prefer this over paying for ESU. It might not be a seamless upgrade, but I’d give it a quick go and see if my application worked on a restored 2016-on-2025 database. That’s an easy test and helps me make a decision.

    I suspect some in regulated industries need support for their compliance goals, and they might pay for ESU if their staff is busy and they need to mitigate an audit finding. I think this option is there, and it’s expensive, as a carrot/stick combo for organizations to upgrade. I can’t be upset about this, as I think there should be a plan in organizations to keep their software up to date. Either deliberately plan to remain on an older version and accept the risk, or ensure you have plans (and time) in place to regularly upgrade systems.

    If you’re on SQL Server 2016, what are your plans? Upgrading soon? Sticking with the platform? And if you’re on 2017 or 2019, you ought to be thinking forward and be ready to handle the end of support for those versions.

    Steve Jones

  • Is Fabric a Reliable Service or a Ripped Resource?

    Over the last few weeks, I’ve noticed a few complaints from different friends and customers about issues with Microsoft’s Fabric service. I had assumed these were isolated incidents in just a few places, and customers were being refunded according to an SLA. Then I saw Joey D’Antoni’s post this week about Fabric going down. It lists quite a few of the incidents in June, including a few global ones.

    However, the most surprising thing in the post was this link, noting Fabric doesn’t have a dedicated SLA. Instead, it’s under the general Microsoft support agreement, meaning your organization needs to have a support plan to get help. I think that makes some sense, but I’d really expect that a data service in the cloud, including an analytic service that touts itself as real-time, would have a high SLA. Some agreement on the order of 4 9s at least, if not 5.

    For those of you who think you can do better on premises, I’ll remind you that four 9s mean you get 52 minutes of downtime a year, or 1 minute a week (roughly). Five 9s is 5 minutes a year, and the weekly calculation doesn’t matter. I’ve had systems run for a year, but a lot, and not a lot of databases, especially with patching 6 times a year. This year, with AI (my guess) finding lots of holes and GDR releasing quite often, I would guess that three nines is out the window for most SQL Server systems that aren’t HA clustered in some way.

    As a point of reference, Denny notes that Azure SQL database, Business Critical, has a four-and-a-half 9s level of reliability and financial refunds for costs if that’s exceeded. You will need some sort of business insurance if you worry about revenue issues, but my guess is that most of us live with the downtime and work around it (and hopefully, plan for it).

    I’ve been skeptical of Fabric (outside of Power BI). It feels cobbled together, so many issues are reported, and I feel like it’s immature. If I were working on a new analytics project, and we didn’t have a solution, I might PoC it, but I’d be more likely to consider Databricks, Snowflake, or Redshift rather than Fabric.

    Perhaps you have a different view, or you have had success with Fabric. I know some people who have, but it seems one-sey two-sey and not commonplace. There seem to be so many workarounds and issues; it makes me skeptical that Fabric is really ready for primetime if Microsoft won’t stand behind it. Databricks only gives credit up to three 9s, but if they fall below 95%, they issue a 100% credit. Snowflake offers four 9s.

    I feel that if Microsoft were confident in their reliability, they’d offer refunds if they didn’t perform.

    Steve Jones