Technical Glossary

Anomaly Detection is the automated identification of database changes or activity that deviate from expected patterns, such as an unusual spike in schema modifications or a change originating from an unexpected source. It's a complementary layer to Drift Detection, focused on unusual behavior rather than only structural mismatches.

Audit evidence is the documentation an organization can produce to prove a change happened the way it was supposed to: what changed, who approved it, what controls ran, and what the outcome was. An audit trail is one piece of it; evidence also includes approvals, policy results, and context an auditor can verify.

An audit trail is a chronological record of the changes made to a system, showing what changed, when, and who made the change. For database change management, it's the log that lets a team or an auditor reconstruct exactly what happened to a database over time.

Automated deployment is the practice of applying database, or application, changes through a script or pipeline rather than by a person running commands manually. A defined, repeatable process runs the same way every time, which is what separates automated deployment from a person executing similar steps by hand.

A Backward-Compatible Schema Change is a database modification that doesn't break application code still running against the previous schema version. It's the underlying requirement that makes Zero-Downtime Deployment and the Expand-Contract Pattern possible, rather than a technique in itself.

Change Failure Rate is one of the four DORA Metrics, measuring the percentage of deployments that result in a failure requiring remediation, such as a rollback, a hotfix, or an incident. For database changes, it reflects how often applied ChangeSets cause problems after deployment.

Change governance is the overall practice of controlling how database changes move from proposal to production: who can approve them, what standards they must meet, and what record is kept of what happened. It's the umbrella discipline that governance policies, policy checks, and audit evidence all exist to support.

Change Lead Time is one of the four DORA Metrics, measuring the elapsed time from a change being ready to deploy to it actually reaching production. For database changes, that typically means the time from a ChangeSet being merged to it being applied in production.

A change set is a single, atomic unit of database change, usually one specific modification such as creating a table or adding a column, identified by a unique ID and author. In Liquibase, change sets are written inside a ChangeLog and are each applied exactly once, in the order they appear.

A Change Type is the specific, declarative operation inside a ChangeSet, such as creating a table, adding a column, or dropping a constraint. Rather than writing raw SQL, a ChangeSet specifies which Change Type it's using, and the underlying tool translates it into the correct syntax for the target database.

A CI/CD pipeline is the automated system that builds, tests, and deploys code changes. Continuous integration merges and tests changes frequently; continuous delivery or deployment automates getting tested changes into production. Database changes can be included in the same pipeline as application code, rather than deployed through a separate, disconnected process.

Compliance automation is the use of automated checks and evidence collection to meet regulatory requirements for database change, replacing manual audits and spreadsheet tracking with policy checks that run on every change and a record that's captured automatically. It's how governance and audit requirements get met without slowing delivery down.

Contexts and Labels are tags applied to ChangeSets that control which ones execute in a given deployment, letting a single ChangeLog serve multiple environments. A ChangeSet tagged for test data, for example, can run in QA while being automatically skipped in production, without maintaining separate ChangeLogs.

A Custom Policy Check is an organization-defined rule that goes beyond Liquibase's built-in checks, written to enforce a specific standard unique to that team or industry. Rather than relying only on default checks, teams can codify their own requirements directly into the deployment process.

Database-as-Code is the practice of managing database schema and configuration the same way application code is managed: version-controlled, reviewed through pull requests, and deployed through an automated pipeline. It applies the discipline of software engineering to database change rather than treating it as a separate, manual activity.

Database drift is the gap between a database's actual schema and the schema defined in its version-controlled source of truth. It happens when changes are made directly to a database, such as a manual fix or an emergency patch, without being captured in the change management process that governs every other environment.

A database migration is the broader process of moving a database from one state to another, which can mean applying schema and data changes over time, or moving an entire database to a new platform or version. Schema migration is typically one component of a larger database migration effort.

A Database Snapshot is a point-in-time capture of a database's schema, used as a reference for comparison, such as checking for drift or documenting a database's state before a major change. It records structure rather than data, focused on what the database looks like, not what it contains.

Data Lineage is the ability to trace where a piece of data originated and how it has changed as it moved through systems and transformations over time. For database change management, it means tracking not just schema history but how the data itself evolved alongside it.

Deployment Frequency is one of the four DORA Metrics, measuring how often changes reach production over a given period. For database change specifically, it tracks how often schema and data updates actually deploy, not just how often they're written or reviewed.

A deployment pipeline is the sequence of automated stages a change moves through on its way from being written to running in production, typically including build, test, and deployment steps across multiple environments. For database changes, it's what applies a ChangeLog consistently at each stage.

DORA Metrics are four measurements, deployment frequency, change lead time, change failure rate, and time to recovery, used to assess how effectively a software team delivers and maintains changes. Originally developed for application delivery, the same four metrics increasingly get applied to database change as organizations bring database delivery under the same measurement standards.

Drift detection is the automated practice of comparing a database's actual current state against the state its ChangeLog says it should be in, and flagging any difference. It's how database drift gets caught early, rather than discovered later during a failed deployment or a compliance review.

The Expand-Contract Pattern is a migration technique for making schema changes without breaking existing code, by first expanding the schema to support both old and new structures, then contracting it to remove the old structure once every consumer has migrated. It's the standard approach to Zero-Downtime Deployment.

