From Provisioning to Control: The New Database DevOps Reality

New Database DevOps is entering a new reality, and serverless databases are becoming the next programmable infrastructure. That was my biggest takeaway from IBM’s announcement of the Db2 Serverless technical preview. At first glance, it looks like any modern cloud database: instant provisioning, automatic scaling, pay-per-use, and no infrastructure to manage. But the more I thought about it, the more it pointed to something bigger.

This is not just about making databases easier to consume. It is about making them programmable, and that shift changes how we think about their role.

Databases Become Programmable Infrastructure

Over the past decade, infrastructure has steadily moved in this direction. Servers became Infrastructure as Code. Containers became Kubernetes. Entire environments became something developers can create and tear down through APIs. Now databases are following the same path.

A database is no longer something you request and wait for. Instead, a developer, a CI/CD pipeline, or increasingly an AI agent can create it on demand. If a team needs an isolated environment for a pull request, they can create a database. If they want to validate a schema migration or test AI-generated code, they can spin up another one just as easily. When the work is done, they can remove those environments just as quickly.

Once you start thinking about databases this way, the implications become much broader. Imagine a workflow where a developer opens a pull request and an AI agent takes it from there. It reviews the code, provisions a fresh database branch, and applies schema changes. Then it loads representative data, runs integration tests, validates the results, and cleans everything up automatically. All of this can happen before the developer has finished reviewing the feedback.

In that world, the database becomes a fully integrated part of the software delivery process.

This is also where things become more complex. Making databases easier to create does not make database change management easier. In many ways, it introduces new challenges.

The Challenge Shifts From Provisioning to Control

Organizations have not struggled with provisioning for a long time. The real difficulty has always been managing change. Who approved a modification? Can we trace it back to source control? Why do environments differ, and did changes deploy through the proper process? These questions are still critical.

Those questions do not go away in a serverless model. Instead, they become more important. When developers and AI agents can create hundreds of short-lived databases every day, the need for governance, visibility, and consistency only increases.

The challenge shifts from provisioning to control. How do you maintain trust across a highly dynamic environment? How do you keep every change tracked, every environment consistent, and every deployment compliant when database lifecycles become so fluid?

Where the Next Chapter of Database DevOps Is Written

For those of us working in Database DevOps, that is an important shift. As databases become easier to create, clone, and automate, the challenge moves beyond provisioning. It becomes about governing change across an increasingly dynamic landscape. The question is no longer how to create a database. It is how to ensure every database change is controlled, traceable, and compliant, whether a developer, a pipeline, or an AI agent made it.

I believe that is where the new Database DevOps reality is being written now. The technology will keep moving faster. The real differentiator will not be how quickly organizations can provision databases, but how confidently they can manage change across them.