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

SchemaHero and Bytebase both move schema changes into your database, but they come from opposite instincts.

SchemaHero treats a table like a Kubernetes object. You declare the shape you want in YAML, kubectl apply it, and an operator reconciles the running database to match. It's a Deployment controller for your schema: desired state in, drift detected, ALTER TABLE generated. It started at Replicated, it's Apache 2.0, and it's a CNCF Sandbox project. The latest release is v0.25 (May 2026).

Bytebase treats a schema change like a code change. You propose it, it gets reviewed, linted, approved, and rolled out across environments, and there's an audit trail at the end. Schema migration is one part of it. SQL review, access control, data masking, and audit logging are the rest. If SchemaHero is the controller that keeps your tables in sync with their manifests, Bytebase is the GitHub/GitLab for databases: the place changes get proposed and signed off before they ship.

Put simply: SchemaHero answers "is my schema in the state I declared?" Bytebase answers "who is allowed to change this, did anyone review it, and can I prove what happened?" Those are different questions, and which one keeps you up at night decides the tool.

What They Have in Common#

Before the differences:

• Declarative schema definition: both can take a desired schema and generate the migration SQL to reach it. Bytebase does this via its state-based workflow for PostgreSQL.
• Drift detection: both notice when the live database diverges from the expected state.
• GitOps: both let committed files in Git drive migrations.
• A plan-then-execute step: SchemaHero shows the planned DDL before you approve; Bytebase shows the SQL and runs review before rollout.
• Open source: SchemaHero is Apache 2.0, Bytebase is MIT plus an Enterprise License for enterprise features.

The overlap stops at "what state should this table be in." Everything after that, who's allowed to get it there and what happens around the change, is where they split.

What SchemaHero Focuses On#

SchemaHero is sharp and narrow: keep the schema reconciled to its declaration, inside Kubernetes.

• Kubernetes-native by design. If your control plane is already Kubernetes, SchemaHero adds zero new operational surface. It's one more operator reconciling one more resource type. There's also an operatorless mode that runs plan and apply as standalone CLI steps when you don't want a controller in the cluster.
• Genuinely declarative. You stop writing and sequencing migration files. Describe the table in YAML, and the operator computes the diff and the ALTER TABLE.
• Schema as a GitOps resource. Tables live in Git next to your Deployments and Services, shipped by the same kubectl apply loop.
• Drift correction is the whole loop. Both tools detect drift, but SchemaHero is the one that actively reconciles it. The manifest wins, continuously, with no human in the path. If you want the database to always match the declaration, that's its entire reason to exist.
• No commercial relationship. Apache 2.0, no paid tier, no vendor. You run it, you own it.

What Bytebase Focuses On#

Bytebase is wide: govern who changes a database, review the change, and prove what happened, on or off Kubernetes.

• Review before it ships. 200+ engine-specific SQL review rules catch the missing WHERE, the unsafe DDL, the convention violation, before the change lands. Free tier; warn in dev, block in prod.
• Routed approval, not just a gate. Define who approves what. "DDL on prod needs DBA approval", "changes touching 3+ databases need a manager", and the change finds the right reviewer.
• Centralized access control. Credentials never leave the Bytebase server, and you grant fine-grained roles per database, schema, or table, not "the whole cluster secret or nothing."
• Data masking on the read path. Column-level masking protects PII when people query through Bytebase, which SchemaHero can't do; it never touches the query path.
• Drift that routes back. Bytebase snapshots the schema on every migration and flags any out-of-band change as an anomaly with a diff, then brings it back through the reviewed pipeline instead of silently overwriting it.
• Answer the auditor. Every change and every query tied to a user identity in the audit log. The SOC 2 answer without stitching three tools together.
• Runs anywhere. A single Go binary or container. Kubernetes is one option, not a prerequisite.

YAML vs. SQL: the difference you feel on day one#

Before the governance differences, there's a plainer one: what you actually type. SchemaHero wants a table described as YAML. Bytebase wants the SQL.

Add an email column in SchemaHero, and you edit the Table manifest:

columns:
  - name: email
    type: text
    constraints:
      notNull: true

kubectl apply, and the operator figures out the ALTER TABLE. In Bytebase you write that statement directly:

ALTER TABLE users ADD COLUMN email TEXT NOT NULL;

Both cut both ways. YAML spares you hand-written DDL and reads the same across engines, but it's a new abstraction and only describes shape: no data moves, no backfills. SQL is what your team already knows and covers DML too, but you own its correctness. That's why Bytebase puts lint and review in front of it.

Feature Comparison#

Where Each Fits#

The honest split: SchemaHero assumes the people changing schemas are the people running the cluster. Bytebase assumes they often aren't. A DBA, an analyst, or a developer without a kubeconfig can't drive a SchemaHero migration, and that's by design, not a gap.

Choose SchemaHero if your platform already runs on Kubernetes, your databases are in its set (Postgres, MySQL, CockroachDB, Cassandra, TimescaleDB, SQLite, RQLite), the people changing schemas hold the kubeconfig, and you want a focused Apache 2.0 engine with no vendor attached.

Choose Bytebase if the people changing your databases aren't all on Kubernetes, changes need review, lint, routed approval, and an audit trail rather than a bare kubectl approve, you run engines beyond those seven, or compliance (SOC 2, ISO 27001, HIPAA, PCI-DSS) puts access control, masking, and audit in scope.

These two aren't really competing for the same job. SchemaHero is a sharp, Kubernetes-native reconciler for the state of your tables. Bytebase is the database DevSecOps platform that governs the humans and policies around those changes. Nothing stops you running both: let SchemaHero reconcile schema in-cluster, and let Bytebase own the governance, review and approval before a change ships, access control and masking on the query path, and an audit trail over all of it.

Bytebase is open source with a usage-based pricing model. Full pricing here.