• Concept
  • Version ยท 6.0
  • Govern

What is in the Liquibase Default Catalog?

Last updated: September 29, 2026

Every workspace starts with the Liquibase Default Catalog, a read-only catalog holding the 60 policy checks built into Liquibase Secure, grouped into 7 packages named after the check categories. This page lists what is in each package and which checks arrive enabled, so you can decide what to copy into your own catalog without opening every package in turn.

The catalog is read-only, so you copy the checks you want into a package of your own, then enable or disable them and set their parameters there. Organize checks and packages covers building the catalog that holds them.

Packages at a glance

  • Authorization and Access: Guards GRANT/REVOKE usage and privilege escalation paths. 5 checks, 4 enabled.

  • Data Protection: Prevents destructive or exposing operations on protected data. 17 checks, 12 enabled.

  • Database Compatibility: Flags vendor-specific syntax that breaks portability. 7 checks, 1 enabled.

  • Metadata Content: Requires labels, contexts, and comments on changesets. 11 checks, 4 enabled.

  • Scripting Standards: Enforces SQL scripting style and structural conventions. 12 checks, 4 enabled.

  • Sensitive Data: Detects PII and secrets in changesets and SQL text. 6 checks, 0 enabled.

  • Advanced Policies: Custom policy hooks for organization-specific rules. 2 checks, 0 enabled.

Note: Enabled here means enabled in the default catalog, which is what a copy inherits. Once a check is copied into your catalog or package, you can enable or disable it there. You can also enable or disable a check for a single assignment without changing its state in other assignments that use the same check.

Package details

Authorization and Access

Guards GRANT/REVOKE usage and privilege escalation paths.

Check

What it does

In the default catalog

SqlGrantAdminWarn

Identifies highly sensitive GRANT statements that include WITH ADMIN OPTION, which allows recipients to grant and revoke the same administrative privileges to others, helping prevent security risks from uncontrolled admin role distribution.

Enabled

SqlGrantOptionWarn

Detects WITH GRANT OPTION statements, which allows the recipient to pass permissions on to other users, helping you prevent privilege escalation security risks which could spread beyond intended recipients.

Enabled

SqlGrantWarn

Alerts when SQL code contains GRANT statements that assign database privileges to users or roles, helping review potential security vulnerabilities by ensuring permissions are appropriately scoped and do not provide unintended access.

Enabled

SqlRevokeWarn

Flags REVOKE statements in SQL that remove database privileges from users or roles, allowing you to verify that removing these permissions will not accidentally break application functionality or prevent legitimate access to critical data.

Enabled

SqlGrantSpecificPrivsWarn

Alerts when changesets contain GRANT statements that assign particular database privileges designated as requiring review, helping maintain strict control over sensitive permissions like DELETE, DROP, ALTER, or administrative rights which pose security risks.

Disabled

Data Protection

Prevents destructive or exposing operations on protected data.

Check

What it does

In the default catalog

ChangeDropColumnWarn

Alerts when DROP COLUMN is detected, giving you an opportunity to verify the column removal will not cause data loss or break dependencies, and that both necessary data and application code are migrated or updated.

Enabled

ChangeDropTableWarn

Warns when DROP TABLE is detected, providing a safety checkpoint to confirm the deletion is intentional and prevent accidental data loss from removing important or referenced tables.

Enabled

ChangeTruncateTableWarn

Alerts you when a changeset attempts to truncate a table and remove all its data, providing an opportunity to verify this destructive operation is intentional and that any necessary data has been backed up or migrated, preventing accidental deletion of entire table contents that may be difficult or impossible to recover.

Enabled

CheckTablesForIndex

Identifies database tables which lack indexes, highlighting potentially performance problems before they cause production slowdowns as data grows, ensuring efficient querying, joining, and constraint enforcement.

Enabled

DetectChangeType

Flags changesets with user-specified prohibited change types, allowing you to enforce policies against certain types of database modifications like raw SQL execution, dropping objects, or other change types forbidden by organizational policy.

Enabled

MaxAffectedRowsAllowedDelete

Validates DELETE statements against a configurable threshold limit to prevent removing too many rows of data, providing a safety net against runaway deletions that could remove more data than intended and helping ensure bulk delete operations are properly scoped.

Enabled

MaxAffectedRowsAllowedInsert

Alerts when an INSERT operation would add more rows than your configured limit, helping catch potential issues with bulk data loads or runaway insert statements that might impact database performance or storage.

Enabled

MaxAffectedRowsAllowedUpdate