A Flow File is a declarative file that orchestrates a multi-stage database change process, combining validation, deployment, and verification steps into a single, repeatable definition. Instead of running separate commands by hand, a team defines the whole sequence once and runs it the same way in any environment.

A Flow Stage is a single step within a Flow File, such as validation, deployment, or verification, containing one or more commands that run in sequence. Breaking a deployment into named stages makes it possible to see exactly where a process succeeded or failed, rather than treating it as one opaque operation.

A governance policy is a defined rule or standard that database changes are expected to follow, such as requiring approval for schema changes to production or prohibiting destructive changes outside a maintenance window. It describes what's allowed, separate from the mechanism, like a policy check, that actually enforces it.

Governance, Risk, and Compliance, or GRC, is the combined organizational discipline that database change governance, policy enforcement, and audit evidence collection ultimately serve. It covers how an organization sets standards, manages risk against them, and demonstrates that regulatory or internal requirements are actually being met.

An idempotent deployment produces the same result no matter how many times it runs: applying it once and applying it five times leave the database in the exact same state, because anything already applied is recognized and skipped rather than reapplied. This is what makes it safe to re-run a deployment after a failure.

Identity-Aware Access Control restricts database change permissions based on a verified user or service identity, rather than shared credentials or broad database-level access. It ties every change back to a specific, authenticated identity, which is what makes accurate audit trails and Separation of Duties actually enforceable.

Mean Time to Recovery, or MTTR, is one of the four DORA Metrics, measuring the average time it takes to restore service after a failure caused by a deployment. For database changes, that typically means the time from a problem being detected to a rollback or fix resolving it.

A migration script is the actual file containing the instructions for a specific database change, whether that's raw SQL or a declarative format like Liquibase's ChangeLog syntax. It's the concrete artifact; the migration itself is the change it describes and applies.

Multi-environment deployment is the practice of applying the same defined set of database changes consistently across several environments, such as development, staging, and production, rather than maintaining separate scripts or processes for each one. The same ChangeLog runs everywhere; what varies is which parts apply where.

An Operation Report is a generated summary documenting the outcome of a specific database operation, such as a drift check, an update, a rollback, or a policy check run. It captures what happened, what changed, and whether the operation succeeded, in a format meant to be reviewed or archived.

An Out-of-Process Change is a database modification made outside the defined deployment pipeline, such as a manual fix run directly against a database rather than through a reviewed ChangeSet. It's the specific cause behind most database drift, rather than a separate concept from it.

Peer review is the practice of having someone other than the author examine a proposed change before it's approved, checking for correctness, risk, and adherence to standards. For database changes, it applies the same review discipline already standard for application code.

Policy checks are automated rules that validate a database change against a defined standard before it's allowed to deploy, such as blocking a table drop without an approval or flagging a change that skips a required naming convention. Instead of a person manually reviewing every change against a checklist, the check runs automatically and blocks or flags anything that doesn't comply.

Preconditions are conditional checks attached to a ChangeLog or an individual ChangeSet that must pass before that change is allowed to run. They let a team specify assumptions about the database's current state, so a change only executes when it's actually safe to apply.

Release management is the organizational process of planning, scheduling, and coordinating what goes into a software release, including which database changes ship with it, when it deploys, and who signs off. It sits above individual deployments, tying together everything, application and database, that needs to move together.

A rollback reverses a database change that has already been applied, returning the schema or data to the state it was in before that change ran. In Liquibase, each change can carry its own rollback instructions, either written explicitly or generated automatically, so a specific update can be undone without rebuilding the database from scratch.

Root Cause Analysis is the practice of tracing a database incident or unexpected behavior back to the specific change, or absence of a change, that caused it. For database issues, that usually means identifying which ChangeSet, or which Out-of-Process Change, is actually responsible.

A schema migration is a change to a database's structure, such as adding a table, altering a column's type, or creating an index, as opposed to a change to the data stored within it. Schema migrations are typically the specific kind of change tracked and versioned by tools like Liquibase.

Separation of Duties is a governance control requiring that the person who authors a database change is not the same person who approves it. It's meant to prevent a single individual from being able to introduce and approve a risky or unauthorized change without independent review.

Source control is a system that tracks changes to a set of files over time, recording who changed what and when, so earlier versions can be recovered and multiple people can work on the same files without overwriting each other's work. In database change management, it means storing ChangeLogs and ChangeSets in the same system used to track application code.

Structured deployment is the practice of applying database changes through a defined, repeatable process: in a fixed order, validated before execution, and recorded automatically, rather than running scripts manually. It replaces ad hoc execution with a process that behaves the same way every time, regardless of who runs it or which environment it targets.

Structured Logging is the practice of recording database operations as machine-readable data, typically JSON, capturing details like the change made, its author, a timestamp, execution outcome, and performance metrics for every operation. Unlike plain text logs, structured logs can be searched, filtered, and fed directly into monitoring tools.

Zero-Downtime Deployment is the practice of applying database changes without interrupting the availability of the application depending on that database. It typically requires structuring schema changes so that both the old and new structure can coexist briefly during the transition.