Technology1 min read

Lakebase branching for CI/CD: lessons from 100 PR databases

By · Published by Everything Blog

In short

Previously, restoring Snorkel AI's Amazon Aurora PostgreSQL production database for pull request environments created significant delays and testing friction. The company now continuously replicates its production data into Lakebase using AWS Database Migration Service to keep it within two minutes of live operations. Whenever a pull request triggers, Lakebase generates an isolated, writable copy-on-write branch in under a minute. These disposable database branches scale compute to zero when idle and automatically delete after tests conclude or PRs close.

Key points

  • Isolated copy-on-write branches prevent test interference and stale schema issues common…: Isolated copy-on-write branches prevent test interference and stale schema issues common to shared staging environments.
  • Storage footprints remain minimal because each branch only tracks between 5 and 10 GB of…: Storage footprints remain minimal because each branch only tracks between 5 and 10 GB of individual data modifications.
  • Automated deletion upon pull request closure paired with idle scale-to-zero compute keeps…: Automated deletion upon pull request closure paired with idle scale-to-zero compute keeps resource usage strictly controlled.

Sources checked by our analysis pipeline: 1

Copy-on-write branching makes isolated copies of production data fast and cheap for CI/CD testing and agentic use cases.

by Yasamin Tari and Kartik Mathur

Snorkel AI builds data development tools for AI teams, used by expert data annotators and frontier model providers. In this specific use case, Snorkel ships code through a CI pipeline built on Kubernetes. Every open pull request, plus ad-hoc commits, gets its own ephemeral Kubernetes namespace (a "PR namespace"). Developers deploy their branch there and run the full test suite before merging.

These tests are most useful when they run against real data. Snorkel's production database is an Amazon Aurora PostgreSQL cluster. Giving each PR namespace its own copy of that database was the hard part. Restoring a copy took about 20 minutes per environment, which is too slow when developers open PRs all day and the merge queue needs a fresh environment for each run. The alternatives (shared staging databases, trimmed fixtures, or synthetic data) bring back the problems production-like testing is supposed to solve: tests interfering with each other, stale schemas, and bugs that…

Technology