Database schema changes are still one of the most fragile parts of modern software delivery. But this isn't due to a lack of tooling: Flyway, Liquibase, Alembic and others turned versioned, repeatable migrations into a solved problem for many teams across the industry.
These tools deliver on what they promise. But the largest drawback of these tools is that they're designed around an imperative workflow instead of a declarative one. Imperative workflows force you to worry about the "how", whereas declarative tools focus on the outcome. I know it may sound like we're splitting hairs at this point, but to make this distinction clear we'll take a moment to look at our neighboring IaC tools in the cloud space. Declarative tools like Terraform let you describe the desired state of your cloud deployment, whereas the imperative equivalent would be a folder with a bunch of bash scripts. Both approaches result in the same outcome, but the former is far easier to reason about and manage, especially at scale.
I know this pain firsthand. At my current job, our databases are shared across many teams and even more applications. Like many organizations, we follow an imperative migration approach: a folder for each changeset, files with targeted changes per component, all tracked in Git. The problem is that this approach results in thousands of migration files piling up over time. They assume everything will go smoothly and can't verify themselves against our actual production database. So we end up with migrations that run in the wrong order, duplicate existing changes, or try to modify tables that no longer exist.
To prevent disasters, dedicated teams often become gatekeepers, slowing down every release. At my workplace, we have a change approval board whose sole job is to coordinate with database admins to apply these scripts. Most of their time is spent understanding what's changing and whether there are any conflicts.
The problem was never the humans in the loop, it was the review tooling that made this difficult. Declarative workflows naturally centralize configuration so it's easier to catch conflicting changes. To be clear, I'm not advocating for fewer human reviews, I'm arguing for a better review experience. Over the past decade, we've seen this exact argument validated in the DevOps space. It transformed how teams build and operate software. One of the biggest advances was the introduction of Infrastructure as Code to manage the growing complexity of the cloud. Having a version-controlled way to provision infrastructure vastly simplified CI/CD pipelines and reduced the cognitive load around change reviews.
But that same evolution never reached one of the most important components of any system: the database.
After working with Terraform for years, I knew what a declarative workflow should look like. But unlike cloud infrastructure, databases already have a native language to describe their state: plain SQL. Instead of inventing a new DSL, Migrata treats your SQL schema as the source of truth and diffs against it directly.
Migrata doesn't replay a history of migrations, It works from the current state of your schema and computes what actually needs to change. The result is simpler reviews, fewer conflicts, and a workflow that scales with your team instead of slowing it down.
Meet Migrata#
Migrata CLI brings the infrastructure-as-code philosophy to database migrations. Instead of relying on migration files, Migrata lets you inspect and safely apply changes to your database schema. It makes migrations predictable, transparent, and reversible.
The best part? You don't need to learn a new language. Migrata works with plain SQL statements. It parses and diffs them against your live database schema to generate a migration plan. No more guessing whether your local migration files match what's actually in production.
Unlike traditional migration tools, Migrata is state-based, not file-based. You define your desired schema in SQL, and Migrata figures out how to get there. No migration files to track or maintain. Combined with Git, this makes rollbacks trivial: just check out a different branch and generate the diff.
Here's the whole workflow in ~40 seconds:
Key Features#
- Risk Classification: Every planned migration is labeled Safe, Warning, or Destructive so you can assess impact at a glance. Warnings and destructive changes are summarized separately with counts.
- Impact Analysis: See all downstream objects (views, functions, etc.) that depend on ent-ities being modified, right alongside the query plan. No more hunting through your schema to find what might break.
- Schema Overview: A side-by-side comparison of source vs target schemas showing entity counts for tables, partitions, indexes, constraints, functions, enums, views, and materialized views. Changed values are highlighted.
- Safe Cast Migrations: Column type changes use a multi-step process with temporary columns to prevent data loss. Instead of a potentially destructive ALTER COLUMN, Migrata adds, copies, drops, and renames safely.
- Advisory Locks: Concurrent migration protection using PostgreSQL advisory locks. Enabled by default, can be disabled with - --skip-lockwhen you have external coordination.
- Dev-Database Validation: Test migrations against an ephemeral Docker container before touching production. The - --dev-imageflag spins up a temporary database, applies the current schema, runs the migration, and reports any runtime errors.
- Table Partition Support: Detects and compares partition tables. Basic operations like create, drop, and rename are automated. Changes involving data movement are flagged for manual review.
- CI/CD Ready: Use - --answerto pre-supply responses to interactive prompts,- --approveto auto-apply, and- --no-styles/- --no-logsfor clean pipeline output.
- Privacy-First: No email or account required to use Migrata. It runs fully local: no LLMs, no calls to third-party services, and your schema never leaves your machine.
Migrata In Action#
Let's walk through a typical workflow with Migrata.
1. Sync your schema from a live database#
Pull your current database schema into local SQL files. This gives you a complete snapshot of your database structure that you can version control.
$ migrata schema inspect \
--from "postgresql://localhost:5432/mydb" \
--to ./schema
2. Commit your schema to version control#
Check your schema files into Git alongside your application code. This versions your database schema and keeps it synchronized with your source code. This makes it easy to roll back to a previous commit and revert both the code and the database architecture.
$ git add schema/
$ git commit -m "Initial schema snapshot"
$ git push origin main
3. Make changes to your schema files#
Edit your DDL statements directly to add columns, modify types, or adjust constraints. Migrata diffs these files against your live database to generate the actual migration steps.
CREATE TABLE public.users (
id UUID PRIMARY KEY NOT NULL,
username VARCHAR(255) NOT NULL,
email VARCHAR(255) NOT NULL, -- Added column
created_at TIMESTAMP DEFAULT now()
);
4. Review and apply your migration#
Run diff to compare your local changes against the live database. Migrata shows you the risk summary, impacted components, and a detailed query plan, then prompts for interactive approval.
$ migrata diff \
--from "postgresql://localhost:5432/mydb" \
--to ./schema
Use --approve to auto-apply for CI/CD, or --out to persist the plan to file for audit trails and peer review.
That's it. There are no migration files to write, review, or keep in sync. Just your schema in SQL and Migrata handling the rest.
Who's This For?#
- Anyone who values working with declarative workflows
- Developers who prefer working with plain SQL because they need full control
- Teams with databases shared across multiple applications and languages
Ready to try it out?#
Binaries and installation scripts for migrata-cli are published on GitHub.
Linux/macOS#
To install on Linux and macOS, run the following command in your terminal
curl -fsSL https://migrata.io/install.sh | sh
Windows#
To install on Windows, run the following command in your (administrator) PowerShell terminal
irm https://migrata.io/install.ps1 | iex
What's Next?#
Migrata is free to use without an account or any limits, and the core tool will stay that way. As Migrata matures, we plan to offer paid add-ons for teams that need them, like advanced auditing, governance, and collaboration features. The workflow you've seen here will always be free.