A staging database that
actually mirrors production

Why traditional staging falls short

Most PostgreSQL staging environments share the same fundamental problems: they drift from production, they're shared between developers causing conflicts, and refreshing them is slow enough that teams just don't bother.

Test migrations against real data before applying to production

Schema migrations are one of the highest-risk operations in any database-backed application. An ALTER TABLE that takes 2 seconds on a 10 GB staging database might take 45 minutes on a 400 GB production database — locking the table the entire time.

With Vela staging environments, you can clone production and test the full migration before applying it to prod:

-- 1. Clone production (done via Vela API or UI — takes < 30 seconds)
-- 2. Connect to the staging clone and run the migration:

BEGIN;

ALTER TABLE orders ADD COLUMN processed_at TIMESTAMPTZ;
UPDATE orders SET processed_at = created_at WHERE status = 'complete';
ALTER TABLE orders ALTER COLUMN processed_at SET NOT NULL;

-- 3. Validate
SELECT COUNT(*) FROM orders WHERE processed_at IS NULL;
-- Should be 0

EXPLAIN ANALYZE SELECT * FROM orders WHERE processed_at > NOW() - INTERVAL '7 days';
-- Check index scan vs seq scan, execution time

COMMIT;

-- 4. If all looks good, apply to production.
-- If not, DELETE the clone and iterate with zero consequence.

• Catch lock contention issues before they block production traffic
• Validate data integrity after migrations on real production data
• Check query performance after index changes with EXPLAIN ANALYZE
• Full rollback if anything looks wrong — just delete the clone