Research · Flyway · 2026
AI in Flyway: a customer discovery programme
How are customers actually using AI with their databases, and where should Flyway meet them? I led the research from plan to recommendation, and the evidence shaped what the team built first.
- customer organisations
- 5
- synthesised themes
- 8
- research plan versions
- 7
- Company
- Redgate
- Product
- Flyway
- My role
- Research leadSynthesisStrategic recommendation
- Methods
- Customer interviews · Field research at SQLBits 2026 · Secondary research · Synthesis into themes · Stakeholder presentation
OutcomeThe team prioritised a v1 MCP server covering the core developer workflow, which shipped in Flyway 13.0.0. Deployment-focused MCP capability is the next area of work.
Full story: showing every section.
Context
The question the team needed answered
AI tooling is reshaping how developers interact with every layer of the stack, and the database layer keeps getting identified as the last remaining bottleneck. Customers are moving faster on application code but struggling to keep schema changes in step. The question for the Flyway team wasn’t whether to invest in AI integration, but where and how. An MCP server? Skills? CLI improvements? Something else?
The risk of getting this wrong in either direction was real. Build the wrong thing and we waste a significant engineering investment. Build nothing and customers build their own workarounds; some already had. This research programme was designed to give the team the evidence it needed to make a confident, grounded decision.
Research scope
What I set out to learn
The programme had five goals:
Understand how customers are currently using AI alongside Flyway.
Identify the highest-value integration points from a customer perspective.
Test whether MCP was as urgently needed as internal signals suggested.
Understand what trust conditions customers require before they’d adopt AI-native database tooling.
Identify constraints, particularly around regulated industries, that would affect what we could build.
I wrote the research plan, recruited participants across multiple channels, designed the discussion guides, ran the interviews, and synthesised the findings into a one-pager and a Mural board for stakeholder review. The plan went through seven versions as new signals came in, from SQLBits, from PM standups, from secondary research into Liquibase and the broader MCP ecosystem. That kept the hypothesis set current as the landscape moved.
Sources
A multi-strand evidence base
Customer interviews were the primary source, but the programme deliberately drew on a wide range of inputs: SQLBits 2026 field research; Summit NY and PASS Chicago conference signals from the PM team; Redgate Community Ambassador calls (four participants); secondary research into competitor positioning (Liquibase Change Intelligence, the MCP ecosystem); and internal Solution Engineer knowledge about how customers were already working around the absence of native AI integration.
Participants
Who we spoke to
Five customer organisations were interviewed, selected to span a range of AI maturity, from teams already building agentic workflows to those just beginning to explore what AI tooling might mean for their database practice. All of them agreed to be named.
- Stifel
- Financial services firm. Had built their own internal Redgate support agent in Copilot Studio because navigating Redgate’s documentation was too difficult. A strong signal for the “AI as interface to Flyway” pattern, and for documentation quality as a prerequisite for AI compatibility.
- StubHub
- Ticketing platform. The most AI-forward customer in the programme. Described a 10x increase in application code output with database changes lagging far behind, framing it as a business blocker, not a developer-experience issue. Was actively building a Flyway skill in Claude Code.
- Intelliflo
- Financial services software. Using Claude to write migration scripts but hitting SQL injection risks without guardrails. Highlighted the gap between AI code generation and safe, governed database change, a gap Flyway is positioned to close.
- Rystad Energy
- Energy data and analytics company. Had independently built two AI agents. Consistent with the broader pattern: customers aren’t waiting for official integrations, they’re building workarounds, which proliferate into fragile, unsupported workflows.
- MorphIT / Hamish Watson
- Redgate Community Ambassador and SQL Server consultant. Clients in regulated industries (finance, national defence) being asked about AI strategy with no answer. Named the governance and audit-trail gap as the biggest concern, and where Flyway was being beaten in conversations.
Recruitment
The hardest part was getting in the room
Recruitment was the hardest part of the programme. I ran outreach across four channels at once: Sales Engineers, direct customer email, Redgate Community Ambassador access via a colleague, and community forums. Even so, response rates were slow. Holiday periods, SE availability and the difficulty of getting warm introductions all created friction.
The experience surfaced a structural gap: Redgate has no systematic mechanism for getting designers in front of customers for research. I flagged this as a process problem rather than a one-off difficulty. It’s the kind of thing that only becomes visible when you do the work end to end.
“Diparati navigates the complex world of internal stakeholder relationships with ease and grace.”
Findings
What came up consistently enough to act on
Four findings held across sources. Select one to see which evidence supported it.
Across every call, customers were actively experimenting with AI in their database workflows without waiting for an official integration. Stifel built their own Redgate support agent. StubHub is building a Flyway skill in Claude Code. Rystad built two AI agents independently. Internal SEs had written AutoPilot scripts and context files to fill the gap. The workarounds exist because the official path doesn’t.
Sources Stifel · StubHub · Rystad Energy · Hamish Watson · Internal SEs
AI agents don’t know how to set Flyway up, don’t know the breadth of what it can do, and can’t interact with it reliably. Documentation is fragmented and contradictory. CLI output isn’t optimised for AI consumption. The gap isn’t just a missing feature; it’s a foundational compatibility problem that limits any AI integration we build on top of it.
Sources Stifel · Multiple SE conversations · Secondary research
Nobody refused AI categorically. But the consistent conditions were visibility into what the AI did, reversibility of its actions, and real human review (not rubber-stamping). One participant’s framing was decisive: human review only works if the reviewer already knows what good looks like. Skills should recommend and explain, not auto-execute, unless explicitly configured to do so.
Sources All interviews · SQLBits · Simple Talk secondary research
Customers in finance, healthcare and defence can’t use whatever AI model Redgate ships against. Their security teams have approved specific models. Any Flyway AI integration that assumes a particular model is a non-starter for this segment. The Liquibase approach, Bring Your Own Model, where the customer plugs in their approved model, addresses this directly and is a design principle we need to adopt.
Sources Hamish Watson · Intelliflo · Stifel · Liquibase competitive research
Synthesised themes
Six of the eight themes
Synthesis produced eight themes across all sources. Here are six of them.
Theme 1
The database bottleneck problem. AI is driving a 10x increase in application code output. Database changes are lagging behind. For AI-forward teams this is a business blocker, not a developer-experience issue.
Theme 2
Flyway as orchestrated tool, not primary GUI. The mental model shifts from “developer opens Flyway” to “agent calls Flyway”. Customers want the Flyway CLI to be a self-describing component an AI agent can invoke. The deterministic core is a feature, not a limitation.
Theme 3
Reversibility, visibility and meaningful review. Trust conditions are consistent across participants: AI must show its work, actions must be reversible, and human review must be substantive, not a checkbox. Expertise is required for review to be meaningful.
Theme 4
Security as a first-class constraint. AI-mature customers already have MCP allowlists managed by security teams. The risk isn’t AI making a mistake; it’s the person who set it up not doing so securely. Security posture must be designed in, not bolted on.
Theme 5
Skills and context files as an interim bridge. In the absence of a native Flyway MCP server, customers are building FLYWAY_AI_CONTEXT.md files, AutoPilot scripts and community MCP wrappers. Real demand signal, and a risk if unofficial patterns proliferate unsupported.
Theme 6
Onboarding friction as a hidden adoption barrier. For some practitioners the barrier isn’t AI scepticism or missing features; it’s setup friction. AI-assisted onboarding may be a higher-leverage integration point than initially assumed.
Recommendation
Ship the developer-workflow MCP server first, then build deployment on top
The research surfaced a real sequencing question: skills versus MCP, and if MCP, what to build first. The team prioritised a v1 MCP server covering the core developer workflow: inspecting changes, updating the schema model, and generating migration scripts. That shipped in Flyway 13.0.0, ahead of a dedicated skills release, on the reasoning that MCP was the more durable foundation and skills could be layered on top rather than precede it.
Deployment-focused MCP capability is the next area of work: extending the server beyond local, development-time actions to cover applying changes across environments. It’s also expected to underpin the cross-product Redgate Assistant diagnose-and-fix loop being explored in a separate initiative.
Reflection
What this taught me
Recruitment is the research
Getting in front of customers took more of the programme than the interviews did. Naming that as a process gap, rather than absorbing it as personal difficulty, was the more useful move.
Get hands-on with the thing you’re researching
I set the MCP server up myself, on my own machine. That uncovered documentation gaps and a potential macOS packaging issue, and it meant I could give engineering specific evidence rather than vaguely reporting that setup was hard. I should have done it sooner.
Keep the hypotheses moving
Seven versions of a research plan sounds like indecision. It wasn’t. The landscape moved between the first draft and the last interview, and the plan had to move with it. The same goes for the sequencing question: the research framed it, the team decided it, and the evidence is still doing its job as the deployment work starts.