Checks UPDATE statements against a configurable limit to protect against unintended mass updates, preventing mistakes like missing WHERE clauses or overly broad conditions that could accidentally change more rows of data than intended.

Enabled

ModifyDataTypeWarn

Flags any changes that modify the data type of an existing column, helping avoid data truncation or loss when converting between incompatible types, such as changing from a larger to smaller size or from text to numeric formats.

Enabled

PrimaryKeyOnCreateTable

Flags table creation statements that do not define a PRIMARY KEY, promoting database design best practices by ensuring every table has a unique identifier for rows, which is essential for data integrity, relationships, and efficient querying.

Enabled

SqlSelectStarWarn

Identifies SQL queries that use SELECT * to retrieve all columns from a table, encouraging best practices for query performance and maintainability by requiring developers to explicitly specify which columns they actually need rather than retrieving unnecessary data.

Enabled

TableColumnLimit

Enforces a maximum TABLE COLUMN LIMIT to maintain database design quality and prevent overly wide tables that can indicate poor normalization, hurt query performance, and make the schema difficult to understand and maintain over time.

Enabled

ConstraintMustExist

Verifies that designated tables include required constraints like foreign keys, unique constraints, or check constraints that are essential for data integrity, helping ensure critical business rules and referential relationships are properly enforced at the database level rather than relying solely on application code.

Disabled

DynamoChangetypeAttributes

Validates that DynamoDB-specific change operations include properly configured attributes that match your organizational patterns or standards, ensuring DynamoDB changesets are correctly parameterized with appropriate table names, capacity settings, index configurations, or other DynamoDB-specific properties.

Disabled

DynamoDeleteDynamoTableCheck

Warns when changesets attempt to delete DynamoDB tables, providing a safety check specific to DynamoDB operations to prevent accidental removal of NoSQL tables and the permanent loss of data stored in Amazon's DynamoDB service.

Disabled

DynamoDeleteGlobalSecondaryIndexCheck

Alerts when changesets try to remove Global Secondary Indexes from DynamoDB tables, helping verify that deleting these indexes will not negatively impact query performance or break application functionality that depends on these alternative access patterns for retrieving DynamoDB data.

Disabled

MongoChangetypeAttributes

Ensures MongoDB-specific database changes have attributes configured according to required patterns or values, helping maintain standards for MongoDB operations like collection names, document structures, or index definitions and preventing misconfigurations in your MongoDB schema changes.

Disabled

Database Compatibility

Flags vendor-specific syntax that breaks portability.

Check

What it does

In the default catalog

WarnOnUseDatabase

Detects USE DATABASE statements in SQL scripts to help maintain portability and prevent unintended database switching, ensuring changesets do not accidentally execute against the wrong database context or create deployment issues across different environments.

Enabled

OracleReservedKeywords

Prevents the naming of database objects using Oracle reserved keywords like SELECT, TABLE, INDEX, or WHERE, avoiding syntax errors and the need for complex quoting or escaping that makes queries harder to write and maintain while ensuring compatibility across different Oracle database versions and tools.

Disabled

PostgresNonReservedKeywords

Prevents using PostgreSQL's non-reserved keywords as object names even though they're technically allowed, promoting clearer and less ambiguous schema design by avoiding keywords that might have contextual meaning or could become reserved in future PostgreSQL versions.

Disabled

PostgresReservedKeywords

Enforces that PostgreSQL reserved keywords (like SELECT, USER, TABLE, or other terms with special meaning in PostgreSQL) are not used as database object names, preventing syntax conflicts and complex quoting efforts.

Disabled

SQLServerFutureReservedKeywords

Prevents using keywords Microsoft has earmarked for future SQL Server versions, protecting your schema from becoming incompatible when upgrading to newer database versions and avoiding the need for potentially disruptive object renaming during future migrations or newer SQL Server releases.

Disabled

SQLServerODBCReservedKeywords

Blocks database object names that conflict with ODBC reserved keywords to ensure compatibility with applications that access SQL Server through ODBC connections, preventing potential issues with database connectivity and query execution.

Disabled

SQLServerReservedKeywords

Blocks the use of SQL Server reserved keywords in database object names, preventing conflicts with T-SQL syntax and ensuring tables, columns, or other objects do not use words like SELECT, TABLE, INDEX, or other terms that have special meaning in SQL Server.

Disabled

Metadata Content

Requires labels, contexts, and comments on changesets.

Check

What it does

In the default catalog

ChangesetCommentCheck

Requires descriptive COMMENT on every changeset to document the purpose behind database changes, improving documentation and long-term maintainability by ensuring future developers understand why modifications were made and what problems they solve.

