Modern software releases rarely consist of application code alone. A new feature might require additional database tables, modified columns, new indexes, updated constraints, or reference data changes. While many organizations have successfully automated application deployments, database schema migrations often remain disconnected from the rest of the software delivery process.

This separation creates deployment bottlenecks, increases operational overhead, and introduces unnecessary risk.

Application teams may deploy code through automated Continuous Delivery (CD) pipelines, while database changes are managed through separate processes, manual approvals, or standalone tooling. The result is a fragmented release workflow where application and database changes must be done manually. In this article, we'll explore how Harness Continuous Delivery (CD) and Harness Database DevOps (DBDevOps) enable teams to deploy database and application changes through a unified pipeline, improving release velocity, visibility, governance, and deployment safety.

Why Database Schema Migrations Should Be Part of Your CD Pipeline?

Applications and databases are now a days mostly tightly coupled and an application release may depend on:

• New tables
• Additional columns
• Updated indexes
• Modified constraints
• New database objects

When application deployments and database schema migrations happen independently, teams often encounter several challenges.

Manual Coordination

Application and database teams must coordinate release schedules and deployment windows.

Deployment Risk

Applications may be deployed before required database changes are available, resulting in runtime failures or broken functionality.

Limited Visibility

Teams often struggle to answer questions such as:

• Which database schema migrations have been deployed?
• Which environments are running the latest schema version?
• What changes were included in a release?

Complex Rollbacks

• Application rollbacks are generally straightforward.
• Database rollbacks can become significantly more complicated when deployments are managed through separate workflows.
• A unified deployment process helps eliminate these challenges by treating database schema migrations as a first-class part of software delivery.

What a Unified Deployment Pipeline Looks Like

Instead of managing application and database releases separately, teams can orchestrate both through a single deployment pipeline.

This approach ensures database and application changes remain synchronized throughout the deployment lifecycle.

Deploying Database Schema Migrations and Applications Together

Let's examine a practical example using Harness Database DevOps and Harness Continuous Delivery. The deployment stage consists of three primary phases:

1. Apply database schema migrations
2. Deploy the application
3. Verify deployment health and initiate rollback when necessary

Phase 1: Apply Database Schema Migrations

The deployment begins by applying database changes using the Harness Database DevOps schema deployment step.

- step:
    type: DBSchemaApply
    name: Apply Database Schema
    identifier: Apply_Database_Schema
    spec:
      connectorRef: account.harnessImage
      migrationType: Liquibase
      dbSchema: bookkeeper
      dbInstance: goodinstance
      tag: v1.0.0

The DBSchemaApply step executes the database schema migration associated with the specified release version. By versioning database changes and deploying them through a pipeline, teams gain:

• Consistent database schema migration across environments
• Controlled promotion between development, staging, and production
• Deployment traceability
• Improved governance and auditability

Most importantly, database changes are deployed automatically as part of the release process rather than through a separate operational workflow.

Phase 2: Deploy the Kubernetes Application

After the database schema migration completes successfully, the pipeline proceeds with the application deployment.

- step:
    name: Deploy Application
    identifier: rolloutDeployment
    type: K8sRollingDeploy
    timeout: 10m
    spec:
      skipDryRun: true
      pruningEnabled: false

The K8sRollingDeploy step performs a rolling deployment to Kubernetes, gradually replacing existing application instances with the new version while maintaining service availability. Because the database schema migration has already been applied, the application can safely consume:

• Newly created tables
• Updated columns
• Additional indexes
• New constraints
• Modified database structures

This sequencing helps eliminate compatibility issues that commonly occur when application and database deployments are managed separately.

Automated Rollback for Safer Releases

One of the most valuable aspects of a unified deployment pipeline is coordinated rollback. If verification identifies an issue, the stage can automatically trigger rollback actions.

failureStrategies:
  - onFailure:
      errors:
        - AllErrors
      action:
        type: StageRollback

The rollback workflow executes the Kubernetes rollback step:

rollbackSteps:
  - step:
      type: K8sRollingRollback
      name: Rollback Rollout Deployment

This enables teams to quickly restore the previous application version and minimize production impact. Combined with database deployment visibility and rollback strategies, organizations can significantly reduce deployment risk and improve recovery times.

Benefits of Combining Continuous Delivery and Database DevOps

• Faster Release Velocity: Database and application changes move through a single automated workflow without waiting for separate deployment windows.
• Safer Database Schema Migrations: Version-controlled database schema migrations help ensure consistency across environments.
• Improved Visibility: Teams gain centralized insight into deployments, migration history, and release status.
• Better Governance: Approval workflows, policies, and compliance requirements can be enforced directly within deployment pipelines.
• Reduced Deployment Risk: Verification and rollback become built-in parts of every release.
• Stronger Collaboration: Developers, platform engineers, and database teams work from the same deployment process rather than maintaining separate release workflows.

Bringing Database Schema Migration into Modern Continuous Delivery

Database schema migration should not be treated as a separate operational activity. Modern software delivery requires application code and database changes to move together through a secure, automated, and governed deployment process. Harness Database DevOps enables teams to:

• Automate database schema migrations
• Integrate database deployments into CI/CD pipelines
• Manage version-controlled database changes
• Apply governance and compliance controls
• Support rollback and recovery workflows
• Deploy applications and databases together through a unified pipeline

By combining Harness Continuous Delivery and Harness Database DevOps, organizations can streamline releases while reducing deployment risk and improving operational efficiency.

Conclusion

Application releases and database schema migrations are two parts of the same deployment. Managing them separately creates unnecessary complexity, increases risk, and slows delivery.

By orchestrating database schema migrations, Kubernetes deployments, verification, and rollback within a single pipeline, teams can build a more reliable and efficient release process. Harness Database DevOps and Continuous Delivery provide the foundation for modern software delivery, enabling organizations to deploy applications and database changes together with greater confidence, visibility, and control. Explore how Harness Database DevOps can transform your delivery process today.

FAQs

1. What is a database schema migration?

A database schema migration is a version-controlled change to a database structure. Examples include creating tables, adding columns, modifying indexes, updating constraints, or introducing new database objects. Database schema migrations ensure that database changes can be tracked, reviewed, and deployed consistently across environments.

2. Why should database schema migrations be included in a Continuous Delivery pipeline?

Including database schema migrations in a CD pipeline ensures application and database changes are deployed together. This reduces deployment risk, improves consistency across environments, simplifies release management, and provides better visibility into the overall deployment process.

3. How does Harness Database DevOps support database schema migration?

Harness Database DevOps enables teams to automate database schema migrations through pipelines, manage version-controlled database changes, enforce governance policies, support rollback workflows, and orchestrate database deployments alongside application deployments within a unified release process.

‍

Modern applications do not just depend on schema changes. They also depend on data that powers the application itself.

Things like dropdown values, feature flags, country codes, user roles, pricing tiers, workflow statuses, or internal configurations are often stored inside database tables. This is called reference data. Even though this data may look small, it is critical to the application. A wrong value can break workflows, show incorrect information to users, or create production issues.

