Migrata vs Atlas: Improving the Declarative Database Workflow

That changes how migrations are reviewed.

Instead of asking:

"Does this look safe?"

you can ask:

"What will this affect?"

Schema overview at a glance#

Before showing the migration plan, Migrata prints a side-by-side comparison of the source and target schemas:

This covers tables, partitions, indexes, constraints, functions, enums, views, and materialized views. Values that changed between source and target are highlighted.

It takes a second to scan and tells you the scope of what's changing before you read a single line of SQL. Atlas does not show this view.

This pairs naturally with the impact analysis above. Together they answer two questions before you see the plan: how much is changing and what depends on it.

Better diffing, not just different syntax#

A declarative tool lives and dies by the quality of its diff engine. The diff is where schema intent meets reality. If it gets the details wrong, the generated SQL is worse than useless.

Migrata's diff engine is built to handle the full lifecycle of a schema change, not just detect that something changed.

Full column lifecycle management#

Changing a column from TEXT to FLOAT is rarely a one-line change. Existing data may be invalid, constraints need to be preserved, and indexes must be rebuilt. Migrata handles the entire sequence:

-- Changing column `score` type `TEXT` → `FLOAT`
BEGIN TRANSACTION;

-- Add temporary column
ALTER TABLE public.users ADD COLUMN score_temp FLOAT NOT NULL;

-- Copy and convert data
UPDATE public.users SET score_temp = CASE ... END;

-- Remove old column
ALTER TABLE public.users DROP COLUMN score;

-- Rename replacement column
ALTER TABLE public.users RENAME COLUMN score_temp TO score;

-- Reapply constraints and indexes
ALTER TABLE public.users ADD CONSTRAINT score_non_negative CHECK (score >= 0);
CREATE INDEX idx_score ON public.users(score);

COMMIT;

Every step is annotated with inline comments explaining what it does and why. Migrations are not only executed by the database; they are read by people during reviews, incidents, and debugging sessions. Inline comments keep that context inside the migration itself.

Critically, Migrata reapplies indexes and constraints after column changes. When you modify a column that has a check constraint or an index, the diff engine preserves those dependencies and regenerates them on the replacement column. Atlas does not handle this automatically.

Safe enum value removal#

Enum types in PostgreSQL are notoriously difficult to change. Removing a value requires understanding what existing rows use that value and what to replace it with.

Migrata handles this interactively. When the diff detects a removed enum value, it prompts:

Select replacement value for 'Cancelled':
  > Pending
    Processing
    Shipped
    Delivered

The chosen replacement is then applied transactionally across all tables using that enum. For CI/CD environments, use --answer to pre-supply the replacement:

migrata diff \
  --from ./schema/current \
  --to ./schema/target \
  --answer "status:Cancelled=Pending" \
  --approve

Other tools require you to hand-write this migration. Migrata handles it as part of the normal diff workflow.

Schema organization without directives#

Atlas uses SQL directives to describe dependencies between schema files.

For example, where users depends on roles:

Atlas

-- users.sql

-- atlas:import roles.sql

CREATE TABLE users (
    id BIGINT PRIMARY KEY,
    role_id BIGINT NOT NULL REFERENCES roles(id)
);

-- roles.sql

CREATE TABLE roles (
    id BIGINT PRIMARY KEY,
    name TEXT NOT NULL
);

Migrata keeps everything as plain SQL.

Migrata

-- users.sql

CREATE TABLE users (
    id BIGINT PRIMARY KEY,
    role_id BIGINT NOT NULL REFERENCES roles(id)
);

-- roles.sql

CREATE TABLE roles (
    id BIGINT PRIMARY KEY,
    name TEXT NOT NULL
);

There are no directives, no tool-specific annotations, and nothing that affects how the SQL is written.

Migrata builds the dependency graph automatically and determines the correct order on its own.

Your schema stays portable and easy to reason about.

The full workflow should be available to everyone#

We believe every developer should have access to a complete database migration workflow from day one.

That includes declarative diffs, development database validation, dependency impact analysis, advisory lock protection, and CI/CD integration, all without requiring a paid license.

Developers should not need to secure organizational approval before they can evaluate a tool properly. By making the full local workflow available for free, teams can adopt Migrata because it improves daily work, not because procurement approved it.

Why Migrata exists#

Declarative schema management is no longer the question.

The question is what the developer experience around it should look like.

Atlas helped move the industry toward declarative database management, and Migrata builds on that foundation. The goal is not to reinvent the model. It is to improve the experience of using it.

That means understanding the impact of a migration before it runs, reading SQL that explains itself, and organizing schemas without tool-specific syntax.

These are not extra features. They are the core workflow.

Atlas proved the model. Migrata improves the workflow.