Every engineering team has a list of “things we don’t do”. No TRUNCATE TABLE in production. Every audit table must end in _audit. Foreign keys follow a naming convention. But until now, enforcing those standards has meant relying on pull request checklists, tribal knowledge, or a separate linting tool bolted onto the pipeline.

From this release, Redgate Flyway Enterprise can enforce your team’s own custom policies automatically, in the same automated code review that already catches missing semicolons and risky schema changes.

The governance gap most teams live with

Flyway Enterprise’s automated code reviews already ship with two layers of policy checks: the built-in policy engines for structural analysis, and a curated library of additional policies authored by Redgate covering security, data loss prevention, and code quality. For most teams, those cover the obvious risks.

What they can’t cover is your organization's specific conventions.

That knowledge tends to live in a wiki nobody updates, in a senior engineer’s head, or in review comments that get repeated on every pull request. When a reviewer misses something, or is on holiday, or is new to the team, a non-compliant migration makes it to production. The fix costs far more than the check would have.

Custom Policy Checks: your standards, in the pipeline

Flyway Enterprise now supports a third layer of automated policy checks, ones you write and own. A single configuration setting, check.sqlfluffCustomRulesPath, points Redgate Flyway at your policy package. From that point, every flyway check -code run enforces your policies alongside Redgate’s, locally, in CI, and in Flyway Desktop - with no additional tooling required.

Custom policy checks are written in Python against the standard SQLFluff plugin API - an interface that many database or platform teams will already know. A policy that blocks TRUNCATE TABLE in production migrations takes roughly a dozen lines. Policies can also be parameterized, so the same check can be reused across projects with different settings: one team enforces a stg_ prefix, another enforces dim_, and each configures it in their own Flyway settings without duplicating code.

Violations from custom policy checks surface in the same places as all other Flyway findings: the CLI summary, JSON and SARIF reports, and Flyway Desktop. They appear in their own engine row, SQLFluff (Custom), tagged with ruleSource: “custom”, so existing dashboards and triage workflows pick them up immediately.

The AI safety net

AI coding assistants - Copilot, Cursor, in-IDE chat, agentic tools - are now producing more code that creates a real bottleneck at the review stage. These tools are capable of writing SQL that parses correctly, but they have no knowledge of your organization's conventions. They do not know that your team forbids SELECT * in views, or that this database has never seen an unqualified DELETE. Without automated policy checks in the pipeline, that gap falls to the human reviewer to catch — every time.

Custom policy checks apply equally to human-written and AI-generated migrations. They are deterministic and fast, and they run on the migration as written. A migration from an AI assistant that violates a custom policy fails automated code review in exactly the same way, with the same message, as one written by hand. Your standards are enforced regardless of where the SQL came from.

Looked at another way, your team’s set of custom policy checks is a machine-readable specification of “what good looks like” for every AI tool working against your codebase. That is a governance asset with value well beyond any individual migration review.

What this means for technical and business buyers

For engineering managers and platform teams, custom policy checks mean that your organization's database standards are enforced consistently on every change, by every developer, without relying on the availability or attention of a senior reviewer. Onboarding new engineers or switching contractors becomes lower risk. Compliance audits become easier to evidence.

For organizations in regulated industries - financial services, healthcare, public sector - the ability to define, version, and automatically enforce database governance policies within the deployment pipeline directly addresses audit and control requirements that previously required manual process.

There is no new tooling to procure, no professional services engagement, and no separate pipeline to maintain. Custom policy checks are enabled with a single Redgate Flyway configuration setting and run inside the automated code review.

Get started

Custom policy checks are available now in Flyway Enterprise. The full reference - including parameterised policies, naming conventions, and worked examples - is in the Custom SQLFluff Rules documentation. To see how automated code reviews fit into a broader database change management workflow, visit the Flyway Automated Code Reviews page.