In this blog, we will look at a clean and safe way to manage reference data updates using Harness Database DevOps with Liquibase OSS compatible changelogs. We will also see how to safely roll back data changes when something goes wrong.

Why Reference Data Needs Version Control

Many teams still update reference data manually.

Someone runs an SQL update in production. Another person edits rows directly from a database UI. Sometimes CSV imports happen without tracking.

This creates several problems:

• Nobody knows who changed the data.
• There is no rollback process.
• Different environments become inconsistent.
• Testing becomes difficult.
• Deployments become risky.

Over time, this also creates environment drift between development, staging, and production databases.

Database DevOps solves this by treating reference data like application code. Where the data lives in Git and the changes are reviewed through pull requests. Database deployments take place through pipelines and rollback workflows become predictable.

This gives teams consistency, governance, and traceability across every environment.

A Better Pattern for Managing Reference Data

One of the safest patterns for updating reference data is:

1. Store reference data inside versioned CSV files
2. Commit those files to Git
3. Use the loadUpdateData change type
4. During deployment, apply the new CSV version
5. During rollback, deploy the previous CSV version

This approach works especially well for database CI/CD and database deployment automation workflows. It also aligns nicely with GitOps-style database management where every change is versioned and auditable.

For example, the Harness community maintains a Terraform onboarding template that helps teams provision and onboard Harness Database DevOps resources directly from CSV files.

Real-World Examples of Reference Data

Teams commonly use this pattern for:

• Product pricing tiers
• Feature flags
• Internal application settings
• Country and currency mappings
• Approval workflow statuses
• Lookup tables used by frontend applications

These datasets are often tightly connected to application behavior, which makes safe deployments and rollback strategies extremely important.

Example Scenario

Imagine your application has a table called subscription_tiers. The application reads values from this table to display pricing plans inside the UI.

Your current data looks like this:

Now your product team wants to add a new Enterprise tier with help of subscription_tiers-v2.csv. Instead of manually inserting rows into production, we can version this data properly.

Step 1: Store Data in Versioned CSV Files

Inside your repository, create a folder for reference data.

reference-data/
├── subscription_tiers-v1.csv
├── subscription_tiers-v2.csv

The version suffix is important, this makes deployments predictable and makes rollback much easier and teams can quickly identify which dataset version was deployed to each environment.

Step 2: Use loadUpdateData

Now create a Liquibase OSS compatible changelog YAML file.

databaseChangeLog:
  - changeSet:
      id: subscription-tier-v2
      author: animesh
      changes:
        - loadUpdateData:
            file: reference-data/subscription_tiers-v2.csv
            tableName: subscription_tiers
            primaryKey: id
            separator: ","
            quotchar: "\""
      rollback:
        - loadUpdateData:
            file: reference-data/subscription_tiers-v1.csv
            tableName: subscription_tiers
            primaryKey: id
            separator: ","
            quotchar: "\""

This is the important part:

• During deployment, Harness Database DevOps executes the changelog and loads subscription_tiers-v2.csv.
• During rollback, the pipeline reloads subscription_tiers-v1.csv.

This creates a rollback-ready deployment workflow without requiring manual SQL fixes during incidents.

How This Fits into Database DevOps?

In a modern Database DevOps workflow, every database change should move through the same CI/CD process.

That includes:

• Schema changes
• Stored procedures
• Reference data
• Permissions
• Seed data

Reference data should not bypass governance. When reference data lives in Git, teams gain much better operational control:

• Developers can review changes before deployment.
• QA teams can validate updates in staging environments.
• DBAs keep database deployment automation in environments consistent.
• Rollback steps are already prepared before production deployment begins.

And this significantly reduces operational risk for the team.

Using Harness Database DevOps for Reference Data Deployments

While many teams have adopted CI/CD for application deployments, database updates often remain tied to manual workflows, increasing risk particularly with reference data.

Harness Database DevOps bridges this gap by enabling automated reference data management. By utilizing Liquibase OSS compatible changelogs and storing CSV files in Git as deployment artifacts, teams can bring database changes into their standard delivery pipelines.

This approach provides several key benefits:

• Full traceability through Git commits, pull requests, and pipeline history.
• Environmental consistency by moving the same reference data from development through production without manual intervention.
• Coordinated delivery by integrating database updates directly into existing application release pipelines.
• Enhanced governance via automated policy checks, audit logs, and approval gates.

Git-driven workflows are particularly advantageous for large-scale operations. To support this, the Harness community offers Terraform onboarding templates that facilitate CSV-driven resource provisioning, helping organizations standardize database operations.

This workflow ensures that rollbacks are integrated from the start. If an update causes an issue, teams can rapidly redeploy the previous CSV version using pre-defined rollback steps in the changelog. This result is a more predictable and secure delivery process for both operations and development teams.

But The Rollbacks Are the Real Advantage

Most teams focus mainly on deployments. But mature Database DevOps practices depend heavily on reliable rollback strategies. Reference data changes can fail for many reasons. The application may still expect an older value. Unexpected data changes can break the UI. 

A feature flag might get enabled too early. Without rollback automation, production recovery becomes stressful and slow. Using versioned CSV files with loadUpdateData keeps the rollback process simple. Since the previous working version already exists, recovery becomes much faster. That simplicity becomes extremely valuable during production incidents.

Conclusion

This streamlined lifecycle leverages automated pipelines to manage updates and rapid recoveries. Standardizing reference data management aligns database deployments with modern CI/CD best practices. Explore how Harness Database DevOps can transform your delivery process today.

FAQs

How does Harness Database DevOps fit into this workflow?

Harness Database DevOps automates Liquibase OSS compatible changelogs through governed pipelines with Git traceability and rollback support.

Can Harness Database DevOps handle both schema and data deployments?

Yes. Harness Database DevOps supports schema changes, reference data updates, stored procedures, and rollbacks in one workflow.

What is the safest way to rollback reference data changes?

Use versioned CSV files with loadUpdateData. Deploy the new CSV during apply and reload the older CSV during rollback.

Is Liquibase OSS better than Flyway Community for reference data updates?

Liquibase OSS supports rollback logic and loadUpdateData, making reference data versioning easier than Flyway Community.

• 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.

Database migrations are rarely just about changing schema. In real production systems, every migration has to preserve three things at the same time: application availability, data consistency, and compatibility across versions. That is the hard part.

When teams say they want “100% uptime,” what they usually mean is no planned downtime during deployments and no user-visible interruption while the application and database are evolving. That goal is realistic, but only if the migration strategy is designed around compatibility from the start.

The Real Objective: Compatibility First, Cleanup Later

A migration should never assume that the new application version is the only code touching the database. During a rolling deployment, blue-green cutover, or staged rollout, both versions may run side by side for a period of time.

That creates a simple rule: “Every schema change must be safe for the current app version and the next app version.” If your schema is not designed for this overlap, you introduce:

• Runtime failures
• Data inconsistencies
• Forced downtime

The solution is not complex tooling, it's the correct migration strategy. Since the safe database migration is not just “correct” - it must be compatible across versions.

