This article is based on reporting and commentary originally published on TheServerSide.com, featuring an interview with Datical CTO Robert Reeves.
The DevOps Automation Wall: The Persistence Layer
The rise of scriptable, cloud-native infrastructure—combined with mature CI/CD toolchains—has pushed DevOps teams to automate virtually every step of the application lifecycle. Servers are provisioned with infrastructure-as-code tools, microservices are packaged in containers, and deployments are triggered by pipeline events. Yet many organizations hit a hard boundary when automation reaches the database. The persistence layer has historically resisted the same treatment applied to stateless application tiers.
Why Databases Are Different: The Problem of State
According to Robert Reeves, CTO of Datical, the core obstacle is straightforward: databases carry state.
“Database release automation is a real problem. You’ve got lots of great ways of automating the application and provisioning servers. But we are still asking DBAs to just work faster, work harder, as they do manual updates.”
Robert Reeves, CTO, Datical
A containerized microservice can be torn down and redeployed in seconds—its state lives elsewhere. A database cannot be handled the same way. Live production data makes it impossible to simply delete and recreate a database instance the way you would redeploy an application container. Every schema change must be applied carefully, sequentially, and with rollback strategies in place. That fundamental constraint is why the Agile and DevOps transformations that reshaped application delivery have been slower to penetrate the database world.
Compounding Challenges Beyond State
The stateful nature of databases is only the starting point. Database change management faces a layered set of additional constraints:
- Regulatory compliance: Many industries require databases to meet strict audit, data-retention, and access-control requirements. A schema change that violates a compliance rule can have legal consequences, not just technical ones.
- Corporate naming and standards enforcement: Enterprises often maintain strict naming conventions for tables, columns, indexes, and stored procedures. Enforcing these manually consumes significant DBA time that could be spent on higher-value work.
- Performance risk: Structural changes—such as adding or removing indexes on large tables—can have significant and non-obvious performance implications. A DBA must verify that altering an index on a column with millions of rows does not degrade query performance or lock the table during peak traffic.
- Manual bottlenecks: Senior DBAs, often among the most experienced people in an IT organization, spend disproportionate time reviewing and applying routine schema changes by hand rather than working on architecture, optimization, or mentoring.
“Enterprises have some of their brightest DBAs, their most senior IT folks, looking at this stuff. They’re doing tedious, manual work, and it isn’t moving the organization forward.”
Robert Reeves, CTO, Datical
Integrating Database Automation into the CI/CD Pipeline
The solution is to treat database changes the same way application code changes are treated: version them, test them, and deploy them through a pipeline. Reeves describes a workflow that integrates database release automation directly into CI/CD:
- Developer commits code and database changes together. When a developer checks in application code that requires a schema change, a corresponding database change set is committed to the same pipeline at the same time. Database changes are no longer a separate, manual handoff to a DBA team.
- CI tooling runs automated tests. A CI tool (Reeves cites Concourse CI as one example) triggers unit, integration, and regression tests against both the application and the database changes. Tests must pass before the pipeline advances.
- A deployable artifact is built. If tests pass, the pipeline packages the application into a deployable artifact—a container image, JAR, or equivalent.
- Database automation validates the change. Before any schema change reaches the target environment, the database automation layer inspects it: Does it comply with naming standards? Does it pass a simulation of the change to verify it won’t break existing data or violate constraints? Only changes that clear all checks proceed.
- Coordinated deployment. Once the database is updated successfully, the new application version is deployed alongside it—using blue/green deployment, canary releases, or whatever strategy the team uses for zero-downtime delivery.
“Once the artifact is created, Datical will look at the database changes, make sure they adhere to standards, do a fork simulation of that change and make sure its application won’t blow anything up. Then, you actually do it. Once the database is updated, then you move out the new application and new containers, do your blue and green stuff, whatever you want, and you’re done.”
Robert Reeves, CTO, Datical
Key Principles for Database Release Automation
Whether you are evaluating a commercial tool or building a homegrown process, successful database release automation rests on several core principles:
- Version control for schema changes: Every DDL and DML change should live in source control alongside application code, with a clear history of who changed what and when.
- Automated policy enforcement: Standards checks—naming conventions, index limits, data type constraints—should be enforced by tooling, not by manual DBA review on every change.
- Pre-deployment simulation: Changes should be validated against a representation of the target database before being applied, catching errors before they reach production.
- Coordinated application and database deployment: Application code and schema changes should be deployed in a coordinated, repeatable sequence to prevent version mismatches.
- Rollback planning: Every schema change should have a defined rollback path, ideally automated, to support fast recovery if a release fails.
The Broader Impact on DevOps Maturity
Database automation is not merely an operational convenience—it is a prerequisite for genuine end-to-end DevOps maturity. As long as database deployments require manual DBA intervention, release velocity is capped by human throughput. Automating the persistence layer frees senior database professionals to focus on performance engineering, data architecture, and reliability work, while allowing development teams to ship database-backed features at the same pace as purely application-level changes.
The tools and practices to achieve this are maturing rapidly. For teams still treating the database as a manual exception to an otherwise automated pipeline, closing that gap is one of the highest-leverage investments available.
Original reporting by Cameron McKenzie for TheServerSide.com, featuring Robert Reeves of Datical. Datical has since rebranded as Liquibase.