Voice of the DBA

Category: Editorial

  • Over or Under Provisioned

    Lots of people move to the cloud; it’s common. In fact, it’s very common to hear customers who are being asked to migrate their workloads to a cloud vendor for a variety of reasons. You might not agree, but often there is some reason to move to the cloud. Sometimes it’s even moving from one cloud to another, just because one of the big three (AWS, Azure, GCP) seems more attractive this year than the one from last year.

    When you move, do you size your system for the peak? 80% of the peak? Perhaps there is another goal for which you design. Do you worry about ever being under-provisioned and letting customers have a slower system? Or do you ensure you never hit the peak, which increases costs?

    Auto-scaling can help, but it doesn’t seem to have worked as well for database systems as it does for serverless functions or other types of workloads. Compute is much easier to scale than stateful database systems that need CPUs and RAM ready on a particular system instantly. In fact, the “serverless” Azure SQL database is attractive to me more for it’s ability to scale the CPUs and RAM more than the on/off capability.

    I was in a discussion recently with a number of data professionals who tend to over-provision a bit, mostly because their companies are willing to. It saves them headaches and phone calls (more angry texts these days), but it also means developers aren’t incentivized to optimize any queries. Unless there is a way to determine that the aggregate of all queries could lower the size of the resource provisioned, no one wants to fix any poorly running code.

    That was interesting to me, as I’d think we’d want to optimize code as we pay every month, but the reality is that we pay every month for a level of resources. Coming in under that level is all that’s important. If we use 99% of those resources or 25%, we pay the same amount. It’s like saying we want to watch a movie every night because we pay for Netflix/Apple TV/etc. We’ve spent the money, so whether we watch 1 a week or 5 a week, there’s no point in optimizing our time to get value out of the subscription.

    In the PaaS world, that might change, but often we’re still purchasing a tier of resources, not paying for each query. Until we need to raise that tier, no one worries about efficiency. If we can’t prove a lower tier would work with better code, no one cares.

    It’s a little sad, but perhaps some future version of monitoring that can spin up a digital twin, optimize some code, and model a lower tier will take hold among all the performance tuners and monitoring vendors. Maybe with a few Claude code tokens, one of you will solve that problem.

    For now, I still think it’s worth trying to optimize code, especially if an AI can give you suggestions and prove things run quicker in a test environment. If the cost of code is getting lower, then why not extend those savings to SQL code?

    Steve Jones

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

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

  • Republish: Fixing Imposter Syndrome

    It’s the last day of vacation. My wife and I stayed in Seattle an extra night so we could unwind and then catch up with a friend this morning before we head back home.

    While I am having a wonderful Filipino breakfast at Ludi’s, you get to re-read Fixing Imposter Syndrome.

    If you get to Seattle and find the Biscuit Bitch too busy, walk down a block to Ludi’s and try their offerings. It’s wonderful. Garlicy, but I love the Long-silog.

  • Republish: Bean Counting to Burnout

    I’m still on vacation. Today I think is Sitka on our Alaskan cruise, but in any case, no internet for me. Didn’t buy a package, not trying to check things in port.

    You get to re-read Bean Counting to Burnout while I hike in the woods around town.

  • The New Software Team

    One of the things I used to emphasize in talks about DevOps is that no modern software of any significance is built by one person. Everything takes a team, so the foundation of version control becomes extremely important. We need a way to coordinate work across multiple individuals and communicate what changes are being made. This requires a strong foundation, and that starts with version control.

    In 2026, that hasn’t changed, but what has changed is the makeup of the team. No longer do I need a bunch of humans. In today’s world, with extremely powerful AI LLMs, we can have a team of AI agents that write code, often at a pace far exceeding that of human teams. However, they still need to coordinate and communicate and ensure their changes mesh together.

    In this short article on the rebirth of programming, the team is a team of n humans and m agents. N=1, and the architect, the coordinator, the project manager is the human (or a few humans). Code becomes less important, and the tests and other elements that describe and verify software become more important. Maybe even more important than today.

    I’d even go so far as to say the performance of the code might not matter in the short term. Since the cost of writing, or re-writing code, becomes lower and lower, when something doesn’t perform well, just spin off a new team of your agent coders who don’t need sleep, aren’t worse at development if they work more than 40 hours every week, and are always happy to tackle new work. It’s a project manager’s dream team. At least, in theory.

    That being said, the cost of writing this code isn’t zero. We see this rising every day, sometimes at a level that exceeds what we might pay human developers. That might change over time, but we certainly see some people spending more on tokens than salaries.

    And your agents do lose focus. Fortunately, you can fire them and hire new ones every day, or every hour. It’s like a team of characters in a game that respawn on demand to tackle the next challenge. There is still plenty of coordination and onboarding work for the manager. They will need excellent documentation and descriptions of what the code looks like, what needs to be done, and all of your guidelines on how to structure things. Lots of tests are needed, but your team can build them (with oversight).

    It seems like an amazing system, but we’re learning that excellent team leaders who are good architects are in short supply. And they can’t work long hours. Some early evaluation of these software managers seems to indicate that they can’t even work the full 8 hours for 5 days a week with a high level of effectiveness. They might not even be able to work half that amount of time.

    So is the falling cost of code going to produce more software? Likely, though perhaps with many more leaders needed to manage those teams. I can certainly see many more one person companies spawned during off hours, where one person can focus on their passion project, something completely separate from the work they are paid to do by someone else.

    It’s going to be fascinating to watch this work itself out across the next decade.

    Steve Jones

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

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