Bytebase vs. Flyway: a side-by-side comparison for database schema migration

Flyway and Bytebase both handle database schema migration, but they solve different problems. Flyway is a migration engine. You write SQL scripts, run flyway migrate, and it tracks what has been applied. Bytebase is a database governance platform. Migration is one part of it, next to SQL review, approval workflows, access control, data masking, and audit logging.

The comparison has also moved. Flyway today is rarely just the open-source CLI. Teams evaluating it are usually evaluating Flyway Enterprise and the Redgate tools around it, so this post compares against that, and says where the free edition stops.

Flyway Today: Community, Enterprise, and the Redgate Toolchain#

Redgate acquired Flyway in 2019. The product now ships in two editions:

• Flyway Community is free. The engine is Apache 2.0 open source, and Community adds Flyway Desktop on top. Redgate positions it for individual developers and education.
• Flyway Enterprise is paid and quote-only. It adds script generation from Redgate's comparison engine, state-based deployments, bundled code analysis with Redgate's own rules, undo script generation, drift detection, change reports, and an audit trail.

Redgate's product and pricing pages list only these two editions. Its licensing documentation still names a Teams edition, so treat the lineup as in flux and confirm with Redgate before planning around a specific edition.

Flyway also sits inside a larger Redgate portfolio, and buyers often meet the pieces together: SQL Compare for SQL Server schema diffs, SQL Prompt for SQL Server code analysis in the IDE, Data Masker and Test Data Manager for masking test data, and Redgate Monitor for performance monitoring. Most of these are SQL Server first, and each is licensed separately.

Flyway Enterprise closes several gaps the CLI had: generated scripts, policies, and drift. The gaps that remain are about who may change what, and who may query what.

What They Have in Common#

• Native SQL support for defining schema changes.
• Both versioned migrations and state-based (declarative) schema management.
• GitOps integration: changes flow from pull requests into pipelines.
• Schema comparison and synchronization.
• Pre-deployment SQL checks.
• Change history tracking.
• An MCP server for AI coding agents.
• A free edition with an open-source core. The Flyway engine is Apache 2.0; Bytebase is MIT licensed, with enterprise features under a commercial license.

Key Differences Between Bytebase and Flyway#

Pricing Comparison#

The practical difference is where the governance features land. On Flyway, bundled code analysis, undo script generation, and drift detection all require Enterprise. On Bytebase, SQL review, rollback, schema sync, and state-based deployments are in the free tier, and the paid tiers add identity, approval, masking, and audit controls.

Developer Interface#

Flyway has two interfaces. The CLI is the primary tool: write migration scripts, run flyway migrate, and it handles versioning and execution. Flyway Desktop is a GUI with a schema model view, a built-in Git client, and comparison tools. Recent Desktop releases moved more pipeline work into the GUI: code review policies are configured in project settings, and an automated deployment page (in public preview) generates GitHub Actions workflows.

Bytebase is a web application where developers submit changes, the team reviews them, and the platform rolls them out. The same workflow is available through the API, the Terraform provider, and GitOps.

Flyway Desktop is a developer tool that runs on one machine. The Bytebase GUI is shared: a developer, a DBA, and a security reviewer look at the same change.

Supported Databases#

Flyway supports more than 30 database engines, over 50 platforms once managed-cloud variants such as Amazon RDS, Azure SQL, and Google Cloud are counted. The list includes PostgreSQL, MySQL, MariaDB, Oracle, SQL Server, Db2, Snowflake, BigQuery, Redshift, Databricks, ClickHouse, MongoDB, Cassandra, SQLite, and SAP HANA. Support is not uniform: the Enterprise-only advanced capabilities cover SQL Server, Oracle, PostgreSQL, and MySQL (Databricks in preview), and a few platforms are community-supported or in preview.

Bytebase supports 25 database engines: 9 RDBMS (MySQL, PostgreSQL, Oracle, SQL Server, MariaDB, TiDB, OceanBase, CockroachDB, Spanner), 6 NoSQL (MongoDB, Redis, Cassandra, DocumentDB, DynamoDB, Cosmos DB), 9 data warehouses (Snowflake, BigQuery, Redshift, Hive, ClickHouse, Databricks, StarRocks, Doris, Trino), and Elasticsearch.

Flyway covers more databases for running migrations. Bytebase covers fewer, and applies its review, masking, and access controls to each engine it supports.

Installation#

Flyway CLI downloads include their own Java runtime, so you no longer install a JVM first. Teams embedding Flyway through the Java API or the Maven and Gradle plugins need Java 21 as of Flyway 13. Flyway Desktop is a separate installer.

Bytebase ships as a single Go binary with no external dependencies. Deploy it with Docker or Kubernetes, or use Bytebase Cloud.

Change Execution#

Flyway uses versioned SQL migration scripts. Name them V1__create_users.sql, V2__add_email_column.sql, and run flyway migrate. Flyway records applied versions in a metadata table and runs only the new ones. Repeatable migrations (prefix R__) are reapplied when their checksum changes, which suits views and stored procedures.

