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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.