--- title: "Bytebase vs. SchemaHero" description: "Compare Bytebase and SchemaHero for database schema management: review, approval, access control, and audit around every schema change, on or off Kubernetes." canonical: "https://www.bytebase.com/compare/bytebase-vs-schemahero/" source-index: "https://www.bytebase.com/llms.txt" --- # Bytebase vs. SchemaHero > Compare Bytebase and SchemaHero for database schema management: review, approval, access control, and audit around every schema change, on or off Kubernetes. Source: https://www.bytebase.com/compare/bytebase-vs-schemahero/ --- ## Bytebase vs. SchemaHero If SchemaHero is a Deployment controller for your schema, Bytebase is GitHub/GitLab for databases — review, approval, access control, and audit around every schema change, on or off Kubernetes. ## The change lifecycle, stage by stage: Bytebase and SchemaHero Both tools take a schema change from a developer's editor to production. The rows below follow that job in order. Where a stage needs a decision about people, who may run this against production, who signed off, who ran the hotfix, Bytebase answers inside the change; SchemaHero leaves it to the tools around it. | Stage | Bytebase | SchemaHero | | --------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------- | | **Set up** — What runs where, and who holds the database credentials? | One binary or container. Developers sign in with SSO and never hold a credential. | An operator in the cluster; the database credential lives in a Kubernetes Secret. | | **Author a change** — How does a developer write and submit a migration? | SQL in an issue, or a file merged through GitOps. | A Table resource in YAML, applied with kubectl; the operator plans the ALTER. | | **Review** — What checks the SQL before a person does? | 200+ SQL review rules on every issue and pull request, all plans. | A plan diff to eyeball. No SQL checks. | | **Approve for production** — Who may run this against production, and where is that recorded? | Rollout policy per environment. Risk-based approval on Enterprise, recorded on the change. | kubectl approve on the plan, by anyone with access to the Migration resource. | | **Roll out** — How does one change reach dev, staging, prod, and every tenant? | One issue carries the change through dev, staging, prod, and every tenant. | One apply per cluster or namespace, sequenced by Argo CD, Flux, or your pipeline. | | **Hotfix data in production** — An UPDATE has to run on prod tonight. How, and by whom? | Same issue: reviewed, approved, rows backed up, one-click rollback. | *Not its job.* | | **Audit** — Six months later, what changed, who approved it, who ran it? | One log of every change, review, approval, and rollout, per person. | Migration status shows what ran. Who approved it is only in the cluster audit log. | | **After the change ships** — Who can read or export the production data the schema now holds? | Project roles, just-in-time access, masking, and export control in the same workspace. | *Not its job.* | ## Who each tool is best for ### Bytebase is best for - All-in-one migration, SQL review, access control, data masking, and audit - Teams where the people changing databases aren't all on Kubernetes - Compliance with SOC 2, ISO 27001, HIPAA, and PCI-DSS - Engines beyond the seven SchemaHero supports (Oracle, SQL Server, Snowflake, NoSQL) ### SchemaHero is best for - Platforms already running on Kubernetes, managing schemas like any other resource - Declarative, GitOps-driven schema reconciliation through Argo CD or Flux - Teams where the people changing schemas are the people running the cluster - A focused, Apache 2.0 migration engine with no vendor attached ## Top 3 reasons leaders pick Bytebase over SchemaHero ### Beyond Kubernetes Developers, DBAs, and analysts ship changes through a web GUI — no kubeconfig, no CRDs, no cluster access required to propose a change. ### Review before it ships 200+ SQL review rules and routed approval catch the unsafe DDL and decide who signs off — not a mechanical kubectl approve anyone with cluster access can wave through. ### Enterprise governance RBAC, risk-based approval flows, dynamic data masking, and complete audit logs — the controls SchemaHero leaves to other tools in your stack. ## Frequently asked questions ### Can I use SchemaHero and Bytebase together? Yes. Let SchemaHero reconcile schema in-cluster and let Bytebase own the governance around it: review and approval before a change ships, access control and masking on the query path, and one audit trail over all of it. The two are not competing for the same job. ### Does Bytebase need Kubernetes? No. Bytebase ships as a single Go binary and a Docker image, with a Helm chart for teams that do run Kubernetes. It runs with or without a cluster, and the people proposing changes need a browser, not a kubeconfig. ### Does Bytebase support declarative schema management? Yes, for PostgreSQL and MySQL. Commit the desired schema to Git and the state-based workflow generates the migration SQL, on every plan including Community. For other engines, schema sync produces the diff SQL between two database states. SchemaHero is declarative across all seven of its engines. ### Does SchemaHero have an approval flow? A mechanical one. The operator generates a plan, and someone runs kubectl approve or reject on it. Anyone with Kubernetes RBAC on the Migration resource can approve; there is no routing to a named reviewer and no check on the SQL itself. Bytebase gates rollout per environment on every plan, adds risk-based approval on Enterprise, and records the approval on the change. ### Is SchemaHero free? Yes. SchemaHero is Apache 2.0, a CNCF Sandbox project that started at Replicated, with no paid tier and no vendor attached. Bytebase is MIT licensed, with a free Community plan and enterprise features under a commercial license. ### Which is better for security and compliance? SchemaHero leaves it out of scope by design: access is whatever Kubernetes RBAC grants on the cluster, and the record of who approved a change is the cluster audit log, if it is enabled. Bytebase records SQL review on every plan and risk-based approval on Enterprise on the change itself, and covers who can read or export production data with roles, just-in-time access, masking, and one audit log. ## Read the full comparison Go deeper on how Bytebase and SchemaHero compare for schema migration, YAML vs. SQL, drift handling, access control, and cost across Community, Pro, and Enterprise tiers. https://www.bytebase.com/blog/bytebase-vs-schemahero/ ## Get Started - [Contact us](https://www.bytebase.com/contact-us/) - [Start now (cloud)](https://console.bytebase.com)