Database branching for CI/CD
Run every CI/CD pipeline against a fresh, production-identical Postgres branch. Ardent creates copy-on-write database clones in under 6 seconds — catch migration failures, constraint violations, and data bugs before they reach production.
CI tests pass, production migrations fail
Most CI/CD pipelines test migrations against empty databases or small seed datasets. These environments miss the edge cases that exist in production: orphaned foreign keys, data that violates new constraints, indexes that fail on real data volumes, and triggers that interact with existing rows.
The gap between CI test databases and production is where bugs hide — and it's the hardest gap to close because duplicating production databases is slow, expensive, and risky.
How Ardent solves this
Ardent creates a fresh branch of your production database for every CI run. Each branch is a full copy-on-write clone: same schemas, same data, same constraints, same indexes. Branches create in under 6 seconds regardless of database size, so they don't slow down your pipeline.
Your CI job creates a branch, runs migrations against it, executes integration tests, and deletes the branch on cleanup. If a migration fails on the branch, it would have failed in production — and you caught it before deployment.
Branches use copy-on-write storage, so you only pay for the changes each CI run makes. Running 50 branches per day against a 200 GB database costs a fraction of maintaining 50 staging environments.
# Setup (run once in CI config):
# npm install -g ardent-cli
# In your GitHub Actions workflow:
- name: Create test database branch
run: |
ardent login --api-key ${ARDENT_API_KEY}
ardent branch create ci-${GITHUB_SHA::8}
# ✓ Branch created in 5.4s
# postgres://branch-ci-a1b2c3d4.db.tryardent.com:5432/mydb
- name: Run migrations
run: npm run db:migrate
- name: Run integration tests
run: npm test -- --integration
- name: Cleanup branch
if: always()
run: ardent branch delete ci-${GITHUB_SHA::8}What makes this work
Production-identical test data
Every CI run tests against real production data. No seed scripts, no synthetic datasets, no drift between test and production environments.
Sub-6-second provisioning
Branches create in under 6 seconds regardless of database size. A 1 TB database provisions as fast as a 1 GB one — no pipeline slowdowns.
Parallel pipeline support
Each branch is fully isolated. Run 10 CI jobs in parallel, each with its own database branch. No shared state, no flaky tests from concurrent mutations.
Scale-to-zero compute
Branch compute autoscales to zero when idle and resumes instantly — near-zero first-query latency, no cold start. Between CI runs, branches cost nothing. No always-on staging servers.
Traditional approach vs. Ardent
Frequently asked questions
How does database branching improve CI/CD pipelines?
Database branching gives every CI run a fresh, production-identical database. Migrations run against real schemas, constraints, and data — catching failures that empty test databases miss. Branches create in under 6 seconds, so they don't slow down your pipeline.
Can I create a database branch in GitHub Actions?
Yes. Install ardent-cli in your workflow, authenticate with an API key, create a branch at the start of the job, run your migrations and tests, then delete the branch on cleanup. The entire process adds under 10 seconds to your pipeline.
How does Ardent compare to Docker containers for CI testing?
Docker containers use empty databases with seed scripts that drift from production. Ardent branches are copy-on-write clones of your actual production database — same schemas, same data, same constraints. They also create in under 6 seconds vs. minutes for Docker + large datasets.
What CI platforms does Ardent work with?
Ardent works with any CI platform that can run CLI commands: GitHub Actions, GitLab CI, CircleCI, Jenkins, Buildkite, and others. The Ardent CLI is a standard npm package.