• Old application must continue to work
• New application must start working immediately
• Database must support both during rollout
• Database must ensure both versions of the application always see the same data, must ensure data integrity even while writing in it.

This is the foundation of zero downtime database migration.

Migration Patterns that Work in Production

‍

‍

These patterns follow the same rule: never break existing reads or writes during transition.

The Safest Rollout Sequence

This is the real test of a safe migration. The old version may still:

• Read a deprecated column,
• Expect a legacy enum value,
• Or write a field that the new version no longer prefers.

The new version may:

• Depend on a new column,
• Expect a new constraint,
• Or write into a split schema.

To support both, design the transition so that:

• The old app still sees valid data,
• The new app can start using new structures immediately,
• And the schema does not force an all-or-nothing deployment.

That is why additive changes and compatibility windows matter more than raw speed. This aligns with real-world pipelines where schema and application changes are decoupled but coordinated.

Keeping Old and New Structures in Sync

During migration, both schema versions may remain active simultaneously.

This creates a synchronization window where:

• Old application versions may still write legacy fields,
• New versions may write updated structures,
• And both new and old representations must remain consistent.

Common synchronization approaches include:

• Database triggers,
• Change data capture (CDC),
• Tansactional dual writes,
• Event-driven synchronization pipelines.

Without synchronization safeguards, post-migration edits can cause data divergence between old and new schemas.

A Practical Deployment Pattern That Mirrors Real Pipelines

Your pipeline example reflects the same deployment philosophy: application rollout, schema application, and controlled progression are separated into explicit steps rather than collapsing everything into one risky event. That is exactly the kind of sequencing needed for production-safe migrations. 

In a mature release process, a database migration stage should be treated as a release gate, not a side effect. The schema change should happen only when the release pipeline has proven that the next application version can coexist with the previous one.

That is how you preserve uptime without gambling on runtime behavior.

What Is the Expand-and-Contract Pattern?

The expand-and-contract pattern is a phased migration strategy used to evolve database schemas safely without downtime. It works in three stages:

1. Expand - Introduce new schema structures without removing old ones.
2. Migrate - Keep old and new structures synchronized while applications transition.
3. Contract - Remove deprecated schema only after all traffic has migrated.

This allows both old and new application versions to operate safely during deployment.

Best Practices for Zero Downtime Database Migrations

Key best practices for zero downtime database migrations include:

• Use the expand-and-contract pattern
• Avoid destructive changes during active deployments
• Ensure backward and forward compatibility and ensure both versions of the app will always see the same data.
• Run idempotent, incremental backfills
• Monitor and validate data consistency continuously

These practices minimize risk and ensure smooth production rollouts.

Frequently Asked Questions

1. How can I migrate a database without downtime?

To migrate a database without downtime, use a phased, backward-compatible approach:

• First, apply non-breaking schema changes (add columns, avoid deletions)
• Perform background data backfills in small batches
• Release the updated service version utilizing synchronized dual-write operations.
• Gradually shift reads to the new schema
• Remove old schema only after all traffic is migrated

This approach ensures continuous availability during the migration process. 

Application-layer dual writes alone do not guarantee consistency. Failures between writes, retries, or partial transaction completion can still introduce divergence between old and new structures. In relational systems, teams often use triggers, CDC pipelines, or transactional synchronization to reduce drift risk during migration windows.

2. What is backward compatible schema design in database migrations?

Backward compatible schema design means structuring database changes so that existing application versions continue to function without modification.

For example:

• Adding a nullable column is backward compatible
• Renaming or dropping a column is not

This is critical during rolling deployments where multiple application versions interact with the database simultaneously.

3. What are the risks of database schema changes in production?

Common risks of database schema changes in production include:

• Breaking compatibility with running application versions
• Causing downtime due to locks or blocking queries
• Data inconsistency can also occur when edits continue in the old schema after migration, but synchronization mechanisms fail to propagate those updates into the new structure.
• Making rollback difficult or unsafe

These risks can be mitigated by using safe migration patterns, staged rollouts, and compatibility-first database design. For example, if a trigger, CDC stream, or synchronization process misses an update, the old and new representations may diverge silently.

Modern data platforms are evolving rapidly, and Google Cloud BigQuery has become a core part of analytics, AI, and large-scale reporting architectures. Teams (including Harness) rely on BigQuery to process and analyze massive datasets, but managing schema changes in a secure, repeatable way can still be challenging.

Today, we’re excited to announce BigQuery support for Harness Database DevOps, enabling teams to bring the same automation, governance, and reliability they expect from application DevOps to their BigQuery deployments.

With this release, organizations can now manage BigQuery schema changes using pipeline-driven Database DevOps workflows directly within Harness, while also leveraging secure OIDC-based authentication for keyless access.

The Challenge: Managing BigQuery Changes at Scale

BigQuery helps organizations move fast with data, but database change management often remains manual and fragmented.

Common challenges include:

• Manual schema deployments that slow down releases
• Limited visibility into schema changes across environments
• Inconsistent promotion workflows between development, staging, and production
• Managing long-lived service account keys
• Difficulty enforcing governance and approvals

Without a standardized deployment process, teams struggle to balance speed, reliability, and security.

Bringing Database DevOps to BigQuery

Harness Database DevOps now supports BigQuery as a first-class database platform, allowing teams to manage schema changes through automated, pipeline-driven workflows.

This means BigQuery schema changes can now be treated just like application code versioned, tested, approved, and promoted through environments using Harness pipelines.

With BigQuery support, teams can:

• Automate schema deployments using Harness pipelines
• Version control database changes alongside application code
• Promote changes consistently across environments
• Enforce approvals and governance policies before production releases
• Track and audit deployments with full visibility
• Eliminate static credentials using OIDC authentication

The result is a modern Database DevOps workflow for BigQuery that helps teams release faster without sacrificing security or reliability.

Key Capabilities

Native BigQuery Integration

Harness Database DevOps can now connect directly to BigQuery environments using BigQuery JDBC connector powered by the Simba BigQuery JDBC driver.

Example JDBC URL:

jdbc:bigquery://https://www.googleapis.com/bigquery/v2:443;ProjectId=YOUR_PROJECT_ID;DefaultDataset=YOUR_DATASET;Location=YOUR_REGION;

OAuth access tokens are injected automatically during authentication, removing the need for manual credential management. 

Secure OIDC-Based Authentication

Harness supports OIDC authentication using GCP Workload Identity Federation, allowing teams to securely authenticate to BigQuery without storing long-lived service account keys. 

During pipeline execution:

• Harness generates a short-lived OIDC token
• GCP Security Token Service exchanges the token
• Temporary credentials are generated dynamically
• Harness securely authenticates to BigQuery at runtime

This improves:

• Security posture
• Compliance readiness
• Credential management
• Operational reliability

No static JSON keys are stored in Harness or delegate environments. 

Automated Database Change Pipelines

Use Harness pipelines to automate BigQuery schema deployments with repeatable workflows across environments.

Teams can:

