Bytebase vs. SchemaHero

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.

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.

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.

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.

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.

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.