AI coding assistants have changed how fast application code gets written. Copilot, Cursor, Claude Code, and agentic tools built on top of them can generate a working feature in minutes. But none of them know your database's history. They don't know that a migration already renamed that column last sprint, that a policy forbids unqualified DELETE statements, or that the target environment has drifted from what your migrations say it should look like.

Until now, that gap left AI-generated changes riskier than they needed to be. Without the right governance and guardrails around them, teams were left to catch problems by hand, across a growing volume of changes and pull requests. From this release, the Flyway MCP Server closes that gap: it brings the same governance and control to every database change, whether a human or an AI proposed it, and keeps your review and approval steps firmly in place. It's available now in public preview for Flyway Enterprise.

AI agents are fast, but blind to your database

An AI assistant working in your codebase can read your application code, your tests, and your directory structure. What it can't see, on its own, is the state of your database: which migrations have been applied, or what your organization's policies say is and isn't allowed in a schema change.

That blindness is manageable when a person is reviewing every AI suggestion line by line. It becomes a real risk once teams start using agentic workflows, where an assistant is expected to plan, execute, and iterate with less human involvement at each step. An agent that doesn't know a migration already exists will happily suggest a conflicting one. An agent that doesn't know your naming policy will write a table that fails review anyway, just later and more expensively.

The Flyway MCP Server: your database, as context an agent can use

The Flyway MCP Server exposes Flyway's own commands as tools that an AI agent can call directly, through the Model Context Protocol. Point Claude Code, GitHub Copilot, Cursor, or another MCP-compatible tool at it, and the agent gains direct, structured access to the same operations a developer would run from the CLI: checking migration status, version controlling changes, generating new versioned migrations, and running policy checks.

Practically, this means an agent working on a feature that needs a schema change can:

• See what's already been applied, so it doesn't propose a migration that conflicts with one already in place
• Generate the next migration script in sequence, following your project's existing versioning
• Run a policy check against the change before suggesting it, catching violations of your team's standards
• Follow the correct development workflow, ensuring visibility and auditability is not compromised for AI-generated changes

The agent isn't given free rein over your database. It's calling the same governed Flyway Enterprise commands your pipeline already trusts, so the control and guardrails that Flyway applies to a human-authored migration apply here too.

Why this matters beyond convenience

The appeal isn't just that an AI assistant can now run flyway commands without a context switch back to the terminal. It's that database change stays inside a single, auditable workflow regardless of who, or what, proposed it.

It also solves a subtler problem. AI is great at proposing database changes but fundamentally incapable of producing the same script twice, and a migration history is a permanent record that demands exactly that. Flyway sits in between as the control layer: non-deterministic in, deterministic out. The agent proposes the change; Flyway turns it into a versioned, deterministic migration that what gets tested is exactly what gets deployed.

With Flyway Enterprise acting as a control layer, an AI-generated migration that violates a naming convention or attempts a risky operation fails the same policy check a human's would. It gets version-controlled the same way. It shows up in the same reports. There's no separate, less-visible path where AI-suggested schema changes bypass the review your team relies on for everything else. As agentic workflows take on more of the day-to-day work of writing code, that consistency is what keeps the database from becoming the one part of the stack nobody can fully account for.

What this means for your team

For developers, it means less time spent manually feeding an assistant context it should already have, and less time catching AI-suggested changes that would have failed review anyway.

For platform and engineering leads, it means AI-assisted development doesn't require a separate governance story for the database. The same policies, the same audit trail, the same drift detection that already cover human-authored changes now cover agent-authored ones too. This means teams have the guardrails in place for database changes. Governance doesn’t slow the pipeline down – instead, it makes it safer for teams to go faster.

Try the preview

The Flyway MCP Server is available now in public preview to Flyway Enterprise users. It's a straightforward addition to an existing Flyway project: point your MCP-compatible AI tool at the server, and it can start using Flyway as part of its normal workflow.

Full setup instructions, the list of available tools, and configuration guidance are in the Flyway MCP Server documentation. We're looking for feedback from teams already using AI coding assistants alongside Flyway, so if you try it out, let us know what works and what you'd like to see next.