• Trigger deployments from Git changes
• Standardize promotion workflows
• Validate changes before production releases
• Automate schema delivery using CI/CD

Governance and Control

Leverage Harness approval gates, RBAC, and policy enforcement to ensure safe production changes. This helps organizations introduce governance into analytics database deployments without slowing down delivery velocity.

Deployment Visibility and Auditability

Track every BigQuery deployment with:

• Pipeline execution history
• Deployment logs
• Approval records
• Change visibility across environments

This creates a more transparent and auditable deployment process for data teams.

Why This Matters

As organizations increasingly rely on BigQuery to power analytics and AI workloads, database changes require the same level of automation and governance as application deployments.

By bringing BigQuery into Harness Database DevOps, teams can:

• Reduce manual deployment risk
• Improve collaboration between platform and data teams
• Standardize analytics database release processes
• Improve security with keyless authentication
• Accelerate delivery of data platform changes

Getting Started

BigQuery support for Harness Database DevOps is now available.

To get started:

1. Configure a BigQuery JDBC connector in Harness
2. Enable OIDC authentication using GCP Workload Identity Federation
3. Add BigQuery change scripts to your repository
4. Create a Harness pipeline to deploy and promote changes
5. Automate BigQuery releases with confidence

Learn More on setting up our documentation.

Learn More

To learn more about using BigQuery with Harness Database DevOps, check out our documentation or schedule a demo. 

Additional Resource - Warehouse Native BigQuery Integration

On May 16th, 2026, Inspired by the growing MongoDB and DevOps community in Bengaluru, we partnered with the Namma MUG community to bring together engineers exploring automation, CI/CD, Infrastructure as Code, and database migration strategies for modern applications.We had been looking forward to for a long time at Harness, our first Database DevOps community event in India focused on MongoDB and modern database automation practices.

The event was a deep dive for experts into how database automation can work with MongoDB easily, without needing manual steps.

My session on OSS Native Mongo Executor initiative was attended by several engineers already using tools like Liquibase, Flyway, and ORM driven migration workflows. That led to incredibly valuable conversations around what Database DevOps should look like for MongoDB-native environments.

Interestingly, many attendees wanted to understand:

• How Harness DBDevOps works internally
• How pipelines orchestrate MongoDB deployments
• How changelog-driven workflows compare against traditional scripting
• Whether Liquibase-style workflows can fit naturally into MongoDB ecosystems
• How rollback and migration tracking works in NoSQL environments

We also had several deep discussions around CI/CD production rollout strategies and the differences between native Mongo execution and traditional relational migration engines.

These discussions were incredibly insightful because they showed that teams are no longer thinking only about “Database Scripts” - they are thinking about full database delivery workflows integrated into DevOps platforms.

What the Community Told Us

One clear thing we heard throughout all our discussions was how much people want easier ways to get started and more hands-on examples for working with MongoDB DevOps. People kept asking us for simple guides for beginners, real examples of how to set up Continuous Integration and Continuous Delivery (CI/CD), starting templates, and clear steps for moving and rolling back databases from start to finish. We also got into some deep technical talks about handling complex queries, moving databases while they are live, and making sure our deployments are reliable, especially when we talk about advanced ways to undo changes. 

A lot of the attendees were really curious about how our MongoDB-native ways of doing migrations are different from the older, traditional database methods. That led us into bigger discussions about why using native MongoDB tools is important, how we manage schema changes in NoSQL, and the unique problems we face with document databases as we move from simple open-source tools to big enterprise-level Database DevOps systems. Overall, the reaction to our new OSS Native Mongo Executor was fantastic! It was clear that people really liked our approach of building Database DevOps features that fit naturally with MongoDB, instead of trying to force old relational rules onto a NoSQL system.

The future of Database DevOps is expanding beyond relational systems, and it’s exciting to see the MongoDB community helping shape that journey with us. A huge thank you to everyone who joined us, especially the speakers and community members who made the event successful: Naveen Kumar, Narendra Gottipati.Pritesh Kiri, Aripriya Basu

For us at Harness, this meetup made us realise something important: The community is actively looking for better ways to automate MongoDB operations while maintaining reliability, governance, and developer velocity. We have a lot more events coming up which you can join - Harness · Events Calendar

‍

‍

The Gap: Modern DevOps Stops at the Database

Most development teams today build everything around Git, and deploy with GitOps principles.

Code sits in version controlled environments, changes go through PRs, and deployments are handled through modern CI/CD. That part is pretty standard at this point, especially when using a modern DevOps platform like Harness.

MongoDB fits into that developer world and workflow pretty naturally. Data is stored in documents that look a lot like JSON, the format many developers already use in application code and APIs. Under the hood, MongoDB stores those documents as BSON, which is essentially a binary form of JSON that supports additional data types like dates, object IDs, and binary data. That means developers get a familiar model to work with, while MongoDB gets a format that is efficient for storing and querying application data. 

Looks just like JSON, with native types like ObjectId and dates powered by BSON.

The tradeoff is that structure isn’t always defined upfront. Schemas change over time, and not always in a clean or consistent way.

Collections can contain documents with different shapes. Index changes can directly impact performance. These aren’t problems on their own, but they require discipline to manage safely.

MongoDB changes are often handled outside the standard development workflow, whether that’s by developers, platform teams, or database teams.

Teams rely on application-level updates or one-off scripts to backfill data, modify structures, or create indexes. These approaches work, but they’re not always consistently versioned in Git. Execution can vary across environments, and review or validation is often informal.

The result is limited visibility into what changed, when it changed, and how it was applied. Over time, that leads to inconsistencies between environments and increased risk during deployment. 

Flexibility is powerful, but without proper controls it introduces risk.

To solve this, teams need to bring MongoDB changes into the same workflow they already trust for application code: Git-driven, reviewable, and automated.

What GitOps for MongoDB Actually Looks Like

GitOps for MongoDB isn’t about changing how Mongo works. It’s about changing how changes are managed.

Instead of handling updates through scripts or application logic alone, database changes are treated like application code. Index creation, schema validation rules, and migration scripts are all defined in Git and tracked over time. This includes MongoDB’s native schema validation rules, which can be versioned and applied consistently across environments.

Changes need to go through pull requests, just like any other code change. This allows developers, platform teams, and DBAs to review what’s being modified before anything runs in an environment.

From there, pipelines handle the validation and deployment. Changes are applied consistently across environments, rather than being run manually and potentially differently each time.

In practice, this means a new field, an index, or a backfill isn’t just a script someone runs once. It’s a versioned change that can be reviewed, tested, and repeated.

This isn’t about forcing rigid schemas onto MongoDB. It’s about making changes visible, consistent, and easier to manage as systems grow.

Harness DB DevOps provides the structure to do this. With Harness, we define changes as changesets, store them in Git, and deploy them through pipelines with built-in validation and policy checks.

To demonstrate how this works, we will walk through a practical MongoDB change from start to finish.

Example: Managing a MongoDB Change End-to-End

Here’s a simple example: A team needs to add a new userPreferences field to the users collection and create an index to support a new query.