Enabled

ChangesetContextCheck

Mandates changesets specify the CONTEXT, such as dev, test, prod, etc, enabling environment-specific deployments and ensuring certain database changes only run in appropriate environments while providing better documentation over which modifications are applied in different stages of the pipeline.

Enabled

ChangesetLabelCheck

Requires all changesets specify the LABEL for better organization and deployment targeting, enabling selective deployment groups, and maintaining clearer documentation of feature work or release cycles.

Enabled

FormattedSqlHeaderRequired

Ensures Formatted SQL changelog files include the required Liquibase header comment, preventing execution errors and ensuring the changelog is processed by Liquibase, with all its tracking and versioning capabilities, rather than treated as raw SQL.

Enabled

ChangesetAttributesAndValue

Validates that specific changeset attributes match your required values or patterns, enabling enforcement of standards like author name formats, runOnChange settings, runWith values, or other attribute requirements that ensure changesets follow your team's configuration conventions.

Disabled

ChangesetAttributesSetTrueOrFalse

Validates specific CHANGESET ATTRIBUTES like runInTransaction or failOnError are explicitly set to either true or false rather than left undefined, preventing ambiguity about how changesets should behave and ensuring intentional configuration of important execution parameters.

Disabled

RequireChangesetIDisUUID

Enforces that all changeset IDs use the standard UUID or GUID format with the 8-4-4-4-12 hyphenated pattern, promoting globally unique changeset identifiers that prevent collisions and improve traceability across distributed teams and multiple changelog files.

Disabled

TableCommentCheck

Flags database tables that do not include COMMENTS, used to explain its purpose and contents, promoting self-documenting schemas that help developers efficiently understand the data model without needing to consult external documentation.

Disabled

TableCommentPatternCheck

Scans TABLE COMMENTS for Regex patterns or specific text, allowing you to ensure required content is present or prohibited content is not included, according to user and organization specific policies.

Disabled

UserDefinedContextCheck

Ensures changeset CONTEXT contains specific words or patterns, helping enforce that all changes are properly tagged for environment targeting, helping maintain consistent environment targeting across your deployment pipeline and preventing errors from misspelled or non-standard context names.

Disabled

UserDefinedLabelCheck

Validates changeset LABEL includes specific words or a defined pattern, enabling enforcement of requirements like ticket numbers, release versions, team names or other identifiers to track and organize database changes.

Disabled

Scripting Standards

Enforces SQL scripting style and structural conventions.

Check

What it does

In the default catalog

CheckRunInTransactionValue

Validates the runInTransaction attribute to enforce whether changesets must run inside or outside of transactions, ensuring operations that require transactional safety are properly wrapped while certain DDL statements in some databases that can't run in transactions are appropriately configured.

Enabled

OneChangePerChangeset

Enforces the best practice of ONE CHANGE per changeset to keep changesets focused and atomic, making it easier to troubleshoot issues, rollback specific changes independently, and understand the history of individual database modifications.

Enabled

RollbackRequired

Ensures every changeset includes rollback instructions to reverse the change if needed, promoting safer deployments by guaranteeing you can undo database modifications if issues arise, which is critical for maintaining database recoverability and reducing deployment risk.

Enabled

SqlPlusSlashTerminatorCheck

This check triggers when SQL content has SqlPlus slash terminator issues that could cause hangs or double execution.

Enabled

EndDelimiterExistsWhenPatternExists

Ensures changesets contain proper end delimiters when certain SQL patterns exist, ensuring SQL commands are properly separated, preventing syntax errors and ensuring your database scripts execute as intended across different database platforms.

Disabled

ObjectNameMustMatch

Enforces naming conventions for database objects like tables, columns, indexes, and constraints by requiring them to match your specified naming pattern or regex, helping maintain consistent and standardized object names across your database schema that align with organizational naming standards.

Disabled

ObjectNameMustNotMatch

Prevents database objects from being named with prohibited patterns or conventions, allowing you to block specific naming styles, reserved words, or naming patterns that conflict with your standards, ensuring objects do not use disallowed prefixes, suffixes, or formats that could cause confusion or conflicts with application code or other systems.

Disabled

PatternAFollowedByPatternB

Validates a specific Pattern A or keyword is always FOLLOWED by another expected Pattern B, helping enforce proper SQL syntax ordering, required clauses, or organizational coding conventions mandating certain statements must appear in a specific sequence in changesets.

Disabled

PatternANotFollowedByPatternB

