Voice of the DBA

We had a Simple Talks podcast recently where we discussed roll forward vs roll back. You can watch the episode and listen to our thoughts, but one interesting place was when we talked about deployments. Grant mentioned that he deployed from version control/source control at a previous employer. I asked him whether he did that for every system.

His response: “Well, …”

He admitted that most, but not all, databases came from a controlled source. There were some systems that had a more ad hoc change process. I wonder how many of you have consistent processes throughout your organization. I suspect not many of you do, especially if an organization isn’t small. Often, different groups and applications are in a constant state of flux, with lots of different processes and protocols.

Some groups are more mature and have stable staff who expect to deploy changes in a certain way. This might be on a known cadence, with documents or processes in place already. Others applications might have been developed quickly; perhaps they are newer and use more automation to deploy changes. Some might even use things like packages from an ORM or a vendor that takes control of database changes away from anyone managing the database. Does anyone deal with Spring Boot and very optimistic developers?

I wonder how many of you have a consistent process for promoting database code to production across all your teams. Maybe 80% is a better metric, as this accounts for those groups severely limited by legacy technology or those that might be experimenting with new ways of working.

Even those companies that have platform engineering groups in place to ease the flow for both developers and operations often aren’t consistent throughout the organization. Often, getting everyone to adopt a standard is hard and takes time.

That might be the biggest challenge with standardizing database deployments: time. Organizations grow and change, new technologies come, and by the time we think we’ve gotten everyone to agree to change, who everyone is has changed. We have someone or something new, and we’re forever chasing standardization. Even when we might have a great DevOps process or a platform engineering team for software, we don’t do this for databases.

I believe having a consistent, standardized process is a worthwhile goal, but one where 80% success is probably good enough in most organizations. If you can get most teams to follow the same process, you’ll increase efficiencies and ensure a better software development life cycle.

Steve Jones

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

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

I have the opportunity to work with a variety of customers on their database systems, often with the focus on how they can build and deploy changes to their databases. Often, they have a process around how and when they make changes. Some have maintenance windows, though often these are approved times for changes rather than a true window during which a system is shut down.

I ran into a customer recently who scheduled a system shutdown for their deployments. This was a surprise to me in 2026, as I thought most people would have learned to deploy changes to live systems. However, I know that many teams make changes that would render portions of the database inaccessible for a period of time, so maybe that’s not true. Maybe they just make changes and deal with the impact on clients.

I wanted to ask this question today: Do you shut down your system completely for a deployment? Not all systems, but the one you’re patching and possibly a few related ones, while preventing client access?

Or do you have to make changes while the system is still in use?

A lot of DevOps analogies revolve around the idea of cars and performing maintenance or improving them. One that I like is learning to replace all the parts of the car while it’s still running and in use. That can be hard in the real world, but we can often find ways to do this in software, including with databases. A little creativity can go a long way.

I love watching the evolution of Formula 1 Pit Stops as a way of visualizing the problem. This video is kind of amazing, but it shows the power of thinking about a problem and finding ways to improve it. In the 50s, pit stops could take 45-60 seconds or longer. If you look at the video, in 1990, they dropped this to less than 9 seconds. That seems amazing, but the power of continuous improvement shows this dropping to 7s in 2000. In 2010, 4 seconds. Then in 2020, 1.82 seconds for 4 tires changed.

This is still a full shutdown, albeit a few short one.

I constantly deal with people who think that they cannot find a way to make deployments easier, faster, or less impactful. I know that car racing teams used to feel that way about their pit stops. Once they tried to creatively work on their challenges, they found solutions that are truly amazing. Using new ideas and tools, they reached speeds no one could have imagined a decade ago.

I bet many of you can do the same thing to your databases with an open mind and a little tooling.

Steve Jones

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

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