Instead of writing a script and running it manually, we define the change and commit it to Git.

1. Define the change in Git
A developer creates the update as a changeset. That includes the logic to add or backfill the new field, along with the createIndex operation needed for performance. The change is committed alongside application code, like any other update.

2. Open a pull request
From there, the change goes through a pull request. Other developers or DBAs can review what’s being changed before anything runs. If something looks off, it gets caught here instead of in production.

3. Let the pipeline take over
Once the change is approved, the pipeline takes over.

The Pipeline

Before anything gets applied, the change is validated and previewed against the target environment. This helps catch issues early, whether it’s a conflict, a bad query pattern, or something that could impact performance.

This is especially important for heavy operations like index creation on massive collections, where resource contention and performance degradation are real risks. Instead of running those changes manually, pipelines can enforce safe rollout strategies like rolling index creations across replica sets, without manual intervention.

Policies are enforced as part of that same process, with required approvals, environment rules, and other guardrails checked automatically so teams aren’t relying on someone to manually verify every step.

Once everything passes, the change is deployed through the pipeline and applied consistently across environments, moving from dev to staging to production in a controlled way. No one is logging into a database to run scripts by hand.

Now, everything is tracked. You can see what was applied, where it was deployed, when it happened, and who approved it, with a full history available if something needs to be reviewed or rolled back later.

Sound familiar? This workflow should sound a lot like application delivery, where changes are versioned, reviewed, validated before deployment, and visible after.

From Manual Oversight to Guardrails

Traditionally, database changes have been tightly controlled by DBAs. They review scripts, approve changes, and sometimes execute them manually in each environment. That model helps reduce risk, but it doesn’t scale as teams grow and release more frequently.

With a GitOps approach, that control doesn’t disappear, it moves earlier in the process.

Instead of reviewing every individual change, database teams define policies and standards up front. Those rules are then enforced automatically through pipelines. Every change must pass the same checks before it reaches an environment, without requiring manual intervention each time.

In practice, this means:

• Required approvals are enforced automatically
• Deployment rules are validated before execution
• Production environments can have stricter controls than lower environments
• Policies are applied consistently across every change

The role of the database team evolves from gatekeeper to system designer. Rather than being involved in every deployment, they define the guardrails that ensure every deployment is safe.

Developers still move quickly, but now within a controlled, repeatable system.

What Teams Actually Gain

Bringing MongoDB into a Git-driven workflow changes how teams ship.

• Faster delivery
  Developers don’t wait on manual reviews or execution. Changes move through the same workflow as application code.
• Consistent environments
  Changes are applied the same way every time, reducing drift between dev, staging, and production.
• More predictable deployments
  Validation and policy checks happen before execution, catching issues earlier and reducing surprises.
• Built-in auditability
  Every change is versioned, reviewed, and tracked, with full visibility into what changed, when, and why.

MongoDB's flexibility doesn't eliminate the need for structure - it just shifts the responsibility for maintaining consistency from the database itself to your development processes.

If your application is managed through Git, your database should be too.

Schedule a demo

If you've ever run an ALTER TABLE on a busy MySQL table in production, you know the feeling. The change is small. The risk isn't. Long-running table locks, queued writes, application timeouts, replication lag, a five-minute migration that turns into a half-hour incident review.

We're shipping an integration that takes that anxiety out of the loop. Harness Database DevOps now supports Percona Toolkit for MySQL as part of Liquibase-based schema management. Flip a checkbox at schema creation, and eligible changes execute through pt-online-schema-change instead of native MySQL DDL.

Why it matters

Native ALTER TABLE on MySQL can lock tables for as long as the change takes to apply. On a large or hot table, that means writes pile up, dependent services start timing out, and replicas fall behind.

Percona Toolkit handles the same change very differently. pt-online-schema-change creates a shadow table with the new schema, copies your data over in small chunks, uses triggers to keep the original and shadow tables in sync, then performs an atomic swap with minimal lock time. The practical upside: schema changes you can run during business hours, not at 2 AM with a runbook open.

How to turn it on

The integration is enabled per schema. When you create a Database Schema in Harness DB DevOps:

1. Fill in your MySQL connection details.
2. Select Liquibase as your schema configuration.
3. Check the box labeled Use Percona Toolkit.
4. Save and continue with your normal workflow.

That's it. With the box unchecked (the default), Harness DB DevOps applies your changelogs using native MySQL operations through Liquibase, exactly as before. Check it, and eligible changes route through Percona Toolkit instead.

Things worth knowing before you flip the switch

Percona Toolkit isn't a silver bullet for every DDL. A few cases need extra thought.

Adding or dropping foreign keys can break during the table swap, so plan those changes carefully or apply them outside the toolkit. Tables without a primary key or unique index won't migrate safely either, since pt-online-schema-change needs one to chunk data deterministically. And a handful of specific operations sit outside the safe-change envelope: dropping a primary key, complex column reordering, and some storage engine swaps.

You'll also want to give the database user the right privileges: ALTER, SELECT, INSERT, and UPDATE on the target table, plus CREATE and DROP on the database for shadow table management.

The full list of supported patterns, edge cases, and required permissions is in the Harness DB DevOps docs.

Try it on your next migration

If you're already running Harness DB DevOps for MySQL, the next schema you create is a good place to try this. Turn it on against a non-critical environment first, watch how it behaves on your workload, and the path to using it in production gets a lot shorter.

For teams running MySQL at scale, that's one fewer reason to schedule schema changes around your customers' sleep.

If you aren't already using Database devops, speak with our experts to discuss how you can achieve zero downtime database schema migrations.

Introduction: Governance Must Be Built Into Delivery

Database changes are inherently complex: coordinating schema updates, managing risk, and avoiding downtime all require care. Even when teams improve how they deliver those changes, governance often remains inconsistent, manual, and reactive.

In many environments, governance is treated as a separate layer around deployment. Policies are applied unevenly, approvals become bottlenecks, and audit evidence is assembled after the fact, creating gaps in enforcement and increasing operational risk.

Effective governance must be enforced as part of how changes are delivered. With Harness Database DevOps, governance is built directly into the deployment pipeline, where each change is evaluated against defined policies before execution based on context such as environment, database type, and deployment configuration.

Pre-Execution Governance with Policy-as-Code

The most effective way to enforce governance is to evaluate changes before they are applied.

With Harness, database changes are analyzed prior to execution using policies defined through Open Policy Agent (OPA). These policies evaluate the SQL being applied along with its context, including the target environment and database type.

Policies can enforce context-aware rules, such as restricting destructive operations in production while allowing flexibility in development environments. Governance can also be adapted by environment. For example, policies that block deployments in production can surface warnings in lower environments, allowing issues to be identified and addressed earlier.

Because policies are defined as code, they can be versioned, reviewed, and updated alongside application and database changes. This ensures governance is applied consistently across teams and environments without relying on manual enforcement. Harness policies are applied across databases and migration tools, allowing teams to define policies once and enforce them consistently regardless of toolchain.

