Ship schema changes as fast as your code, with the safety net your database deserves
Vision · PR workflow · CLI · Quick start · Docs
SchemaBot is declarative and GitOps-driven: SQL files in your repository provide a shared source of truth across environments. It compares those files with the live database, shows the exact change, and applies it through pull requests or a CLI.
Walk through the illustrated PR workflow
Plan and apply a change. Review the SQL, apply the change, and follow it to completion.
Know your database fleet. Explore live schemas, spot lint issues, and follow changes through their logs.
Get started with the CLI · Explore your database fleet
Block runs SchemaBot for the majority of its production schema changes, including MySQL tables spanning terabytes and Vitess databases with hundreds of shards.
Review the proposed SQL before it runs. Configure who can apply it and which environments it must pass through.
| Protection | How it works |
|---|---|
| Require a review before apply | Enable the review gate to require approval from a configured reviewer before PR changes run. The author's own approval does not count |
| Prove the change in earlier environments | Set the promotion order, such as staging → production. PR applies are blocked until the earlier environment's check passes |
| Keep destructive changes explicit | Lint findings flag unsafe changes. Applying them requires acknowledgment of the exact plan; a changed plan needs a new acknowledgment |
| Merge what is already live | Configure SchemaBot's checks as required checks. They pass when the managed live schema matches the PR, so unfinished changes cannot merge |
These are PR workflow gates. Direct CLI and API calls use server permissions; they do not require PR review or enforce promotion order.
These boundaries matter just as much for a coding agent as for a person. Give agents schema context and scoped access while keeping policy on the server.
Grab the CLI from Releases. From your application’s project directory, run:
schemabot init
The wizard connects to your MySQL or PostgreSQL database, imports its schema into declarative .sql files, and verifies a no-change plan before it finishes. It reads your application's schema and never changes it. SchemaBot keeps its own plans and progress in a separate database, which can live on the same server. Make your first edit and run schemabot plan to preview changes. Run schemabot apply when you’re ready to apply them. docs/init.md walks through each step, including the flag form for agents and scripts.
Want to try SchemaBot with demo databases? See the examples guide.
To run the PR workflow for your team, deploy the server from Releases (binary, container image, or Helm chart), then follow docs/github-app-setup.md to wire up GitHub and docs/configuration.md for the server config. schemabot onboard pulls a live database's schema into a new declarative schema directory against that server, so you start from your real tables rather than writing them out by hand.
| Database | Status | How changes run |
|---|---|---|
| MySQL | Generally available | Spirit, with instant DDL where supported and online copying when needed |
| Vitess on PlanetScale | Generally available | Deploy requests, with per-shard progress |
| PostgreSQL | Early alpha | pg-sprite; see the support envelope |
Follow progress, choose cutover timing, and pause, resume, cancel, or roll back where the engine supports it. Execution methods, throttling, and recovery differ by engine; the capability matrix explains the choices.
Guides and reference:
- Vision: See what we’re building toward
- Quick start: Try it on your machine
- Initialize a database: Connect a database you already have and start from its live schema
- Local examples: Run the demo and connect to its MySQL databases
- Pre-merge workflow: Take a schema change from your first edit to a merged PR
- CLI guide: Set up the CLI, inspect your databases, and run changes
- Schema intelligence: Get to know your fleet and what’s changing
- Engines: See how changes run on your database engine
- PostgreSQL: Find out what’s supported today
- Configuration: Set things up for your environment
- Storage schema: Keep SchemaBot’s own bookkeeping database converged across deploys
- Authentication: Choose who can read and change your databases
- AI agents: Set clear boundaries for your assistants
- Safety invariants: Understand the guardrails behind each change
- Architecture: Follow a change from start to finish
- Target credential self-heal: Understand target probes and credential rotation recovery
- Partition-aware index builds: See the decision for online indexes on partitioned PostgreSQL tables
- Ideas behind SchemaBot: The projects that helped shape it
- Contributing: Come build with us
Releases are published as binaries on the GitHub Releases page, as container images at ghcr.io/block/schemabot, and, if you run Kubernetes, as a Helm chart at oci://ghcr.io/block/charts/schemabot.
Every release tag is deployed to production at Block. SchemaBot is pre-1.0, so read the release notes before upgrading: they describe compatibility changes.
See docs/release.md for how releases are cut and what is checked before a tag is published.
Contributors are welcome. See CONTRIBUTING.md.
For feature requests and bugs, open an issue.