Voice of the DBA

Category: Editorial

  • Republish: Getting Fired

    I haven’t been fired as a DBA, but I was asked to resign. It was a tough day, though a big relief as my boss was a ****head.

    I’m traveling around Italy with my wife, so you get to re-read Getting Fired.

  • Cleaning Up the Cloud

    Recently, I got a bill from Azure. That’s not an unusual thing for many of you, but for me it was a surprise because it said I was late paying. I’ve had a number of services running, and I thought at first that I had left something running too long, like a VM. As I checked, most of the things were paused, even the expensive ones like a Synapse workspace. Instead, I found that my free credits were not being applied. Fortunately, I had changed credit cards or I might have been billed for a few months before I noticed.

    This was a change in how Microsoft managed benefits, which is fine. I opened a support call and someone helped me, but it took several days to get a response. I was slightly worried about the bills, so I decided to audit the things I had running.

    It was amazing how many little things had been created or added as I’ve worked in Azure. Little experiments, even some targeted demos didn’t consist of just a database or a website. There were storage accounts, network endpoints, analytics and log services, and more. Quite a few resources had been auto-created when I deployed something else and had auto-generated names and I wasn’t sure where they were being used. Even in places where I had tried to group things into resource groups, I wasn’t sure of the purpose of each item.

    And that’s just me. Imagine a team of developers or infrastructure people being asked to create things, spin them up for a purpose or after getting a request, and then having some staff turnover. There would likely be dozens or hundreds of resources, which might be poorly or inconsistently named, tagged, or grouped. After this I can see why organizations often feel they’ve lost control of the cloud if they allow too many people to create their own resources.

    It was a sobering experience for me, someone trying to stay under $150/mo of costs for various projects. The number of experiments and deployed services I no longer needed was astounding. A good late-summer cleaning taught me to be a little more organized with my resource groups, and to ensure I’m auditing what I have running every few months.

    Something most organizations should do, but likely struggle to complete effectively in any way.

    Steve Jones

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

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

  • PRs Are Like Trouble Tickets

    I’ve spent quite a bit of my career as a DBA/sysadmin/Operations person. However, I’ve had my share of development positions as well. As I work with customers who look to mature their database development to be more like other software development, I’ve noticed that PRs sometimes don’t get handled as smoothly as we might like. In some sense, they are like help desk trouble tickets that never get closed.

    One of the first things I caution people about is specifying specific reviewers, especially DBAs. There are often DBAs who are the gatekeepers for code, but if we require them to be the only ones to review code before a CI or test process, we really slow things down. This often happens in smaller environments where one DBA wants to avoid anything impacting their job. They want to review everything before it commits.

    That’s a bottleneck that will slow you down. Train others, agree on the types of changes that can be approved by multiple people, and learn to handle the problems, not try to prevent them all.

    Another issue is that lots of people are often overloaded with their workload. It’s a big reason people want to adopt a more DevOps view of the world and try to reduce time spent on handoffs and the friction in the process. However, until things get better, they can get worse. PRs can languish when people are overloaded. Like the first item above, choosing specific people for a review can make this worse, but even if you have a group to review requests, you might find everyone expects someone else to look at the request.

    There’s no good solution here, but establishing a rota for reviews or setting aside time in a calendar can help. There will still be cases when you need immediate review, so there needs to be some escalation process, at least until everyone acts like a team and tries to ensure the others aren’t waiting a long time for their work to be reviewed.

    The last thing about PRs that I find similar to trouble tickets is the content. I have had tickets where I have MB of multiple text logs, and at the same time, a bare-bones description like “this doesn’t work.” PRs can be the same way, with too many changes and too sparse a description. Your commit message(s) might not be good for a PR. Use the PR space to give the reviewer some context. Try to limit the changes, though I know sometimes this can be hard. As much as possible, focus on making non-breaking changes in code, tying schema alterations to feature flags so that you can merge in smaller bits of work without breaking the system.

    Learning to create a more mature database development process takes work. Software developers have gotten better, though they still face some struggles in managing their PRs. Learn from them, ask questions, take advice, and above all, work as a team.

    Steve Jones

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

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

  • Choosing an AI in Sept 2025

    Some of you out there are positive about AI and looking to use them. Some of you aren’t too thrilled with the tools and might avoid using them. I think that not learning to harness the power of an AI is a mistake. This technology is going to change the world in many ways and you need to learn how it can help you.

    You also should learn where the sharp edges are as there are some very, very sharp edges.

    Which AI should you use? That’s an interesting question. If you listened to my podcast interview with Tom Hodgson (YouTube, Spotify, Apple), he prefers Gemini as a developer at Redgate. I think that’s one of the more popular models to choose from as a developer. I see lots of people writing about their experiences using Gemini to code.

    It’s recommended (with others) in this article on choosing models, which is a topic that I think is important to keep an eye on. We often like to build some skill and trust with a tool, developing muscle memory that helps us work efficiently with the tool. In the AI world, things are changing constantly, though not so much that I would recommend jumping on the latest release of a new model.

    Instead, I’d recommend you stick with a tool and, perhaps every 3-4 months, you experiment with another model and see if you like it. Perhaps send some duplicate queries to your current tool and a second one. As much as we’d like to say this one LLM is best, there is some personal preference we will have for different tools. I find LLMs to be non-deterministic, so you want to work with a tool in which you have some trust.

    The current top models that most people look at are the OpenAI gpt models, the Claude models, and the Gemini ones. It is hard to keep track of these, so I’ll try to simply them.

    For many of us in the Microsoft space, we are used to OpenAI and the ChatGPT models. There is the gpt-4o and gpt-5o models in use by many people. I haven’t found these as useful to me for SQL coding. The way they respond slightly grates on me, so I have learned to check in various tools to switch the mode away from gpt-40 (often the default). They might work well for other code, but they seem to lean towards MySQL, which annoys me.

    Claude (from Anthropic) is my preferred model. I usually choose a Sonnet model (3.7 or 4) and have them work well. I like the structure of Sonnet output and find it helps me get database work done pretty well. It’s not perfect, and it’s certainly not always correct, but it’s good. I’ve had it solve a number of problems, and it’s the one I often use in my AI Experiments posts.

    Gemini (from Google) is the one I’ve used the least, but it’s the one several developer friends like. It’s on my list to experiment with this one a bit and see how it works. There are various types of v2.5 models here to choose from.

    Depending on what types of work you do, you might like other models. I primarily deal with text, so I haven’t spent much time with models that work with audio/video/pictures, though my wife has been playing with AI video editing. She doesn’t know which model she used, but she appreciated the LLM help in producing a sale video for a horse recently. It was way better than anything she had done on her own.

    I’ve tried Perplexity (sonar), and very lightly, grok, but they haven’t attracted me for some reason. I tried a local DeepSeek R1 model, but it wasn’t smart enough (or quick enough) to get much done. If you’re in doubt, just ask the AI which model is running. Most of them let you switch models easily, so give it a try.

    And let me know what works for you and why. I have found different models working differently, so pay attention and share what you learn.

    Steve Jones

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

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