Governance as a System: Process and Consistency Across Environments

Effective governance extends beyond evaluating individual changes to ensuring that deployments follow the correct process.

Harness enforces this through pipeline-level controls, such as requiring changes to progress through defined environments and applying approvals where needed. These controls ensure that database changes follow consistent promotion paths, such as progressing from development to staging to production.

Governance is applied consistently even in complex environments where multiple teams use different database change tools or databases. Harness provides unified visibility and governance across tools such as Flyway and Liquibase, allowing policies to be defined once and enforced consistently regardless of the underlying toolchain.

By combining policy enforcement with structured workflows, teams can maintain control over how changes are delivered while reducing reliance on ad hoc reviews and manual coordination.

Auditability: Proving Enforcement and Change History

Harness provides a complete record of database activity across environments, including what changes were deployed, how they were executed, and who approved them.

In addition to change history, Harness maintains an audit trail of configuration changes to pipelines, policies, and governance settings. This allows teams to demonstrate that governance controls were consistently applied during a given period, simplifying audits by reducing the need to manually reconstruct evidence for each deployment.

Visibility Across Environments: Preventing Drift

Harness provides centralized visibility into database changes across environments, allowing teams to see what has been deployed where and when.

This visibility, combined with enforced deployment workflows, prevents cross-environment drift. Reporting and customizable dashboards extend this further, enabling teams to analyze delivery performance using metrics such as lead time and to track database changes as part of the broader software delivery process.

When used alongside Harness CD, teams can also view combined metrics across application and database changes, providing a more complete picture of delivery outcomes.

Conclusion: Governance That Scales With Delivery

Governance enforced before execution, defined as code, and applied consistently enables both control and scalability. But don’t take our word for it, just ask our customers.

Athena Health: “Harness gave us a truly out-of-the-box solution with features we couldn’t get from Liquibase Pro or a homegrown approach. We saved months of engineering effort and got more for less, with better governance, smarter change orchestration, and a clearer understanding of database state across teams and environments.”

By embedding governance directly into the delivery pipeline, teams can reduce manual oversight while improving compliance, consistency, and delivery speed.

‍

Testing database changes against production-like data removes risk from your delivery process but to be effective, it must be orchestrated, governed, and automated. Manual scripts and ad-hoc checks lack the repeatability and auditability required for modern delivery practices.

Harness Database DevOps provides a framework to embed production data testing into your CI/CD pipelines, enabling you to manage database schema changes with the same rigor as application code. Harness DB DevOps is designed to bridge development, operations, and database teams by bringing visibility, governance, and standardized execution to database changes.

Instead of treating testing with production data as an afterthought, you can define it as a pipeline stage that executes reliably across environments.

A Pipeline-Driven Reference Workflow

To incorporate production data testing into your delivery process, you define a Harness Database DevOps pipeline with structured, repeatable steps. The result is a governed testing model that captures evidence of correctness before any change ever reaches production.

Stage 1: Environment Provisioning and Data Preparation

In Harness Database DevOps, you begin by configuring the necessary database instances and schemas:

• DB Schemas are defined in Git, using Liquibase or Flyway changelogs or script-based SQL files under version control.
• DB Instances connect to your target environments with credentials and Delegate access configured.

For production data testing, you provision two isolated instances seeded with a snapshot of production data (secured and masked as needed). These instances are not customer-facing; they serve as ephemeral test targets.

This structure sets up identical baselines for controlled experimentation.

Stage 2: Schema Application Within a Harness Pipeline

Harness Database DevOps lets you define a deployment pipeline that incorporates database and application changes in the same workflow:

• Pipelines unify database deployments with application delivery.
• You add stages such as “Apply Schema Changes” that reference your DB Schema and DB Instance.

Using Liquibase or Flyway via Harness, the pipeline applies schema changes to Instance A while Instance B remains the baseline.

This step executes the migration in a real, production-scale context, capturing performance, constraint behaviors, and other runtime characteristics.

Stage 3: Automated Rollback and Undo Migration Testing

A powerful capability of Harness Database DevOps is automated rollback testing within the pipeline:

• The pipeline can execute undo migrations to revert schema changes.
• Pipelines track execution results and rollback outcomes, enabling teams to validate that undo logic works reliably.

Testing rollback paths removes the assumption that reversal will work in production, a key risk often untested in traditional workflows.

Stage 4: Comparison Against Baseline and Validation

After rollback, you compare Instance A (post-rollback) with Instance B (untouched):

• At this point, they should be identical in schema and data state.
• Tools designed for database comparisons (e.g., DiffKit) can be integrated to perform row-level and schema-level verification, highlighting hidden drifts or silent mutations.

If disparities are detected, the pipeline can fail early, prompting review and remediation before production deployment.

This approach builds evidence rather than assumptions about the quality and safety of database changes.

How This Aligns with Harness Capabilities?

The updated workflow aligns with the documented capabilities of Harness Database DevOps:

• Orchestration of database changes as part of CI/CD pipelines with visibility across environments.
• Governance and approvals, so schema changes are reviewed and compliant.
• Integrated rollback support for automated undo migrations.
• Unified interface and audit trails to track which changes ran where and when.

Importantly, the workflow does not assume native data cloning features within Harness itself. Instead, it positions data-centric operations (cloning and validation) as composable steps in a broader automation pipeline.

Strategic Outcomes for Engineering Teams

Embedding production data testing inside Harness Database DevOps pipelines delivers measurable outcomes:

• Reduced risk of production incidents by catching issues early.
• Repeatable, auditable delivery practices, aligning database changes with application code flows.
• Clear rollback evidence, not just theoretical promise.
• Improved collaboration between developers and DBAs through pipeline transparency.

This integrated, pipeline-oriented approach elevates database change management into a disciplined engineering practice rather than a set of isolated tasks.

Conclusion

Database changes do not fail because teams lack skill or intent. They fail because uncertainty is tolerated too late in the delivery cycle when production data, scale, and history finally collide with untested assumptions.

Testing with production data, when executed responsibly, shifts database delivery from hope-based validation to evidence-based confidence. It allows teams to validate not just that a migration applies, but that it performs, rolls back cleanly, and leaves no hidden drift behind. That distinction is the difference between routine releases and high-severity incidents.

By operationalizing this workflow through Harness Database DevOps, organizations gain a governed, repeatable way to:

• Treat database changes as first-class citizens in CI/CD
• Validate forward and rollback paths against real data
• Produce auditable proof of correctness before production
• Scale database delivery without scaling risk

This is not about adding more processes. It is about removing uncertainty from the most irreversible layer of your system. 

Explore a Harness Database DevOps to see how production-grade database testing, rollback validation, and governed pipelines can fit seamlessly into your existing workflows The fastest teams don’t just deploy quickly, they deploy with confidence.

Engineering teams are generating more shippable code than ever before — and today, Harness is shipping five new capabilities designed to help teams release confidently. AI coding assistants lowered the barrier to writing software, and the volume of changes moving through delivery pipelines has grown accordingly. But the release process itself hasn't kept pace.

