Ardent vs Aurora cloning
What is Aurora?
Amazon Aurora is a cloud-native relational database with MySQL and PostgreSQL compatibility. Aurora supports 'fast cloning' using copy-on-write at the storage layer — clones share the underlying Aurora storage volume and only store modified pages.
Aurora cloning is a mature, AWS-native feature. The storage clone itself is fast. However, the compute provisioning step takes 5+ minutes, clones have a 0.5 ACU minimum (they never truly scale to zero), and the fast clone limit is 15 per cluster.
What is Ardent?
Ardent creates database branches of any Postgres database in under 6 seconds — including compute provisioning. Branches scale to true zero when idle and resume in milliseconds with no cold start. There's no limit on the number of branches.
Ardent also adds change data capture (CDC) to track every modification on a branch, enabling a diff workflow: create a branch, let an agent work on it, review exactly what changed, then apply or discard.
Where Ardent wins
Instant resume — no cold start
Aurora added auto-pause (scale to 0 ACU) in late 2024, but resuming takes 15-30 seconds — longer if paused over 24 hours. Every agent run starts with a cold start wait. Ardent branches resume in milliseconds with no cold start, making scale-to-zero actually usable for interactive workflows.
6 seconds vs 5+ minutes
Aurora's storage clone is fast, but compute takes 5+ minutes to provision. Every agent run, every developer sandbox, every CI test starts with a 5-minute wait. Ardent branches — including compute — are ready in under 6 seconds. That's the difference between a blocking workflow and a seamless one.
No clone limit
Aurora caps fast clones at 15 per cluster. Clone #16 triggers a full physical copy — effectively a dump and restore that takes hours for large databases. Ardent has no branch limit. Create hundreds of branches for concurrent agent sessions, CI runs, or developer sandboxes.
No migration required — branch where you are
Aurora cloning requires your database to be on Aurora. If you're on Supabase, standard RDS, PlanetScale, or self-hosted Postgres, you'd need to migrate your entire production database onto Aurora first — a weeks-long project with significant risk. Ardent connects to your existing database and branches it in place. No migration, no vendor lock-in.
Separation of concerns — keep the best of both worlds
With Aurora, you're coupling your production database choice to your branching tool. What if PlanetScale gives you the best query latency at scale, but you need copy-on-write branching? Ardent decouples branching from hosting. Pick the best database for production performance, and layer Ardent on top for branching. You don't have to compromise.
Built-in diff
Aurora clones don't track what changed. Ardent captures every modification on a branch — run 'ardent branch diff' to see exactly which tables, rows, and schemas were modified before applying anything to production.
Where Aurora fits
Aurora is the right choice if you need a production-grade, AWS-native database with high availability, automatic failover, and deep AWS ecosystem integration. Aurora's storage layer is excellent — up to 128 TB with 6-way replication across 3 AZs.
For teams already running on Aurora with low clone counts (under 15) and workflows that can tolerate 5-minute spin-up times, Aurora cloning works without adding a new tool to the stack. If your clones run for extended periods (days/weeks), the 0.5 ACU minimum matters less.
The biggest hidden cost of Aurora cloning is the migration itself. If you're not already on Aurora, moving your production database is a weeks-long engineering project with real risk. Teams often underestimate this — and once you're on Aurora, you're locked into AWS pricing and infrastructure.
Where Aurora cloning breaks down: agent use cases where you need dozens of concurrent sandboxes, each used for minutes then discarded. The 5-minute spin-up, idle compute floor, and 15-clone cap make it impractical for high-throughput, short-lived branch workflows.
Pricing comparison
Aurora clone cost: $0.12/ACU-hour when active. Aurora now supports auto-pause (0 ACU), but resuming takes 15-30 seconds and doesn't work with RDS Proxy. If you disable auto-pause for faster access, the 0.5 ACU minimum costs ~$43/month per idle clone.
Aurora clone management: Each clone is a separate Aurora cluster you manage — monitoring, patching, security groups, parameter groups. 10 clones = 10 clusters to manage. Plus the 15-clone cap means you'll hit limits quickly.
Ardent: Developer plan $250/month includes 250 branch compute hours and 100 GB storage. Idle branches cost $0 — compute scales to true zero and resumes in milliseconds. Branches are managed through a single CLI, not individual database clusters.
Frequently asked questions
How does Ardent compare to Aurora cloning?
Aurora clones take 5+ minutes, have a 0.5 ACU idle minimum (~$43/mo each), and cap at 15 fast clones. Ardent branches in under 6 seconds, scales to true zero, and has no branch limit.
Can Aurora clones scale to zero?
Aurora added auto-pause (scale to 0 ACU) in late 2024, but resuming takes 15-30 seconds. It also doesn't work with RDS Proxy or scheduled jobs. Ardent branches scale to zero and resume in milliseconds — no cold start.
What happens when you hit Aurora's 15-clone limit?
Clone #16 triggers a full physical copy — effectively a dump and restore that takes hours for large databases. Ardent has no limit. Every branch creates in the same 6 seconds regardless of how many exist.
Can I use Ardent with my Aurora database?
Yes. Ardent can branch Aurora PostgreSQL databases (Aurora is Postgres-compatible). You get Ardent's faster branching, scale-to-zero compute, and change tracking on top of your existing Aurora production database.