Bytebase

Last reviewed Aug 26, 2026 · 761 words

Bytebase is not a migration runner; it is a change management process for databases, and that distinction decides whether you want it. Flyway and Liquibase apply versioned SQL files at deploy time. Bytebase puts a review step, an approval gate, a linter, an audit log and a rollback plan in front of every ALTER TABLE, across MySQL, PostgreSQL, ClickHouse, MongoDB, Oracle, SQL Server and about 15 other engines. With 2 or more people touching production databases, that is worth the 1 GB of RAM. With 1 person, the catalogue's "overkill for solo devs" con is exactly right, and psql plus a migrations directory in Git is the better tool.

One container, one volume, one flag you should not skip

Bytebase is a Go binary with an embedded PostgreSQL for its own metadata, so the install is a single container:

docker run -d --name bytebase \
  --restart unless-stopped \
  -p 8080:8080 \
  -v ~/bytebase/data:/var/opt/bytebase \
  bytebase/bytebase:latest \
  --data /var/opt/bytebase --port 8080

First visit creates the admin account. The flag worth adding early is --external-url https://bytebase.example.com, because GitOps webhooks, SSO callbacks and email notifications all embed that URL and change badly later. For anything beyond a trial, --pg postgresql://user:pass@host:5432/bytebase moves the metadata to your own Postgres so backups are one pg_dump rather than a volume snapshot, and the Postgres-for-everything argument applies here as well as anywhere.

Ports inbound are just 8080. Outbound, Bytebase needs to reach every database it manages, which is the security conversation to have with yourself: this box holds credentials to all of them, so it belongs on the management network behind a VPN, not on a public host.

The workflow: issue, review, rollout, audit

Register an instance (a database server), map its databases to a project, and assign environments like dev, staging and prod. From then on, a schema change is an issue: someone submits SQL, the SQL review engine runs it against roughly 100 configurable rules (no DROP without WHERE, index naming, column comments required, no SELECT * in views), a reviewer approves, and Bytebase executes it environment by environment. Every statement, who ran it and when lands in the audit log. For MySQL and Postgres it can capture a prior backup of affected rows for rollback of data changes.

The SQL Editor is the other half. It gives teammates a browser query console with per-environment read-only defaults, so nobody needs a production password in a desktop client. Data masking on columns tagged as sensitive works there, which is the feature that quietly makes a compliance conversation shorter.

GitOps mode is where the "CI/CD" claim comes true

Point a project at a repository on GitHub, GitLab, Bitbucket or Azure DevOps (self-hosted Gitea works through the same webhook path with some setup) and Bytebase watches a path like migrations/. A merged file named 202608261200__add_orders_index.sql becomes an issue automatically, goes through the same review, and rolls out. Combine that with a CI step calling the bytebase-action container to run SQL review on pull requests, and schema changes get the same pipeline as application code, which is the whole point of putting it in the CI/CD category.

Batch change across many databases sharing a schema (one per tenant, one per region) is the feature that makes agencies and SaaS shops choose it over Flyway: 40 databases, 1 issue, 1 approval.

What is free and what is not

The Community edition is MIT-licensed and covers the core workflow, SQL review, GitOps, the editor and the audit log with no user limit. Pro and Enterprise add SSO, approval flows with multiple stages, advanced masking, environment tiers and support, priced per instance at last check. A self-hosting team of 5 gets the useful 80 percent for free. Read the licence page before assuming a specific feature is in Community; the line moves between releases.

What I'd do

A team of 3 or more with a production database: Bytebase in one container behind Tailscale, metadata on external Postgres, prod set to require 1 approval, SQL review rules turned on at warning level for a month before making them errors, and GitOps mode wired to the repo so nobody runs ALTER from a laptop again. Back up its Postgres with the rest of your 3-2-1 routine. Working alone: skip it, keep migrations in Git, and revisit when you hire the second person.