Bytebase runs every change as a reviewed plan. A developer submits SQL for one database or many, SQL review runs against it, any approval flow that applies routes it to approvers, and the rollout proceeds environment by environment. For large MySQL tables, Bytebase can run the change as an online schema migration with gh-ost, so the table stays writable during the migration.

State-Based Deployments#

Both tools let you declare the target schema and generate the migration, instead of writing every ALTER by hand. They differ on edition, engines, and what happens to the generated script.

Flyway Enterprise calls this state-based deployment. You keep a schema model of every object in version control, and the prepare and deploy commands use Redgate's comparison engine to generate a dependency-ordered deployment script. It covers SQL Server, Oracle, PostgreSQL, and MySQL, with Databricks in preview. It is not in Community.

Bytebase offers a state-based workflow on every plan, including Community. You declare the target schema in your repository, and Bytebase computes the DDL to reach it. The generated DDL goes through the same SQL review and approval as a hand-written change, so declaring a target does not skip the gates.

Check the scope before planning around it. Bytebase's state-based workflow covers PostgreSQL and MySQL only, and a defined set of object types within them; the limitations page has the current list. SQL Server and Oracle teams who want state-based deployments today will find wider engine coverage in Flyway Enterprise.

Schema Sync#

Flyway Desktop compares a development database or schema model against a target and generates migration scripts from the difference. Script generation from the comparison engine is an Enterprise capability. For SQL Server, Redgate's separate SQL Compare product covers ad-hoc schema diffs and deployment scripts.

Bytebase has schema sync in every plan. Pick a source database or a past schema version, then one or more targets. Bytebase generates the diff for each target and applies them as one change, going through SQL review and the same rollout controls as any other change. It keeps staging aligned with production, or syncs dozens of tenant databases in one pass.

Batch Change#

Flyway deploys one target at a time. To roll a change across environments or tenants, you run flyway migrate or flyway deploy once per target in your pipeline and write the orchestration yourself. Flyway Pipelines, Redgate's hosted dashboard, then shows what was deployed where.

Bytebase orchestrates the rollout. A single change can target multiple environments (dev, staging, prod) on every plan. Database groups, which target every tenant database matching a rule, are available on Pro and Enterprise.

SQL Review and Code Analysis#

Flyway Community can run SQL checks if you install and manage SQLFluff yourself; Flyway wires it into the pipeline. Flyway Enterprise removes that setup: the check command bundles SQLFluff, adds a library of Redgate rules (RG01 to RG23 at the time of writing) aimed at data-loss and security issues, and can fail CI on a violation. You can also load custom SQLFluff rules. Policies are enforced before merge, and Flyway Enterprise lets you grant exceptions for legacy code, which can be set to require approval.

Bytebase includes SQL Review with 200+ engine-specific rules across MySQL, PostgreSQL, Oracle, SQL Server, and more, on every plan. Rules are attached per environment, so the same statement can warn in dev and block in prod.

SQL review runs in two places:

1. When a change is submitted in Bytebase.
2. In CI, when a pull request contains SQL. Make the review job a required check so a failing review blocks the merge.

Approval Flow#

Flyway has no approval workflow for database changes. Approval lives in the CI platform: Flyway's generated GitHub Actions workflows pause on GitHub Environments with required reviewers, and Flyway runs its checks before the pause. That works, but the approver sees a pipeline run, not the database change, its risk, or who is asking for it.

Bytebase Enterprise has custom approval flows attached to the change itself. Each flow has a condition built from the environment, project, database engine, SQL type, affected rows, and a risk level Bytebase calculates from the statement type, and the first matching flow routes the change through one or more approval stages. A low-risk change in dev can skip approval while a production DROP waits for a DBA. The same flows cover database creation, role requests, and just-in-time access requests, not only schema changes. Community and Pro have no approval workflow; their rollout policies control who may deploy to each environment and whether plan checks must pass first.

One caveat: custom approval applies to changes made in Bytebase. In a GitOps workflow, Bytebase expects the approval to happen in the pull request, just as Flyway's does. The difference is what sits next to it: SQL review as a required check, and the rollout, masking, and audit trail in Bytebase afterwards.

Rollback#

Flyway rollback is undo migrations: a U1__...sql script that reverses V1__...sql. Undo is a paid feature; Community has none. Flyway Enterprise can generate undo scripts for you, and the scripts still need to be reviewed and tested like any migration.

Bytebase handles data and schema separately, on every plan:

• Data changes: Bytebase backs up the affected rows before an UPDATE or DELETE runs, then offers one-click rollback from that backup. This covers MySQL, PostgreSQL, Oracle, and SQL Server.
• Schema changes: roll back from a changelog entry, or sync the database back to an earlier schema version.

Drift Detection#

Flyway Enterprise detects drift: flyway check -drift compares the target database against what the applied migrations should have produced, and generates drift resolution scripts. Flyway Pipelines flags drift across deployments.

Bytebase does not offer drift detection; the feature was removed in 3.14. Its answer is prevention rather than detection. With access control and approval in place, changes that bypass the workflow are the exception, and schema sync brings a drifted database back to a known version. If your environment has many people with direct DDL access you cannot remove, Flyway's drift reports are the stronger fit.

