Database branching for Supabase
Branch your Supabase Postgres database in under 6 seconds with full data. Test migrations, validate RLS policy changes, and let AI agents work on real data — without touching your production Supabase project. Copy-on-write storage means zero duplication cost.
Supabase projects are hard to test safely
Supabase makes it easy to build — but testing database changes against production data is still hard. Creating a second Supabase project means duplicating data, reconfiguring RLS policies, and keeping schemas in sync manually. Most teams test migrations against empty databases and discover bugs in production.
Supabase's preview branching creates schema-only copies from migration files. But many bugs only surface with real data: constraint violations on existing rows, RLS policies that fail on specific user data, and performance issues with real data volumes. Database testing is consistently cited as the top pain point for Supabase teams scaling beyond their first project.
How Ardent solves this
Ardent connects to your Supabase Postgres database and creates full copy-on-write branches. Each branch includes your schemas, RLS policies, functions, triggers, and — critically — your actual data. Branches create in under 6 seconds regardless of database size.
Your application code, AI agents, or CI pipeline can connect to the branch using a standard Postgres connection string. Test RLS policy changes against real user data. Run migrations against real rows. Let Claude Code clean up data on a branch. When you're satisfied, apply the changes to production.
Ardent handles the Supabase-specific complexity: auth schema stubs, extension compatibility, and schema-level replication. You focus on building.
# Install and log in
npm install -g ardent-cli
ardent login
# Connect your Supabase database (one-time setup)
ardent connector create postgresql postgres://postgres:pass@db.yourproject.supabase.co:5432/postgres
# Create a branch with full data
ardent branch create test-rls-changes
✓ Branch created in 5.1s
postgres://branch-rls01.db.tryardent.com:5432/postgres
# Test your RLS policy changes on real user data
psql $BRANCH_URL -c "SET ROLE authenticated; SELECT * FROM private_data;"
# Review changes and cleanup
ardent branch diff
ardent branch delete test-rls-changesWhat makes this work
Full Supabase schema support
Branches include RLS policies, functions, triggers, extensions, and auth schema stubs. Your Supabase-specific setup is preserved on every branch.
Real data for real testing
Unlike schema-only branching, Ardent branches contain your actual data. Test constraint changes against real rows, not empty tables.
Works alongside Supabase CLI
Ardent doesn't replace Supabase's tools — it complements them. Use Supabase CLI for local development, Ardent for production-data testing.
Scale-to-zero compute
Branch compute autoscales to zero after 5 minutes idle and resumes instantly — near-zero first-query latency, no cold start. No overprovisioning — you only pay for compute when actively testing.
Traditional approach vs. Ardent
Frequently asked questions
Does Ardent work with Supabase databases?
Yes. Ardent connects to your Supabase Postgres database and creates copy-on-write branches with your full schema, RLS policies, functions, triggers, and data.
How is Ardent different from Supabase's branching?
Supabase's built-in branching creates empty branches from migrations. Ardent creates branches with your actual production data using copy-on-write — so you test against real data, not empty schemas.
Does Ardent preserve RLS policies?
Yes. Branches include all RLS policies, functions, triggers, and schema objects. You can test RLS changes against real data before deploying to production.
Can I use Ardent with Supabase Auth?
Ardent creates branches of the Postgres database layer. Auth, Storage, and Edge Functions are Supabase-managed services that aren't branched. However, auth schema tables are stubbed so your RLS policies and functions that reference auth.users continue to work.