heroku pg:backups:capture --app x
heroku pg:backups:download --app x
pg_restore --verbose --clean --no-acl --no-owner -h localhost -U postgres -d y local_db_for_robots_etc.dump
This takes more than 6 seconds. I'm curious how they achieved that for arbitrary DBs!https://docs.tryardent.com/architecture
But essentially we get around the restrictions of the original DB by replicating into a different postgres compatible DB that essentially serves as a read replica. That DB is the one that branches but since it mirrors the original DB you get effective clones
By doing this we get a lot more control over what we can do to create the clones. The read replica clones using copy on write + isolated autoscaling compute to clone in 6s. We use neon to do this since we think they've implemented those two properties well.
Since it's default postgres logical replication + DDL triggers you can technically point it at any "branching enabled" db on the other end in order to achieve the same effect
> The source database can't have any active connections during cloning.
I wouldn't mind some lock contention, but having to kill all connections seemed a bit harsh
So you don't need to touch real production db?
Not sure if it applies for all use cases tou
Using a cloud provider read replica might not (as I think that might use block level replication) - but then you're paying for an extra dev database host for the privilege
I'd think you could also setup logical rep to a VM then snapshot and clone the storage which is generally pretty fast.
aws rds restore-db-cluster-to-point-in-time \
--source-db-cluster-identifier <source-cluster> \
--db-cluster-identifier <new-cluster> \
--restore-type copy-on-write \
--use-latest-restorable-time \
--db-subnet-group-name <sub group> \
--vpc-security-group-ids <security group> \
--serverless-v2-scaling-configuration MinCapacity=0,MaxCapacity=16Main exceptions are copying/encrypting snapshots when they're not incremental and PITR restores which can take substantially longer.