Voice of the DBA

Tag: DevOps

  • Architecting Zero Downtime Deployments–Day of Data Boston

    Here are the resources for my talk at Day of Data Boston.

    Slides – ArchitectingZeroDowntime.pptx Slides also at: https://dayofdata.org/2026-10-03-dayofdata1150/#schedule

    Code: https://github.com/way0utwest/ZeroDowntime

    Book: Refactoring Databases

    Some interesting questions. I’ll write more, but a couple of quick answers as I breakfast at Logan.

    How do I handle expanding a column? Making it larger?

    This is platform and change dependent. For example, if you are expanding a varchar() column from 10 to 20, this is usually a metadata operation in MSSQL. No data gets touched, no rows, the system tables record a new size. This can be instantaneous. There are exceptions where this might take time, but usually this works.

    Changing from int to Bigint is different, but I’d follow the split columns pattern and add a new column instead, move data, then drop the old one.

    How do I get my organization to adopt better patters?

    This deserves a longer answer, but there are two parts: technical and politicial. The technical part is teaching other developers the new patters, using linting to catch issues, and convincing others this isn’t hard and works well.

    The political part is getting management to support/enforce this. That can be tricky, but you need to provide business reasons why downtime is a problem and how this addresses the issues, with real numbers: time down, cost savings, revenue lost, etc.

  • You Need a DBA Pipeline

    I work regularly with a number of customers on improving their database change processes. This has been the goal of Redgate’s Database Change Management over the years, helping database systems work more like application software with DevOps principles. The idea is to move quicker and respond better to demands, while providing safety and governance. A database is a stateful machine, which is a challenge to evolve and maintain, but with good data modeling, testing, code analysis, and automation, your database change process can coexist with your application software.

    That being said, most of the solutions for managing database change focus on the database itself and everything inside it. After all, that’s where the data is. I understand people wanting to solve that problem, but there are plenty of things that need to be managed for a database server (or an instance for MSSQL) outside of the database. We have security, configuration, and, in the case of SQL Server, jobs. That might be the number one request is a way to manage jobs across systems.

    Regardless of any tooling you might use, the important thing that you need is a way to easily manage and deploy the scripts you generate. These might be adding users or logins, perhaps rotating certificates, or something else. Clicking through SSMS or manually running things might seem like it’s quick, but that’s a governed way to manage tasks. You might update a Jira ticket when you’re done, but do you always capture the code you ran in the ticket? The results?

    For many tasks, this might not seem like it matters. If we make a mistake, we correct it, and no one needs to know. However, this doesn’t help you work more efficiently, nor does it help your team work closer together. If there are records of the code and results in a pipeline, then you have a trail of who, what, when, and how. The ticket should tell you why.

    This helps hold you accountable. It ensures you test more carefully. It gives teammates a place to go grab a script that worked and re-run it, perhaps changing the name of something in the script; this allows the reuse of work. This ensures that the work is routine.

    Many of us have made a career out of doing work manually, and we’ve gotten good at it. However, the future will require us to work in a team, one that may include an AI, and learning to build patterns of work that flow easily across humans and agents will be a skill that lets us both be productive and provide value to our employers.

    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.

  • Architecting Zero Downtime Deployment Resources–Albany Day of Data

    Thanks to those who attended my session at Day of Data Albany 2026. I’m posting this to help you find the resources from the talk.

    Slides: ArchitectZeroDowntime_SQLSatAlbany2026

    GitHub Repo: https://github.com/way0utwest/ZeroDowntime

    The GitHub repo has the code for the database setup and demos (and teardown) in the SQL folder. This creates the db, login/user, schema, and data.

    The VS project is in the DBClient folder. I don’t think this is updated beyond .Net 4.6 (?), but feel free to update it. There isn’t anything special about this project. It was developer in VS 2019, but I ran it from VS2022 on Saturday, and I believe I upgraded my local project to .NET 4.8 last week. I haven’t committed this back as I don’t want to push this forward yet.

    If you have questions, feel free to contact me.