Anvil

Anvil brings Git-style branching to Postgres, giving AI coding agents instant, isolated copies of your live database to safely test and build against, without ever touching production.

Comment

Inspiration

We kept running into the same wall. Coding agents are good at writing code now, but the moment that code touches a real database, one bad migration or a careless query can corrupt live data or open a security hole. We felt this ourselves, then went and validated it: we talked to other startups and businesses to pin down the exact pain point. The pattern was consistent. Everyone wanted agents to move fast, but nobody could safely let them run against production data. What people actually needed was a safe environment to test against real data, and that insight shaped our whole MVP.

What it does

Anvil connects to your existing Postgres and gives coding agents disposable, isolated branches of your real data. Using copy-on-write, a branch spins up in seconds, the agent runs migrations, debugging, CI, or backfills against it, and then you drop it when you're done. Production is never touched.

The core idea in one line:

$$ \text{branch} = \text{real data} \;-\; \text{risk to production} $$

How we built it

We started narrow: validate before building. Customer conversations narrowed the problem to one specific pain point, which kept the MVP focused instead of sprawling. From there we built a functional prototype using ZFS snapshots and clones to give each agent a copy-on-write branch of the source Postgres database, so a branch is near-instant to create and cheap to throw away instead of a full duplicate of the dataset. Changes captured through Postgres logical replication flow into an event log, so branches stay grounded in real data.

Alongside the product we shipped the pieces a real launch needs: our website went live, we produced a demo, and we ran market-insight campaigns on X and LinkedIn to test messaging and pull in signal from prospective users. We're now refining toward an early-tester rollout and lining up design partners.

What we learned

  • Validate the specific pain, not the general idea. "Agents are risky with data" is too broad to build on; "agents need an isolated copy of real data to test against" is a product.
  • Talking to other founders early saved us from building the wrong thing.
  • Copy-on-write is what makes the safety guarantee practical. Without cheap, disposable branches, "just use a copy" doesn't scale.

Challenges we faced

  • Making branches genuinely fast and cheap while keeping them fully isolated. Copy-on-write is elegant in theory but has real edge cases at scale.
  • Guaranteeing production is never touched, which is a trust problem as much as an engineering one.
  • Narrowing from a big, appealing vision down to a sharp MVP that solves one thing well.
  • Ensuring continual update of database from source
  • Defining the boundaries for branch status management across the lifecycle, such as stale, live, archive and more - and more specifically - balancing the user need and cost of maintaining branching for all users on our servers.

What's next

Early-tester rollout, securing design partners, and hardening the branching layer based on real usage.

Built With

Share this project:

Updates

Submission history