Database branching vs replicas
What is Traditional Replicas?
Database replicas create full copies of the primary database that continuously synchronize via streaming replication. In PostgreSQL, replicas use WAL (write-ahead log) shipping to stay in sync. They serve two primary purposes: read scaling (distributing query load) and disaster recovery (failover target).
Replicas are a proven, battle-tested approach for production availability. AWS RDS supports up to 15 read replicas, and most managed Postgres services include replica support.
What is Ardent?
Database branches use copy-on-write technology to create isolated, writable copies of a database in seconds. Instead of duplicating storage, branches share the parent's data pages and only store modifications. Ardent creates branches of any Postgres database — Supabase, AWS RDS, or self-hosted.
Branches are designed for different use cases than replicas: testing, development, AI agent workflows, and CI/CD pipelines where you need writable, disposable copies of production data.
Where Ardent wins
Seconds, not hours
Replicas take hours to days to provision because they copy the entire database. Ardent branches in under 6 seconds using copy-on-write — regardless of database size. A 1 TB database branches as fast as a 1 GB one.
Pay for changes, not copies
Each replica stores a full copy of the database. 5 replicas of a 500 GB database = 2.5 TB of storage. 5 Ardent branches of the same database store only the changes — often under 1 GB total.
Fully writable and isolated
Replicas are typically read-only and sync continuously with the primary. Branches are fully writable and completely isolated — changes on a branch never affect production or other branches.
Unlimited copies
AWS RDS caps read replicas at 15. Ardent has no branch limit. Create a branch per developer, per CI run, per AI agent session — without hitting infrastructure limits.
Built-in diff
Ardent tracks every modification on a branch. Run 'ardent branch diff' to review a complete diff of what changed before applying anything to production. Replicas don't track changes — they just mirror.
Where Traditional Replicas fits
Replicas are the right choice for production read scaling and disaster recovery. If you need to distribute read traffic across multiple database instances, replicas with connection pooling are battle-tested. If you need a hot standby for failover, streaming replication with replicas is the standard approach.
Replicas also provide continuous synchronization, which branches don't. A replica always has the latest data from the primary. Branches are point-in-time snapshots — they diverge as soon as production receives new writes.
In short: replicas for production availability, branches for testing and development.
Pricing comparison
Replica costs scale linearly: each replica needs full compute and full storage. An RDS db.r6g.xlarge replica costs ~$0.48/hour ($350/month) plus storage. 5 replicas = $1,750/month in compute alone, plus 5x storage.
Ardent branches share storage via copy-on-write. The Developer plan ($250/month) includes 250 branch compute hours and 100 GB storage. Branch compute scales to zero when idle — you're not paying for compute on branches nobody is using.
For testing and development workflows, branching is significantly cheaper than maintaining equivalent replica environments because you only pay for compute when active and storage for changes only.
Frequently asked questions
What is the difference between a branch and a replica?
A replica is a full, continuously-synced copy for read scaling. A branch is a copy-on-write snapshot that creates in seconds, is fully writable, and is completely isolated from production.
When should I use branching instead of replicas?
Use branching for testing, development, AI agent workflows, and CI/CD. Use replicas for read scaling and disaster recovery.
How much storage does a branch use?
Branches use copy-on-write storage and initially use 0 MB. You only pay for the data that changes. A 500 GB database with 10,000 modified rows stores only those changed rows.
Can branches replace replicas?
Not for read scaling or disaster recovery — those require continuous sync. Branches replace replicas for testing, development, and staging environments where you need writable copies of production data.