Voice of the DBA

Category: Editorial

  • I Don’t Want To Do XX

    Every job is a job on some days.

    I’ve said this to my kids and others I’ve mentored over the years. I’ve probably written that here, and I truly believe it. When you work at a job, some days are bad days. There are always days you don’t want to do the work. There are also likely some days that you dread starting. Whether you work for someone else or run your own business, there will be times you aren’t completely in control of the work and wonder how you ended up in this situation. Even if you’re self-employed, you have clients that sometimes dictate your day.

    I’ve worked for myself in the past, and I currently have an amazing job as an advocate/architect with Redgate Software. I get to travel all over and talk about AI readiness, DevOps / Database Change Management, Database Intelligence, and random SQL Server stuff. Usually it’s a lot of fun, but at times it can be hard. If you see me not engaging at an event, it might be that I’ve been on the road a lot while still having lots of other work commitments to manage. I might be worn out and need a break. Those often are tough days. (FYI – We always need good people and have a few spots open.)

    Lately I’ve been hearing people talk a bit about AI and how it sometimes takes the joy out of work. That might be because it’s doing the stuff you enjoy doing. This conversation with Casey Muratori on using AI is revealing. He’s not using AI because he loves programming. He doesn’t want to have AI doing his coding.

    That’s interesting, and it got me thinking about daily tasks, the things we do and what we might send off to be handled by an assistant.

    What things do you not want to do at your job?

    That’s the question today. Let me know what things you wish you could get someone else to do, or some robot to handle for you. I know lots of people wish they had a robot to do the laundry or dishes at home. What tasks at work would you want a trustworthy helper to handle?

    Steve Jones

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

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

  • The Cost of Multiple Platforms

    I ran into an interesting post that noted the modern data platform can have a bunch of different systems underlying it. The example might be that your “software” could use PostgreSQL, MongoDB, Cassandra, Clickhouse, and something NewSQL (Spanner, CockroachDB, etc,). Some of you might think that’s not reality, but keep in mind that for a lot of your organizations, the “software” is what the customer uses. I’m sure my bank has multiple systems behind the mobile app I use to pay for things, move money, check balances, etc. I would guess there is some DB/2, SQL Server, and some analytics or No/NewSQL stuff in there. Hidden as different applications that make up the “app”, but they are still in there from my perspective as a user of the app.

    No one intentionally designs software like this, but we still see it. They might not even have 5 or 6 platforms in their organization, but almost none of the customers I work with have less than 3. Somehow, somewhere, someone added a PostgreSQL server to an Oracle/SQL Server environment. MongoDB crept in when someone thought it was a better store than DB/2 or MySQL. An article written about how Facebook or Spotify or some other high tech company used Cassanda or Snowflake inspired a developer to add that to their toolbelt and build it into their application.

    And the ease with which the cloud makes experimentation quick and cheap causes a spread of your database estate.

    There’s a cost to having all these systems. Either an organization hires separate sets of experts to manage Ops, or they try and train lots of individuals to run multiple systems. It can be done, but those lightly trained people who have to focus on remembering the differences between SQL Server, PostgreSQL, and MongoDB will work slower. They’ll solve problems with a higher MTTR. Even if they have a single pain of glass, like Redgate Monitor, they still won’t be as effective as the number of platforms grow. It’s just human nature. And if you hire separate teams, that’s a cost as well.

    Heck, I’m a pretty good DBA and a good volleyball coach, but I get confused. When I got voluntold to manage DB/2 systems in addition to SQL Server, I got less done every day. When I coached two volleyball teams at the same time, I was less effective with each. It’s hard to keep focused on multiple similar things. Add in the complexity of not only separate paradigms, but different ways to manage things in the cloud or on-premises and the operational cost is high.

    I’m not sure it exceeds any licensing cost or the cost of limiting what platforms developers can use. I would argue only allowing 1-2 platforms just makes you more efficient and your staff more effective.

    However.

    That’s not the world. Even if I mandated that, often some external even changes my world. Companies get bought and integrated. New COTS software is needed, and it will, of course, run only on a database platform we don’t run.

    There’s a serious operational cost to adding new platforms that few consider. Even if they did, I’m not sure anything would change.

    Steve Jones

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

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

  • Measuring Productivity

    I’ve dealt with a lot of customers with who lately are concerned with the ROI of their teams. Certainly they want a good ROI if they purchase software from Redgate, as do we. Our goal has been to be partners with customers and continue to add value to the products they’ve purchased on a regular basis. We release every week or two, and our Redgate Monitor and Flyway updates reflect this. New functionality, fixes, and previews. I’m proud of the constant updates we deliver, and I know customers get increased value throughout our partnership.

    Does our software provide a good ROI? I get asked this question by execs regularly, and I often ask them if they feel they get a good ROI from their staff already. Answers are mixed, especially in the database world where it seems the costs and the value delivered from database dev or ops groups can be nebulous. Databases support application software, and if that software doesn’t work well because the database deployment scripts weren’t correct, weren’t tested, or have performance issues, who is at fault?

    It’s easy to blame the database, but who bears responsibility here? Is it the developers that didn’t model schema well or test queries at high volumes of data? DBAs who haven’t been adding or maintaining indexes? A lack of resources matching workload (an Ops issue)? Perhaps someone not taking time to review code (shared Dev/Ops or process issue) is at fault. Could it be the delays from a slow process to deploy changes end up delaing your digital transformation? Execs really care about that last one.

    There are metrics that DORA produces from their research around software delivery. These can be applied to database code, though I find often that companies adopting these don’t extend them to the database. At Redgate, we often have solutions engineers and architects spending time helping customers evaluate their existing database software lifecycle and try to decide if there is room for improvement. We love to sell you software, but only if you will use it and get value from the purchase.

    Today I’m wondering if any of you self-assess and maintain metrics or measures about how your databases perform. Lots of you use Redgate Monitor (or some other software) to watch databases, but do you keep metrics on how code gets to production? DORA would recommend you measure the time to make a deployment, the frequency, and other items, including when deployments fail. By the way, code compiling, but breaking the application because the logic is wrong is still a failed deployment.

    In 2026, even in the age of AI, I’m surprised how often I run into companies still doing manual work to deploy database code. Emailed scripts, file shares with random collections of code, even manual runs of SQL Compare to update production are the norm in many places. Even when C#/Java/etc. application code runs through an automated CI/CD process. I get that stateful databases are hard, but shouldn’t we be trying to make changes easy? An ordinary event, not an extraordinary one?

    Maybe more importantly, do you measure yourselves and evaluate your productivity as a DBA or database developer? Whether you do or don’t, what do you think are good measures of your productivity?

    Steve Jones

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

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

  • Preserving Data

    Most data professionals I know go out of their way to take care of the data entrusted to them. Most people ensure backups are running, lots (hopefully most) test their restores. A few will ensure a good rotation their data offsite. Some of you might have formal rotation schemes, and some might just keep a rolling list of xx backups available.

    Likely a few of you don’t worry about anything other than the last full backup, which is a risker approach than I’d take.

    In the past, I’ve often kept around monthly backups for a year, usually with more granular backups inside of the month. Beyond that, depending on the system, we might keep quarterly backups or yearly ones for a longer period. These days with cheap storage and automated solutions, I’m sure many of you just assume your backup system keeps xx backups around. the cloud providers will keep point in time backups if you use Azure SQL DB (7 days by default) or AWS RDS (1 or 7 days, depending on the provisioning method). If you use VMs or other systems, you ought to be aware of how long backups will be kept and ensure that fits inside your RPO.

    This came to mind as PBS, a US broadcaster, almost lost most of their archived data recently. Their provider stopped responding to them and they couldn’t get to the data, which was stored in Iron Mountain data centers. They sued and got access to ensure they could access and use this data. A win for them, and really, for many of us.

    I don’t expect Azure or AWS to go under, but some of you are using third-parties for backups, even in the cloud. If your provider goes under, can you access your data? I can guarantee if any of these companies has issues (financial, hacking, ransomware, etc.), there will be a few clients that need a restore that day. Resolving this in the courts is likely to be successful, but after how many days?

    Backups are important, but only when they facilitate a restore. It’s easy to get complacent and think because you’ve been running backups that you’re protected. Test that restores work. Have a plan, and maybe a contractual clause, that ensures you can get to backups in the event of issues. This won’t protect you from everything, but it can help speed things up.

    And if you’re like me, keep at least the last backup (or two) local to your system, in a place that you can get to quickly and easily. It’s fine to assume the automated PIT backups will be there, but if AWS or Azure has issues on the day I need a restore, I’d like to think it’s worth a small cost to me employer to ensure there’s at least one backup separate from the automated service. That SLA refund isn’t likely going to cover the lost business when your database is down.

    Steve Jones

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

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