Skip to main content

Change Types

A Liquibase-compatible schema is composed of one or more Change Types. These are a structured instruction that defines particular database updates. Each changeset you write in YAML, XML, JSON, or SQL contains one or more change types. When Applying the change, Database DevOps translates these into the correct SQL statements for the target database platform.

Why Change Types Matter

  • Cross-Database Compatibility: You write a single change definition; Liquibase generates SQL for MySQL, PostgreSQL, Oracle, SQL Server, and more.
  • Clarity & Safety: Change types are declarative and easier to understand than raw SQL. They also help avoid mistakes with rollbacks.
  • Governance & Review: Each changeset with a defined change type can be tracked, versioned, and peer-reviewed like application code.
  • Automation-Friendly: Change types integrate smoothly into CI/CD pipelines, making database deployments repeatable and reliable.

Categories of Change Types

Harness Database DevOps supports a wide range of change types for managing schema and data evolution. Below are the most commonly used types, grouped by Entity, Constraint, and Data, along with their rollback behavior and examples.

1. Create Table Creates a new table with defined columns. By default, when rolled back the table is dropped.

- changeType: createTable
tableName: users
columns:
- name: id
type: int
constraints:
primaryKey: true
- name: name
type: varchar(255)
  1. Drop Table Removes an existing table.
- changeType: dropTable
tableName: users
  1. Add Column Adds new columns to a table. By default when rolled back, drops the added columns.
- changeType: addColumn
tableName: users
columns:
- name: email
type: varchar(255)
  1. Drop Column Removes a column from a table.
- changeType: dropColumn
tableName: users
columnName: email
  1. Rename Column Renames a column in a table. When rolled back, renames it back.
- changeType: renameColumn
tableName: users
oldColumnName: email
newColumnName: user_email
note

Renaming a column directly typically necessitates downtime because it means the database schema is not backwards compatible. For this reason, Harness recommends adding a new column using the new name, and setting up a trigger to sync the two versions. Once the old application version no longer exists in any environment, an additional changeset can be released that removes the trigger and deletes the old column.

  1. Rename Table Renames a table. When rolled back, renames it back.
- changeType: renameTable
oldTableName: users
newTableName: app_users
note

Renaming a table directly typically necessitates downtime because it means the database schema is not backwards compatible. For this reason, Harness recommends adding a new table using the new name, and setting up a trigger to sync the two versions. Once the old application version no longer exists in any environment, an additional changeset can be released that removes the trigger and deletes the old table.

Change Types vs Raw SQL

The table below compares the advantages of using change types versus writing raw SQL for database changes:

AspectChange TypesRaw SQL
PortabilityWorks across multiple databases (Liquibase translates automatically)Vendor-specific, different SQL databases have minor SQL syntax differences that may cause failure on different platforms.
ReadabilityDeclarative and self-explanatoryRequires SQL expertise to interpret
RollbackBuilt-in rollback support for most change typesMust be manually written and tested
GovernanceEasier to version, review, and auditHarder to maintain compliance and history
FlexibilityCovers most schema, data, and constraint changesNeeded for complex, vendor-specific features

Always prefer Change Types for common operations; fall back to raw SQL only when absolutely necessary.

Conclusion

Change types are the building blocks of database changes in Harness Database DevOps. They provide a clear, portable, and automation-friendly way to manage schema and data evolution across diverse database platforms. By leveraging change types, teams can ensure safer deployments, easier rollbacks, and better collaboration in their database development workflows. For complex scenarios not covered by change types, raw SQL can be used, but it should be minimized to maintain the benefits of using change types.