shift: click-to-run MySQL schema migrations for sharded databases

shift exists because DDL on MySQL was eating whole days

square/shift describes itself as an application that helps you run schema migrations on MySQL databases. The problem it names is narrow and unglamorous: running schema migrations manually takes too much time, so schema work competes with everything else an operations or DBA team owes. The project points at teams where migrations are taking up too much of their time, an operations team or a DBA group inside a large organization, and then adds that in practice anyone can use it. The scale claim is specific rather than promotional: shift has had no problem running hundreds of migrations a day, or migrations that take over a week to complete. A migration that spans a week is the tell about what kind of tool this is. shift is not aimed at a short ALTER on a table with forty rows. It is built for tables where the copy alone takes days, and for fleets where the same change has to land many times.

The statement runs through pt-online-schema-change, never directly

shift does not execute DDL straight against a live table. Its feature list names the mechanism: safe, online schema changes that invoke the tried-and-true pt-online-schema-change from the percona toolkit. Supported statements are the three that matter for table structure, namely ALTER TABLE, CREATE TABLE and DROP TABLE. Everything else in shift is packaging around that choice, including which DDL an admin has to approve and which shard set a job fans out to. The trade-off is implicit in the design. A direct ALTER on a large table can hold a metadata lock and stall traffic behind it, so shift takes the slower path of copying and swapping in the background, at the cost of requiring the percona toolkit to exist where the runner executes. No percona version is documented for the bundled patch.

Three components split across Rails, Go and a percona patch

shift is not one binary. The repository splits into three components, each with its own readme: a ui directory that is a rails app where you can file, track and run database migrations, a runner directory that is a go agent consuming jobs from an api exposed by the ui, and a ptosc-patch directory holding a patch for pt-online-schema-change from the percona toolkit. The top level also carries a docs directory, CONTRIBUTING.md, LICENSE.txt and README.md. The shape matters for operating it. The browser side is Ruby on Rails, the execution side is Go, and the database-level safety comes from a patched copy of an external tool. A real deployment therefore means running a Rails app, running at least one Go runner that talks to its api, and making sure the patched percona binary sits where the runner expects it.

Filing is self-service, approval is not

Out of the box, shift is built so that any user can file and run migrations, and an admin is only required to approve the ddl. That split is described as configurable, so the approval gate is a default rather than a rule baked into the code. The practical effect is that the person who knows what the schema should become can write it up and queue it, while the person accountable for production data signs off. The interface is the same surface for both roles. The feature list describes a place where you can see the status of migrations and run them with the click of a button. No cli is mentioned anywhere in the project, so if you expect shift to fit a terminal-first workflow, the evidence points the other way.

One migration fans out across every shard

Shard support is listed in plain terms: easily run a single migration on any number of shards. The unit of work stays one migration, and the runner expands it across the shard set. That is the piece that turns a week-long migration into a single click in the interface, and it is the reason the tool targets organizations large enough to have shards in the first place. The alternative for the same job, with one shard per box and a fleet, is to drive the DDL yourself and watch each one. How the shard list is enumerated, and how a fan-out that failed halfway is retried, is not documented. Treat the shard configuration as something you set up and verify by hand rather than something the project explains for you.

The project hands itself off to SchemaBot and Spirit

The most consequential line sits near the top of the README: shift is no longer under active development. Its successor is SchemaBot, Block's GitOps tool for database schema changes, where you describe the desired schema in SQL files, open a pull request, and SchemaBot plans, applies and verifies the change. Online MySQL schema changes run with Spirit. The difference in approach is concrete rather than cosmetic. shift is a service you operate, with a ui, an api, a runner and jobs to approve and click. SchemaBot works from files in version control and a pull request, where planning, applying and verification are part of the change itself. Nothing asks you to migrate an existing shift installation, so treat this as a statement of direction rather than a migration plan.

Where shift stops being the right tool

Three limits follow from the design. First, the supported ddl surface is three statement types, so anything outside ALTER TABLE, CREATE TABLE and DROP TABLE has no built-in path. Second, the safety story depends on pt-online-schema-change actually running, and the repository carries a patch for it rather than the upstream tool, so your runtime depends on a fork that has to be kept in step with the percona releases you upgrade. Third, there is no cli and no external api documented for callers, only the ui and the runner behind it. Add the maintenance note and the picture sharpens. The project is not archived and the last push was on 2026-09-08, so the code is present and reachable, but the project itself says development has stopped.

Apache-2.0 covers the code, not your migration plan

shift is distributed under the Apache 2.0 Licence, with copyright held by Square Inc. and a LICENSE.txt at the repository root, so the code carries a permissive licence with no copyleft obligation on code you build around it. That licence covers shift itself. It says nothing about the percona toolkit it drives, or about the pt-online-schema-change patch in ptosc-patch, which modifies someone else's tool and carries its own upstream terms. The repository has no GitHub releases, which means there is no tagged version stream to pin, no changelog to read before an upgrade, and no published artifact to diff. For a system that runs ddl against production tables, that absence matters more than it would for a library. The upgrade path is to read the diff in ptosc-patch against the percona version you run, and rehearse the whole change on a copy of a real shard before it touches production.

Editorial conclusion

shift suits an operations or DBA team that already runs sharded MySQL and wants a click-to-run, approval-gated path for ALTER TABLE, CREATE TABLE and DROP TABLE through pt-online-schema-change, and it does not suit a team that wants schema files in version control, a CLI, or a project with an active roadmap. Before adopting, check three things: whether the percona toolkit and the ptosc-patch in this repository build cleanly in your environment, how a shard list is configured and retried after a partial failure, and whether you are willing to own code whose documentation says development has stopped, with the last push dated 2026-09-08 and no published releases to diff against. The same note names SchemaBot and Spirit as the path forward.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. square/shift on GitHub