CI/CD Integration#

Flyway runs as a CLI step in any pipeline: GitHub Actions, GitLab CI, Jenkins, Azure DevOps, Octopus Deploy, Harness, TeamCity. Flyway Desktop can generate GitHub Actions workflows, and recent CLI releases return distinct exit codes, so a pipeline can branch on the exact failure.

Bytebase GitOps runs inside your CI on GitHub, GitLab, Bitbucket, and Azure DevOps. SQL review runs on the pull request, and merged SQL files become a release that Bytebase rolls out across environments. For other platforms, the API connects any pipeline.

AI Agents and MCP#

Both vendors now expect AI coding agents to write database changes, and both answer with an MCP server that keeps those changes inside the governed path.

Flyway MCP Server shipped with Flyway 13 in July 2026 as an Enterprise feature, in preview. It lets agents such as Claude Code, GitHub Copilot, Cursor, and Gemini run Flyway commands against migrations and state-based projects, so agent-written changes are version-controlled and policy-checked.

Bytebase has an MCP server on every plan. The agent signs in through OAuth and acts with that user's permissions. Query results honor data masking policies, every proposed change becomes a reviewable change in Bytebase, and every action is audit-logged under the user's account. The SQL Editor also has a built-in AI assistant for writing and explaining queries.

The difference follows the rest of this post. Flyway's MCP server governs the migration path. Bytebase's also governs what an agent is allowed to read.

Change History#

Flyway records applied migrations in the flyway_schema_history table, with versions, timestamps, and checksums. flyway info summarizes it. Flyway Enterprise adds change reports and a commit-to-production audit trail through Flyway Pipelines.

Bytebase keeps a changelog for every database, with the schema diff of each change and a link back to the change that produced it.

Database Access Control and Audit#

Flyway does not cover this area. It controls how changes are deployed, not who can query production. Redgate describes access for Flyway itself through external secrets managers such as HashiCorp Vault.

Bytebase layers access control across its plans:

• Community: built-in workspace and project roles, plus the SQL Editor as a controlled query surface instead of shared credentials.
• Pro: SSO with Google and GitHub, user groups, and an audit log with 7-day retention.
• Enterprise: SSO with OIDC, OAuth 2.0, and LDAP, 2FA, SCIM, custom roles, just-in-time access that expires automatically, dynamic data masking at column level, and an audit log with no retention limit.

When to Choose Flyway#

• Your team is CLI-first and wants migrations embedded directly in existing CI/CD pipelines.
• You run a wide range of databases, including engines Bytebase does not support.
• You are a SQL Server or Oracle shop that wants state-based deployments and generated scripts, or already uses Redgate tools such as SQL Compare and SQL Prompt.
• Drift detection matters because direct DDL access to production cannot be removed.
• You need a migration engine, and approval, query access, and audit are handled by other tools.

When to Choose Bytebase#

• You want change management, SQL review, access control, data masking, and audit logging in one platform instead of several products.
• Your team includes DBAs or platform engineers who review database changes before they reach production, and you want approvals routed by environment and risk rather than by who happens to watch the pipeline.
• You need evidence for compliance: approval records, audit trails, and data masking for SOC 2, GDPR, or internal security policies.
• You run multi-environment or multi-tenant deployments where batch orchestration matters.
• You want SQL review, rollback, schema sync, and state-based deployments on PostgreSQL or MySQL without an enterprise license.
• AI agents query or change your databases, and their access needs the same controls as a person's.

FAQ#

Is Flyway still open source?#

The Flyway engine is Apache 2.0 licensed. Flyway Community, the free edition, adds Flyway Desktop. Redgate's product pages list two editions, Community and Enterprise. Bundled code analysis, undo script generation, state-based deployments, drift detection, and the MCP server are Enterprise features.

Can I use Flyway and Bytebase together?#

They solve different layers. Flyway handles the migration file format and execution; Bytebase handles review, approval, access control, and audit. If you already have a library of Flyway migration scripts, you do not have to throw them away to add governance around how changes reach production.

What is Flyway Desktop?#

Flyway Desktop is Redgate's GUI for database development. It provides a schema model view, a built-in Git client, schema comparison, code review policy settings, and (in public preview) automated deployment setup that generates GitHub Actions workflows. It is included in Community; script generation, state-based deployments, and bundled code analysis require Enterprise.

Which tool has better CI/CD integration?#

It depends on what CI/CD integration means to you. If it means a command you add to a Jenkins or GitHub Actions pipeline, Flyway is the simpler fit: it is a CLI call that works anywhere. If it means SQL in a pull request gets engine-specific review as a required check and then rolls out across environments with a record in Bytebase, Bytebase's GitOps workflow does that out of the box.

How does Flyway pricing compare to Bytebase?#

Flyway Community is free. Flyway Enterprise has no public price; Redgate quotes it, with a 28-day trial. Bytebase Community is free and self-hosted, and the paid Pro and Enterprise plans are listed on the Bytebase pricing page.