Safe database migration testing
Test every database migration against production-identical data before deploying. Ardent creates Postgres branches in under 6 seconds with copy-on-write — catch constraint violations, data loss, and locking issues before they cause outages.
Migrations are the #1 cause of database outages
Schema migrations that pass in testing but fail in production are one of the most common causes of database incidents. The root cause is always the same: test databases don't have real data.
Adding NOT NULL to a column? Works on an empty table, fails on 2 million rows with NULLs. Creating a unique index? Works with seed data, fails when production has duplicates. Dropping a column? Works in staging, breaks 15 views and 3 materialized views that reference it. These bugs only surface with real data, real volumes, and real dependencies.
How Ardent solves this
Ardent creates a production-identical branch of your database in under 6 seconds. The branch has the same schemas, data, indexes, constraints, triggers, and functions as production — created using copy-on-write so there's no storage duplication.
Run your migration against the branch. If it succeeds, it will succeed in production. If it fails, you've caught the bug before deployment. You can also benchmark execution time to know whether a migration will lock tables for seconds or hours.
After the migration runs, use ardent branch diff to see exactly what changed: which tables were modified, which rows were affected, and whether any data was lost. This gives you a complete audit trail before you touch production.
# Install and log in (one-time setup)
npm install -g ardent-cli
ardent login
ardent connector create postgresql postgres://user:pass@host:5432/mydb
# Create a branch for migration testing
ardent branch create test-migration-v47
✓ Branch created in 4.6s
postgres://branch-mig47.db.tryardent.com:5432/mydb
# Run the migration against the branch
DATABASE_URL=postgres://branch-mig47.db.tryardent.com:5432/mydb \
npm run db:migrate
# Review every change the migration made
ardent branch diff
# Shows row-level changes: which rows were inserted, updated, deleted
# Safe to deploy — migration verified against real data
ardent branch delete test-migration-v47What makes this work
Catch constraint violations early
NOT NULL on columns with NULLs, unique indexes on duplicate data, foreign keys referencing deleted rows — all caught on the branch, not in production.
Benchmark execution time
Know whether ALTER TABLE will take 2 seconds or 2 hours on your real data volumes. Plan maintenance windows with actual performance data.
Audit trail before deploy
ardent branch diff shows every schema and data change the migration made. Review the complete impact before applying to production.
Scale-to-zero compute
Branch compute autoscales to zero when idle and resumes instantly — near-zero first-query latency, no cold start. Run migration tests on demand without paying for always-on staging.
Traditional approach vs. Ardent
Frequently asked questions
Why do database migrations fail in production?
Migrations fail because they're tested against empty or synthetic databases. Real production data contains NULLs, duplicates, orphaned foreign keys, and data volumes that seed scripts don't replicate.
How does Ardent help test migrations safely?
Ardent creates a copy-on-write branch with your real production data in under 6 seconds. Run your migration on the branch. If it fails there, it would fail in production — and you caught it before deploying.
Can I test migration performance on a branch?
Yes. Branches contain real data volumes, so you can benchmark execution time, check for table locks, and verify index creation performance on actual data.
Does Ardent work with migration tools like Prisma or Flyway?
Yes. Ardent provides a standard Postgres connection string. Any migration tool that connects via Postgres works: Prisma, Flyway, Alembic, Django migrations, Knex, TypeORM, and others.
How much storage does each branch use?
Branches use copy-on-write storage — they only store the delta (changes) from production. A migration test that modifies 10,000 rows on a 500 GB database uses only the storage for those 10,000 changed rows.