The evidence shows up in the data. In our 2026 State of DevOps Modernization Report, we surveyed 700 engineering teams about what AI-assisted development is actually doing to their delivery. The finding stands out: while 35% of the most active AI coding users are already releasing daily or more, those same teams have the highest rate of deployments needing remediation (22%) and the longest MTTR at 7.6 hours.

This is the velocity paradox: the faster teams can write code, the more pressure accumulates at the release, where the process hasn't changed nearly as much as the tooling that feeds it.

The AI Delivery Gap

What changed is well understood. For years, the bottleneck in software delivery was writing code. Developers couldn't produce changes fast enough to stress the release process. AI coding assistants changed that. Teams are now generating more change across more services, more frequently than before — but the tools for releasing that change are largely the same.

In the past, DevSecOps vendors built entire separate products to coordinate multi-team, multi-service releases. That made sense when CD pipelines were simpler. It doesn't make sense now. At AI speed, a separate tool means another context switch, another approval flow, and another human-in-the-loop at exactly the moment you need the system to move on its own.

The tools that help developers write code faster have created a delivery gap that only widens as adoption grows.

What Harness Is Shipping

Today Harness is releasing five capabilities, all natively integrated into Continuous Delivery. Together, they cover the full arc of a modern release: coordinating changes across teams and services, verifying health in real time, managing schema changes alongside code, and progressively controlling feature exposure.

Coordinate multi-team releases without the war room

Release Orchestration replaces Slack threads, spreadsheets, and war-room calls that still coordinate most multi-team releases. Services and the teams supporting them move through shared orchestration logic with the same controls, gates, and sequence, so a release behaves like a system rather than a series of handoffs. And everything is seamlessly integrated with Harness Continuous Delivery, rather than in a separate tool.

Know when to stop — automatically

AI-Powered Verification and Rollback connects to your existing observability stack, automatically identifies which signals matter for each release, and determines in real time whether a rollout should proceed, pause, or roll back. Most teams have rollback capability in theory. In practice it's an emergency procedure, not a routine one. Ancestry.com made it routine and saw a 50% reduction in overall production outages, with deployment-related incidents dropping significantly.

Ship code and schema changes together

Database DevOps, now with Snowflake support, brings schema changes into the same pipeline as application code, so the two move together through the same controls with the same auditability. If a rollback is needed, the application and database schema can rollback together seamlessly. This matters especially for teams building AI applications on warehouse data, where schema changes are increasingly frequent and consequential.

Roll out features gradually, measure what actually happens

Improved pipeline and policy support for feature flags and experimentation enables teams to deploy safely, and release progressively to the right users even though the number of releases is increasing due to AI-generated code. They can quickly measure impact on technical and business metrics, and stop or roll back when results are off track. All of this within a familiar Harness user interface they are already using for CI/CD.

Warehouse-Native Feature Management and Experimentation lets teams test features and measure business impact directly with data warehouses like Snowflake and Redshift, without ETL pipelines or shadow infrastructure. This way they can keep PII and behavioral data inside governed environments for compliance and security.

These aren't five separate features. They're one answer to one question: can we safely keep going at AI speed?

From Deployment to Verified Outcome

Traditional CD pipelines treat deployment as the finish line. The model Harness is building around treats it as one step in a longer sequence: application and database changes move through orchestrated pipelines together, verification checks real-time signals before a rollout continues, features are exposed progressively, and experiments measure actual business outcomes against governed data.

A release isn't complete when the pipeline finishes. It's complete when the system has confirmed the change is healthy, the exposure is intentional, and the outcome is understood. 

That shift from deployment to verified outcome is what Harness customers say they need most. "AI has made it much easier to generate change, but that doesn't mean organizations are automatically better at releasing it," said Marc Pearce, Head of DevOps at Intelliflo. "Capabilities like these are exactly what teams need right now. The more you can standardize and automate that release motion, the more confidently you can scale."

Release Becomes a System, Not a Scramble

The real shift here is operational. The work of coordinating a release today depends heavily on human judgment, informal communication, and organizational heroics. That worked when the volume of change was lower. As AI development accelerates, it's becoming the bottleneck.

The release process needs to become more standardized, more repeatable, and less dependent on any individual's ability to hold it together at the moment of deployment. Automation doesn't just make releases faster. It makes them more consistent, and consistency is what makes scaling safe.

For Ancestry.com, implementing Harness helped them achieve 99.9% uptime by cutting outages in half while accelerating deployment velocity threefold.

At Speedway Motors, progressive delivery and 20-second rollbacks enabled a move from biweekly releases to multiple deployments per day, with enough confidence to run five to 10 feature experiments per sprint.

AI made writing code cheap. Releasing that code safely, at scale, is still the hard part.

Harness Release Orchestration, AI-Powered Verification and Rollback, Database DevOps, Warehouse-Native Feature Management and Experimentation, and Improve Pipeline and Policy support for FME are available now. Learn more and book a demo.

Data platforms are evolving rapidly, and Snowflake has become a cornerstone of modern data architectures. Teams rely on Snowflake to power analytics, machine learning, and business intelligence, but managing data warehouse changes in a safe, repeatable way can still be a challenge.

Today, we’re excited to announce Snowflake support for Harness DB DevOps, enabling teams to bring the same automation, governance, and reliability they expect from application DevOps to their Snowflake data warehouse changes. By combining application and Snowflake deployments into a consistent pipeline, teams can release confidently at speed.

With this release, organizations can now manage Snowflake schema changes using pipeline-driven database DevOps workflows directly within Harness.

The Challenge: Managing Snowflake Changes at Scale

Snowflake empowers teams to move fast with data, but data warehouse change management often remains a manual or fragmented process.

Common challenges include:

• Manual change deployments that introduce risk and slow down releases
  
• Limited visibility into schema changes across environments
  
• Inconsistent promotion workflows between development, staging, and production
  
• Difficulty enforcing governance and approvals
  
  

Without a standardized process, teams struggle to balance speed, control, and reliability.

Bringing Database DevOps to Snowflake

Harness DB DevOps now supports Snowflake as a first-class database platform, allowing teams to manage schema changes through automated, pipeline-driven workflows.

This means Snowflake schema changes can now be treated just like application code—versioned, tested, and promoted through environments using Harness pipelines.

With Snowflake support, teams can:

• Automate schema deployments using Harness pipelines
  
• Version control schema changes alongside application code
  
• Promote changes across environments with consistency and auditability
  
• Enforce approvals and governance policies before production releases
  
• Track and audit deployments with full visibility
  
  

The result is a modern Database DevOps workflow for Snowflake that helps teams release faster without sacrificing reliability.

Key Capabilities

Native Snowflake Integration

Harness DB DevOps can now connect directly to Snowflake environments, allowing teams to deploy and manage schema changes seamlessly.

Automated Database Change Pipelines

Use Harness pipelines to automate Snowflake data warehouse deployments with repeatable workflows across environments.

Governance and Control

Leverage Harness approval gates, role-based access controls, and policy enforcement to ensure safe production changes.

