DiffyPick
What your schemas really are, not what migrations claim
2 followers
What your schemas really are, not what migrations claim
2 followers
Visual schema diff and sync for PostgreSQL, MySQL, MariaDB, SQL Server and SQLite. See what changed, cherry-pick what to apply, run it safely. Desktop app for macOS, Windows and Linux.
Free Options
Launch Team / Built With
Render Sandboxes: a computer for every agentIsolated compute, persistent state and a real filesystem
Promoted
Hi Product Hunt 👋
The moment behind this tool is embarrassingly small. I was extending a production system, working locally against a Docker database. Halfway through, something urgent pulled me away. When I came back to the feature branch, the code was all there — and I had no idea what I'd changed in the database. The schema state lived in exactly one place: my head, two weeks ago.
The standard answer is "that's what migrations are for." I'd used them — and stopped. Not out of ignorance, but because on real projects I kept finding databases that had drifted from their migration history anyway: a column in production with no migration file, a hand-applied index nobody recorded. Once the history can't be trusted to describe reality, you're paying the discipline cost of maintaining it and still having to check the actual databases. So I dropped the ledger and kept the check — and realized the check deserved a real tool.
Here's the part that shaped DiffyPick: some schema differences are intentional. A production-only index. A replica-only tuning. No tool can know which differences are deliberate and which are accidents — intent lives in people's heads. A human has to look at each difference and decide.
And that's why this is a GUI tool, not another CLI. If classification is human work, the tool's job is to support human judgment: show every difference one line at a time, make dependencies between changes visible, let you select exactly which changes to apply and fine-tune the result before anything touches a database. A wall of diff text in a terminal can't do that — not because terminals are bad, but because judgment needs structure.
Under the hood: a Rust comparison engine connects to two live databases (Postgres, MySQL/MariaDB, SQL Server, SQLite), compares everything from columns to RLS policies to constraint validation state, and generates sync SQL in dependency-safe order. Fail-closed by design — if something can't be verified, it blocks rather than guesses.
Solo-built, desktop app, macOS / Windows / Linux. The SQLite tier is free forever, no account — that's the "see if you trust it" tier.
How does your team handle schema drift today? I'm especially curious what it would take for you to trust a tool enough to point it at production — that bar is the whole problem this tool lives under.