Infrastructure as Code Isn't Enough: Why Database Delivery Must Evolve

| Harness Blog

• Infrastructure as Code solved infrastructure provisioning, but it did not solve database schema change delivery.
• Database changes are fundamentally different because they modify persistent production state.
• Separate application and database deployment workflows increase operational risk.
• Modern platform teams need version-controlled database schema change delivery with rollback and governance built in.
• AI will accelerate software delivery, making unified delivery workflows increasingly important.

‍

For more than a decade, Infrastructure as Code (IaC) has transformed how engineering organizations build and operate systems.

Infrastructure became programmable, provisioning became repeatable, and configuration became version-controlled.

Teams gained the ability to automate environment creation, enforce policy consistently, and scale infrastructure operations far beyond what manual processes could support.

Yet one critical part of software delivery never fully made the same transition, the database.

As Mrina Sugosh, Senior Product Marketing Manager at Harness, explained during a recent discussion on modern software delivery: infrastructure evolved into a declarative system while database delivery largely remained procedural.

That gap is becoming increasingly difficult to ignore.

Infrastructure Became Programmable. Database Changes Didn't.

Infrastructure as Code introduced a powerful operating model. Instead of manually configuring servers and cloud resources, teams could define desired state in code and let pipelines handle deployment. Tools like Terraform, OpenTofu, AWS CloudFormation, AWS CDK, and Terragrunt let organizations standardize infrastructure management and retire the fragile, hand-run processes that came before.

Platform engineering itself emerged from this shift. Version-controlled infrastructure, reproducible environments, and codified policy became foundational capabilities for modern engineering organizations.

Databases followed a different path. Schema changes, migrations, rollback logic, and data management frequently stayed outside that same delivery framework. The result is a split operating model: infrastructure is automated, applications are automated, and database changes are still done by hand. That separation is where the risk lives.

The Hidden Gap in Modern Software Delivery

Modern systems are no longer simple applications running on servers. They're interconnected ecosystems of applications, databases, APIs, queues, caches, event systems, and infrastructure services, each one depending on the others behaving correctly.

Yet many organizations still deploy these components through separate workflows. A database engineer manages schema changes, a DevOps engineer manages infrastructure, an application team manages deployments, and success depends on those people coordinating rather than those systems coordinating.

Wyatt Munson, Product Education Engineer at Harness, described what that looks like in practice: sitting shoulder to shoulder with a software engineer during a deployment, one person ready to roll back the application and the other ready to roll back the database, both watching for the moment to click at the same time. It worked. But a release that hinges on two people and their timing isn't a delivery model that scales.

Why Database Delivery Is Fundamentally Different

Many organizations assume database delivery should behave like IaC, but the reality is more complicated. Infrastructure provisioning is generally additive and reconstructable: if a virtual machine fails, you recreate it; if a Kubernetes cluster is misconfigured, you rebuild it.

Database changes operate differently because they carry persistent business state. They represent years of accumulated data, application assumptions, indexing strategies, access patterns, and operational dependencies. A schema migration isn't provisioning infrastructure. It's modifying a live system, and even seemingly small changes can ripple outward:

• Dropping a column removes information permanently.
• Index changes affect query performance.
• Schema migrations can impact application behavior.
• Data migrations may create consistency issues across services.

As Munson put it: "At the end of the day, it's the data that's the most important." Losing infrastructure is disruptive. Losing data is catastrophic.

The GitHub Incident That Exposed the Problem

The risks of database delivery aren't theoretical. One example discussed during the webinar was a GitHub production database migration. A migration removed a column believed to be unused, but parts of the application still referenced that column through a separate ORM path. After the change deployed, GitHub saw elevated error rates across pull requests, push operations, notifications, webhooks, and API traffic.

The failure wasn't really the migration itself. It was that the database change and the application that depended on it were validated separately rather than together. The migration was checked as a migration and the application was checked as an application, but the two were never exercised as one system before the change reached production. So the dependency stayed invisible until it broke in front of customers.

This is the gap a unified delivery model is built to close, and it closes it in two places:

1. Catch it in pre-prod. Had the schema change and the application deployed together into a production-like environment, spun up on demand with Infrastructure as Code, the same errors that surfaced in production would have shown up there first, against real application behavior, where they cost nothing.
2. Gate it before prod. A destructive change like dropping a production column should pass through a policy gate before it ever reaches production, held for explicit review and ideally backed by proof that it cleared QA without breaking anything.