Deployment Visibility and Auditability

Track every Snowflake change deployment with full pipeline visibility and audit logs.

Why This Matters

As organizations increasingly rely on Snowflake to power data-driven applications, database changes need the same rigor and automation as application deployments.

By bringing Snowflake into Harness DB DevOps, teams can:

• Reduce manual deployment risk
  
• Improve collaboration between developers and data teams
  
• Standardize data warehouse release processes
  
• Accelerate delivery of data platform changes
  
  

Getting Started

Snowflake support for Harness DB DevOps is now available.

To get started:

1. Configure a Snowflake database connection in Harness
   
2. Add Snowflake change scripts to your repository
   
3. Create a Harness pipeline to deploy and promote changes
   
4. Automate Snowflake releases with confidence

Dev Hub Docs

Learn More

To learn more about using Snowflake with Harness DB DevOps, check out our documentation or schedule a demo.

Related Snowflake Topics

Warehouse Native Experimentation 

How a Software Catalog Powers DevOps at Scale

Managing hundreds of microservices without a centralized system of record leads to scattered ownership, duplicate pipelines, and compliance gaps that slow delivery. Understanding software catalogs and their benefits is essential for platform teams looking to scale delivery without compromising governance or developer velocity.

Beyond Inventory: The Catalog as Platform Backbone

A software catalog does more than just list services. It acts as a central hub, connecting each service to its owners, environments, deployment pipelines, compliance rules, and SLOs.

With this central hub, developers can help themselves. They can find dependencies, see the impact of changes, and use approved patterns without hunting through scattered docs or relying on team knowledge.

Operational Benefits: From Bespoke to Standardized

The catalog integrates with Harness’s reusable templates, so building pipelines takes minutes rather than days. Platform teams need only manage a few standard templates that update automatically, rather than handle hundreds of separate setups.

You can build pipelines visually or with code, and the central view eliminates GitOps tool sprawl by showing everything in one place. Automated workflows move changes through environments based on set policies and checks, so you don’t need manual steps.

Governance by Design: Compliance Without Friction

Modern software catalogs build governance right into delivery workflows with OPA policies, audit trails that can’t be changed, and deployment freeze windows. These controls work with GitOps workflows, so developers keep their freedom while the company stays compliant.

Teams can use the catalog independently, while policy-as-code automatically handles security, approvals, and change management.

Managing Microservices Sprawl With a Software Catalog

When you manage hundreds of microservices across many CD setups, it’s hard to see what’s going on. Manual promotion, scattered ownership information, and compliance tracking all slow things down, but a software catalog can fix these problems.

• Centralize service ownership with authoritative metadata linking each service to owners, repositories, dependencies, and on-call contacts
• Publish golden path templates through reusable deployment strategies that embed security and compliance while allowing controlled developer customization
• Generate pipelines instantly using AI-powered automation that creates production-ready deployments from plain English requests
• Automate dependency tracking to visualize service relationships and predict impact scope (blast radius) during rollouts or incidents
• Enforce regulatory compliance through policy-as-code that applies consistent approval workflows and audit trails across your entire service ecosystem

This method makes managing microservices easier and more scalable by replacing manual work with automated discovery and self-service via rules. Teams get a clear view of compliance, and developers can still deliver features quickly and safely.

Best Practices for Implementing a Software Catalog in Enterprise CI/CD

Start by mapping out your catalog’s main parts before picking tools. Define key elements like services, environments, pipelines, policies, and scorecards, and make sure their relationships are clear. Use labels and categories that match your company’s structure to make incident handling and releases easier.

By focusing on data first, you create a single source of truth that pipelines can access via REST APIs and automated links. This makes it easier for developers to manage hundreds of microservices.

Once your data model is set, build a template strategy that can grow with it. Create golden paths for common deployment types, such as canary and blue-green releases. Use insert-block templates so developers can customize while keeping key steps and safety checks. Harness’s flexible templates make it easy for platform teams to share reusable pipeline parts that developers can use for new services.

After setting up templates, add governance by using OPA-based policies for secrets, approvals, and deployment windows right in your pipelines. Make sure template updates are automatically pushed out so every service receives security fixes and policy changes. Harness’s policy-as-code provides immutable audit trails and central policy management, so teams can move fast while still meeting compliance requirements.

Software Catalog FAQs for DevOps and Platform Teams

Platform engineers managing hundreds of services often have questions about catalog tooling, compliance integration, and GitOps coordination. The following answers explain how catalogs differ from traditional IT inventory systems and integrate with modern delivery pipelines to reduce operational overhead.

What's the difference between a software catalog, a CMDB, and tools like Backstage?

A Configuration Management Database (CMDB) tracks infrastructure assets and configuration states for IT operations. A software catalog focuses on service metadata, ownership, and delivery pipelines for development teams. Backstage is an open-source developer portal that can implement catalog functionality, while platforms like Harness provide centralized management layers as enterprise control planes with built-in governance and AI-powered automation.

How do software catalogs support compliance and governance in continuous delivery workflows?

Catalogs centralize policy enforcement using OPA-based rules, audit trails, and template propagation across pipelines. They provide compliance artifacts such as SBOMs, security attestations, and approval workflows required by frameworks like NIST SSDF. This approach embeds compliance into delivery, enabling governance without added friction.

How does a catalog integrate with Argo or Harness CD and GitOps to solve visibility and orchestration gaps?

Catalogs provide the metadata layer that connects GitOps deployments to service ownership, dependencies, and policies. Harness acts as a centralized management layer, aggregating multiple Argo or Harness CD instances into unified dashboards while adding release orchestration and AI-powered verification. This solves tool sprawl by centralizing visibility and enabling coordinated promotions across environments.

Can software catalogs help with incident response and troubleshooting?

Catalogs accelerate incident response by linking services to on-call teams, runbooks, and dependency maps. When issues occur, responders immediately see service owners, recent deployments, and related components. Research shows that GitOps automation reduces configuration drift detection and remediation times, and that catalogs enhance this by providing the service context needed for rapid root-cause analysis.

How do catalogs scale with AI-accelerated development?

As AI coding assistants increase commit velocity, catalogs help deployment processes keep pace through automated pipeline generation and template reuse. Context-aware AI can use catalog metadata to generate production-ready pipelines in minutes. This prevents deployment bottlenecks, supporting the productivity gains of AI-assisted development while maintaining governance and safety standards.

From Inventory to Impact: Operationalizing Your Software Catalog

With GitOps workflows and automated governance, software catalogs become the backbone of your platform. Golden paths, central dashboards, and policy-as-code turn catalog entries into self-service deployment pipelines capable of handling hundreds of microservices.

Start with one golden path template and a single view of all GitOps tool setups. As teams use catalog-driven delivery, you can add release orchestration. This way, building pipelines takes minutes instead of days, and you maintain enterprise governance with automated checks and rollbacks that keep pace with the speed of AI-generated code.

Harness gives you an AI-powered control plane and a GitOps dashboard for enterprises. This turns your software catalog from a simple list into a dynamic tool for automated, governed delivery.