Every team running PostgreSQL eventually reaches the same inflection point: the migration tool becomes a liability. Not because it fails, but because it demands a 200 MB Java runtime for what is, at its core, a simple job. Apply SQL files in order. Track what ran. Don’t break production.
We decided to rebuild it.
Why we built Waypoint
Flyway is one of the most widely adopted tools for database migrations, and for good reason. It established conventions that thousands of teams depend on. Versioned SQL files. Checksum validation. A schema history table that tells you exactly what ran and when.
But Flyway requires a full JVM installation. Docker base images that increase container sizes. A dependency graph that makes CI pipelines slower than they need to be. For teams running lean infrastructure (containers, serverless, edge deployments) the overhead is hard to justify. And there is a quieter cost: energy. Running a 200 MB runtime for a job that should take kilobytes of compute is wasteful at scale. Multiply that across thousands of CI runs and deployments, and it adds up. We believe lean code is not just faster. It is more sustainable.
We wanted something that respected Flyway’s conventions while respecting the machine and the resources it consumes.
Why Rust
Database migrations are not the place for ambiguity. A migration tool touches your data, and data is the one thing you cannot afford to get wrong. Rust’s philosophy of correctness by construction resonates deeply with that responsibility. Memory safety without a garbage collector. Errors that must be handled, not ignored. A type system that catches entire categories of bugs at compile time. The same rigour you expect from the database itself, applied to the tool that changes it.
The result is Waypoint: a single static binary that reads your existing Flyway migration files, understands V and R naming conventions, validates checksums against the schema history table, and applies pending migrations. All without a runtime, a framework, or a dependency you didn’t ask for.
- ~4 MB binary size
- ~21 MB Docker image (Alpine based)
- 0 runtime dependencies
- Full compatibility with existing
flyway_schema_historytables
If you’re already using Flyway, switching to Waypoint requires no migration file changes. Point it at your database, and it picks up where Flyway left off.
Beyond Flyway: what we added
Once we had a fast, correct migration runner, we kept going. These are the features we always wished Flyway had:
Safety analysis
Before executing a migration, Waypoint analyses the SQL statements and warns you about operations that could lock tables, cause downtime, or introduce breaking changes. You see the risk assessment before you run, not after.
Auto generated rollbacks
Waypoint can generate rollback SQL from schema diffs. When you add a column, it knows how to remove it. When you create an index, it knows how to drop it. Not a replacement for hand written rollbacks, but a starting point that saves time and catches what you might forget.
Migration simulation
Test migrations against a throwaway schema before running them in production. Waypoint creates a temporary schema, applies the migration, validates the result, and tears it down. You get confidence without risk.
Drift detection
Has someone modified production by hand? Waypoint compares the live schema against what your migrations describe and reports the differences. No more mystery columns or missing indexes discovered in production at 2 AM.
Getting started
Install Waypoint with a single command:
curl -sSf https://raw.githubusercontent.com/tensorbee/waypoint/main/install.sh | shOr pull the Docker image:
docker pull ghcr.io/tensorbee/waypoint:latestRun your first migration:
waypoint migrate --url postgres://localhost:5432/mydb --path ./migrationsWaypoint is open source under the MIT licence. We built it because we needed it, and we think you might need it too.
View on GitHub