Full PostgreSQL database copy — including all data — available in under 30 seconds. No pg_dump. No restore. No waiting. Storage cost near zero.
The standard approach to creating a database copy is pg_dump followed by pg_restore. For small databases this is fine. For production databases — which are often tens or hundreds of gigabytes — it becomes a bottleneck that teams work around by not cloning at all.
Cloud snapshots (e.g., AWS RDS snapshots) are faster to trigger but still take 10–30 minutes to restore into a usable database. They also create a full copy on disk, making many-simultaneously-clones expensive.
Vela uses storage-level copy-on-write (CoW): when you clone a database, the clone immediately shares all storage blocks with the source. No data is duplicated. The clone is instantly readable and writable.
When either the clone or the source modifies a page, only that page is written separately — the rest remains shared. This means:
Use cases that were previously too slow or expensive to do regularly
Clone your production database, apply the migration to the clone, validate data integrity and query performance — before running it on prod.
Benchmark queries, indexes, and autovacuum behavior against actual production-scale data. Synthetic data doesn't reveal real bottlenecks.
Give each developer a full copy of the production database to work against. No more coordinating over who's using the shared dev DB.
Clone production to a temporary database, run your masking/anonymization scripts against the clone, and use the masked copy for safe data sharing.
| Feature | pg_dump / restore | Cloud snapshot restore | Vela CoW clone |
|---|---|---|---|
| Clone creation time (100 GB DB) | 45–90 minutes (pg_dump + restore) | 10–30 min (RDS snapshot restore) | < 30 seconds |
| Additional storage per clone | 100 GB (full copy) | 100 GB (full copy after restore) | Near-zero (shared unchanged blocks) |
| 10 simultaneous clones | ~1 TB additional storage | ~1 TB additional storage | Near-zero additional storage |
| Requires database downtime | No, but high I/O impact | No | No |
| Works with any size database | Yes (but slow at scale) | Yes (but slow at scale) | Yes (speed doesn't scale with size) |
| Scriptable / API-driven | Yes (pg_dump CLI) | Yes (AWS CLI) | Yes (REST API) |
Vela uses copy-on-write (CoW) storage at the block level. When you clone a database, no data is actually copied. The clone and the source share the same underlying storage blocks. When either the clone or the source modifies a block, only that modified block is written separately. This means clone creation is instantaneous regardless of database size — there's no data to transfer.
The terms are often used interchangeably, but in Vela's context: a clone is a full, independent copy of a database — typically used for one-time tasks like migration testing or data masking. A branch is a clone that's managed within Vela's branching workflow — with lifecycle management, CI/CD integration, and the ability to create multiple branches from the same source. All branches are implemented as CoW clones under the hood.
On creation, a clone uses near-zero additional storage because all data blocks are shared with the source. As writes are made to the clone (or to the source after cloning), only the modified blocks require additional storage. A clone of a 100 GB database used purely for read testing might use less than 1 MB of additional storage. A clone used for a migration that touches many rows might use a few GB.
Yes. Vela creates a consistent snapshot of the database at the moment of clone creation without locking the database or pausing traffic. The clone reflects the state of the database at that point in time. Production reads and writes continue normally.
pg_dump serializes all data to a file, which can take 45–90+ minutes for a 100 GB database and requires the same amount of storage again on restore. Vela cloning creates a usable clone in seconds with near-zero additional storage, regardless of database size. For large databases, pg_dump/restore is often impractical for frequent use in CI pipelines.
Try Vela's copy-on-write cloning in the sandbox — no infrastructure to set up.