Validates a specific Pattern A or keyword is NOT FOLLOWED by another expected Pattern B, helping enforce proper SQL syntax ordering, required clauses, or organizational coding conventions ensuring your SQL adheres to organizational standards or database best practices.

Disabled

PatternANotPrecededByPatternB

Validates a specific Pattern A or keyword is NOT PRECEDED by another expected Pattern B, helping enforce proper SQL syntax ordering, required clauses, or organizational coding conventions mandating certain statements must appear in a specific sequence in database scripts.

Disabled

PatternAPrecededByPatternB

Validates a specific Pattern A or keyword is always PRECEDED by another expected Pattern B, helping enforce proper SQL syntax ordering, required clauses, or organizational coding conventions mandating certain statements must appear in a specific sequence in database scripts.

Disabled

SqlUserDefinedPatternCheck

Allows user-defined custom Regex patterns or specific text strings to search for within SQL code, enabling enforcement of organization-specific coding standards, both detecting prohibited patterns or proving inclusion of required patterns, building an audit trail of development practices.

Disabled

Sensitive Data

Detects PII and secrets in changesets and SQL text.

Check

What it does

In the default catalog

PIIcomputerAndDate

Identifies highly-sensitive Computer-related and Date information, helping avoid PII (Personally Identifiable Information) data exposure, and supporting audit and authorization requirements in highly-regulated environments.

Disabled

PIIfinancial

Identifies highly-sensitive Financial or Bank information, helping avoid PII (Personally Identifiable Information) data exposure, and supporting audit and authorization requirements in highly-regulated environments.

Disabled

PIIhealth

Identifies highly-sensitive Health, Hospital and Doctor information, helping avoid PII (Personally Identifiable Information) data exposure, and supporting audit and authorization requirements in highly-regulated environments.

Disabled

PIIlocation

Identifies highly-sensitive US Geographic Location information, helping avoid PII (Personally Identifiable Information) data exposure, and supporting audit and authorization requirements in highly-regulated environments.

Disabled

PIIpersonal

Identifies highly-sensitive Person-centered information, helping avoid PII (Personally Identifiable Information) data exposure, and supporting audit and authorization requirements in highly-regulated environments.

Disabled

SensitiveInfoCheck

Identifies multiple types of highly-sensitive Personally Identifiable Information (PII) including Financial, Banking, Personal, Location, Health, and Computer types of data, helping avoid data exposure, and supporting audit and authorization requirements in highly-regulated environments. Create focused checks by copying and customizing specific IDENTIFIERS for your specific data protection policies.

Disabled

Advanced Policies

Custom policy hooks for organization-specific rules.

Check

What it does

In the default catalog

ChainedChecksTemplate

Enables checking complex or multi-part policy conditions by combining or chaining multiple Policy Checks with logical operators, allowing you to create sophisticated rules based on combinations of simpler factors, like changeset attributes, SQL content, label content, etc to match nuanced organizational requirements.

Disabled

CustomCheckTemplate

Allows you to create and run completely custom policy checks using your own Python scripts and logic, providing flexibility to enforce organization-specific rules, integrate with external validation systems, or implement complex checks that are not covered by standard policy check capabilities.

Disabled

Checks that ignore DML

The checks that look for a DDL or DCL keyword, such as GRANT or DROP TABLE, evaluate DDL and DCL statements only. They ignore any statement that begins with SELECT, INSERT, UPDATE, DELETE, MERGE, or WITH, so a keyword stored as data does not trigger them. For example, an INSERT that stores the address 101 Grant St. does not trigger SqlGrantWarn.

These checks are ChangeDropColumnWarn, ChangeDropTableWarn, ChangeTruncateTableWarn, SqlGrantAdminWarn, SqlGrantOptionWarn, SqlGrantWarn, SqlRevokeWarn, and WarnOnUseDatabase.

A changeset that mixes DML and DDL is still flagged on its DDL. Only the DML statements are ignored, so a changeset holding an INSERT followed by GRANT ALL ON sales TO admin_user triggers SqlGrantWarn on the GRANT.

SqlSelectStarWarn is the exception. It looks for SELECT *, which only appears in DML, so it evaluates every statement.

How this compares to the CLI package files

If your team runs policy checks from files, init project generates six of these packages as package files.

Going the other way, the file workflow has composite packages that bundle several themed packages together, which the catalog has no equivalent for. What are the default policy check packages? covers the file side, including the commands that target a package by name.

What to do next

You have seen what ships and which checks arrive enabled. Organize checks and packages to copy the packages you want into a catalog of your own, then define policy assignments to put them in force.