Voice of the DBA

Category: Editorial

  • 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

  • The Mythical Bus Accident

    What if I got hit by a bus?

    I’m sure many of you have heard some variation of this, or used it, or maybe your boss told you to be ready in case you (or someone more important) gets hit by that vehicle. This is the “bus factor,” and it’s often used in reference to preparation for unforeseen events. Not literally someone getting hit by a bus, but perhaps a sudden accident that takes someone away from work (hopefully not fatal). Perhaps it’s someone leaving for a new job. Maybe it’s retirement, which is something my boss and I at Redgate chat about periodically.

    Don’t worry, I’m not planning on retiring anytime soon. I expect to work until at least 2033 and possibly longer. Likely longer, I’m a weird work-a-holic in some ways, and I love my job.

    Recently, Rob Sewell wrote about a DR plan for his life, and specifically about his setup in case his wife needs to understand what’s running. I certainly don’t have the automation or complex computer setup he does. In fact, none of my computers really need to be running for anything on the ranch to function.

    However, there is a lot of important data.

    If you think about how embedded your life is with digital assets, you’ll realize quickly that if you were to get hit by the mythical bus, a lot of stuff might disappear. Most won’t matter, but your partner/spouse/children/parents might care about some. They might really care about a few items.

    There will be passwords to banks, the locations of photos, videos, and other memories. There will be documents you’ve kept on maintenance, or manuals on how something works, or maybe it’s just the various email (and social) accounts you have. You might not care, but the person behind you might feel the need, and want to, notify your friends and coworkers that you’re gone. Maybe your family wants to know how to keep your site alive (I still miss Tom and re-read his work occasionally).

    This isn’t to be morbid or worry you, but the planning you might undertake for your life is a lot like the planning that you should be doing at work for your job. Others should be able to take over for you (especially on vacations), and a guide to how you’ve solved problems, patched over issues, and built scripts that run rarely but reliably for some forgotten reason. Those items should be available to others. Certainly, your IT staff can give someone else access, but will those others know what to do with that access?

    I’ve documented a bunch of processes for SQL Server Central. Mostly so I can go on sabbatical and not worry, but also so that others can share the load. I’ve given away some of my work to others, I’ve been lucky to have others volunteer (volun-told) to help, and I realize as I write this, I likely need to update some docs. Not a fun task, but my buddy Claude can likely help me. And he will.

    Planning for the future is prudent, it’s respectful to others, and it’s a common courtesy. I used to think the future was a long way off, but as I age, I realize it’s closer than I think. Planning for the future is a good idea, and it’s something I need to ensure I update every so often, to help the others in my life.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

    Note, podcasts are only available for a limited time online.

  • A Security and AI Fail

    The AI boom is still growing like crazy. Many organizations are trying to learn how they can use AI to improve operations and become more efficient at a reasonable cost. Plenty of companies are spending crazy amounts of AI tokens, sometimes blowing their yearly budgets in months and not necessarily receiving substantial value back. Some companies are trying to train AIs to understand their operations and perhaps reduce their other costs, primarily labor. Still others are tiptoeing in the waters of AI LLM use and conducting smaller experiments, with limited access to AI technology.

    Meta has been a company at the forefront of trying to train AI based on the work employees already perform. There has been plenty of concern that their efforts are designed to lower headcount and replace humans with AI agents. That might or might not work, though I don’t expect a lot of organizations to do this. It’s likely harder than any of the hype suggests, and most organizations have much more complex types of operations than Meta.

    However, in collecting this data, Meta has had other issues. Notably, they have had security problems with all the data they are trying to collect. Some of this data was exposed and they have paused the data collection for now. They were trying to move fast, likely cutting corners or not thinking things completely through. They created these issues. Hackers are constantly looking for holes and the quicker anyone moves to change their software and processes, the more likely that security holes slip by.

    Plus, data governance and protection is hard. Most developers really don’t think through data protection and security well. They’re focused on software and assume the data store (RDBMS, NoSQL, data lake, etc.) is handled by someone else.

    Data is hard. Especially at scale.

    While I’m sure most companies aren’t looking to track employees’ every move (which is a big uplift), they will be trying to move data around and use it for AI purposes. With RAG, with model training, with who knows how, but they are just as likely to cause a security incident if they are not careful.

    Think data governance and data security early. Develop patterns with DBAs and InfoSec alongside software engineers to ensure that as you stand up new agents, systems, and data stores, you aren’t asking for trouble. Re-using existing data is fine, but if you assume that your development team automatically knows about data security, you’re going to have issues. They likely don’t, and if you (or they) think they do, make them prove it.

    AI is amazing, but it’s also easy to mess up the data part of this. Everyone I deal with at Redgate Software is concerned about data governance, and more so all the time. For good reason. Meta made the headlines, but a lot of us aren’t better at securing our systems. We just aren’t as much of a media target.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

    Note, podcasts are only available for a limited time online.

  • Forward Deployed Engineers

    I recently recorded a session with Ken Muse and a Redgate Flyway Solution Engineer. It was a fun session using GitHub and AI, and better managing the code in an automated fashion to bring some determinism to AI coding. I’m hoping it will be released soon, and you can see a vision of how you can better wrangle your AI agents and reduce risk and increase reliability.

    When we started our discussion, Ken noted that he is an AI forward deployed engineer for GitHub. His job is to work with teams in how to use agentic coding. When we were first prepping, I had never heard the Forward Deployed Engineer title, which is apparently getting popular. It was in an issue of the Pragmatic Engineer Deep Dives last year, and I must have missed that issue. Apparently, this is a role that works part of the time with customer teams and part of the time with product or engineering teams.

    In other words, a software engineer with a new title who gets paid more than a software engineer.

    Titles are always a funny thing to me. I’ve seen people who write computer code go from programmers to developers to software engineers to forward deployed engineers. The job is the same. I work with a team of others who write code, or I work with a customer who wants code and might need help writing it. Or, if I’m working at a company that works with outside customers, this is really a consultant role renamed.

    DBAs have had a similar change. I started as a DBA because they made a lot of money at the time. I moved from programmer to DBA, without much change in skill, but with a nice pay rise at a new company. I left that role before we got Data Engineers, Site Reliability Engineers, Database Reliability Engineers, and who knows what else. However, if I had stayed in a company, I’m sure I would have been changing my title periodically to earn more money.

    Certainly, I’d still have been adding skills that give me a reason to change my title, but I’m not sure the job would have changed. Instead, I’d be trying to grow my career not only with seniority and time, but with new skills and title changes.

    Maybe that’s a good reason to keep learning new skills. New skills let you claim you need a new title. Hopefully, you pick a title that HR doesn’t have any data about, so they have to set a new range for the position that’s above your current range.

    Viola! Instant raise.

    Not a bad career plan. Just make sure you’re adding some skills that are asked for in job descriptions, including soft skills. After all, a forward deployed engineer is going to be working with others, so communication is going to be key.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

    Note, podcasts are only available for a limited time online.