Three Requirements for Modern Database Delivery

1. Version Control Database Changes

Database changes should be managed like application code, through version control and GitOps. That gives every change traceability, auditability, and a documented history: who made it, why, and when it shipped. The same properties that make application code reviewable and repeatable apply just as well to a schema migration.

2. Automate Validation and Rollback

Database delivery needs more than deployment automation. Before a change reaches production it should go through:

• Validation against a realistic environment, so problems surface in pre-prod, not prod.
• Schema and migration testing as part of the pipeline.
• Environment promotion, the same staged path application code follows.
• A defined reverse path: a reviewed rollback where the change can be cleanly undone, a tested forward-fix where it can't.

The goal is to remove uncertainty before a change ships, not to rely on an emergency undo after it's already in production.

3. Unify Delivery Workflows

The biggest opportunity is bringing infrastructure, application, and database delivery into a single operational framework. Instead of coordinating separate workflows by hand, platform teams orchestrate them through one pipeline, so application deployment, infrastructure provisioning, and database migration run as a single coordinated motion, governed consistently rather than stitched together by hand.

From Infrastructure as Code to Delivery as Code

The next phase of platform engineering extends the code-driven model beyond infrastructure to delivery itself. Call it Delivery as Code: the principles that made infrastructure programmable, applied to how every change ships, databases included.

In practice that means three things.

Database Pipelines

Database changes move through controlled promotion workflows rather than ad hoc scripts, so each one is reviewed, tested, and promoted environment to environment like application code. 

Policy Enforcement

Governance gets codified through policy engines such as Open Policy Agent, so the rules that used to live in someone's head become enforceable at the pipeline:

• No dropping production tables
• No violating naming standards
• No deploying unapproved schema changes to prod

AI-Assisted Operations

AI begins to absorb the repetitive operational work, helping draft migration definitions and validation checks so engineers spend less time on boilerplate and more on the changes that actually need judgment.

The goal isn't replacing engineers. It's removing the repetitive operational toil so they can focus on higher-value work.

Building a Unified Delivery Platform

Platform teams are facing a new reality. AI-generated code is increasing development velocity dramatically, and more changes are entering delivery systems than ever before. When application deployment is automated but database delivery stays manual, the database becomes the bottleneck, and the fix isn't more coordination meetings. It's a unified delivery model where:

• Infrastructure changes are version-controlled.
• Database changes are version-controlled.
• Governance is codified.
• Testing is automated.
• Rollbacks are built into workflows.

That's a delivery system that can scale alongside modern software development. Infrastructure as Code was the first step. Database DevOps is the next one.

Conclusion

Infrastructure as Code fundamentally changed software delivery by making infrastructure programmable.

But modern systems are more than infrastructure.

Applications, databases, policies, and delivery workflows must operate as a coordinated system.

As software delivery accelerates—particularly with the rise of AI-generated code—database delivery can no longer remain a separate operational process.

Platform teams that unify infrastructure, application, and database workflows will be better positioned to deliver software faster, safer, and with greater operational confidence.

Ready to see how Harness helps platform teams bring database delivery into the modern software delivery lifecycle? Explore Harness Database DevOps and Infrastructure as Code Management.

FAQ

What is Database DevOps?

Database DevOps applies DevOps principles to database changes, including version control, automation, testing, governance, and CI/CD workflows.

Why isn't Infrastructure as Code enough for databases?

Infrastructure as Code manages infrastructure state but does not address schema changes, data migrations, rollback workflows, or database governance.

Why can database changes be riskier than infrastructure changes?

Database changes modify persistent production data. Unlike infrastructure resources, databases often cannot be recreated without business impact.

How does Database DevOps improve software delivery?

It enables automated testing, version-controlled changes, rollback capabilities, and coordinated application and database deployments.

What role does GitOps play in database delivery?

GitOps provides version control, auditability, and workflow automation for database schema changes and migration management.

Can Harness DB DevOps be integrated into CI/CD pipelines?

Yes. Database DevOps integrates natively with Harness Continuous Delivery, so schema management, validation, and rollback run as steps in the same pipeline as your application deployments. If you run a different CI/CD tool, those same capabilities can be invoked from your existing pipelines instead.

How does Harness AI help database delivery?

Harness has an AI powered schema authoring capability, which can assist with migration generation, so engineers spend less time on boilerplate and more on the changes that need real judgment. Governance and approval controls stay in place regardless of how a change was authored.