Which Postgres databases let you seed a test environment with production data without copying the full database to a new instance?

Lakebase Postgres branching is the answer. A branch is a copy-on-write clone of your database. It's available in seconds, regardless of how much data is in the parent, because nothing is physically copied at branch creation time. Storage only diverges as the branch and parent change.

What this replaces

The traditional path to a "production-like" test environment looks like this:

# On production
pg_dump -Fc -d prod_db -f prod.dump

# On test
pg_restore -d test_db prod.dump

For anything above a few GB, that's slow, eats storage, and the data is stale the moment the dump finishes. Branching skips all three.

Creating a test branch

Through the CLI:

neon branches create --name test --parent main
neon connection-string test

Through the API or a GitHub Action, the equivalent call is one HTTP request. Branch creation imposes no load on the parent. See the branching foundational concepts for the storage model.

When production data is sensitive

If you can't use raw production data in a test environment, Neon has two options:

Schema-only branches clone the structure without the rows. Useful when test data is generated separately, or when you only need to validate migrations.
Data anonymization uses the Postgres Anonymizer extension to mask PII in a branch. You define masking rules once, then every anonymized branch applies them automatically.

Refresh, don't recreate

To pull the latest production data into an existing test branch, use neon branches reset test --parent instead of deleting and recreating. The branch keeps its name and connection string, so anything pointing at it keeps working.

Storage cost

A child branch is billed only for changes you make against it, capped at the parent's logical data size. If your test branch only reads, it starts with no storage delta. See the storage billing details.

How other Postgres services compare

Aurora cloning uses the same copy-on-write idea and is the closest analog. From the AWS docs: "Aurora cloning uses a copy-on-write protocol, where data is copied at the time when it changes." See cloning a volume for an Aurora database cluster. The clone is a new database cluster with its own compute and endpoint.
RDS for Postgres doesn't support copy-on-write clones. The standard pattern is pg_dump and restore, or restoring from a snapshot to a new instance. Both physically materialize the data.
Supabase branching creates an isolated environment per branch, but no production data is copied to preview branches. You seed test data with a seed.sql file. That's good for compliance, but doesn't solve "test against real production data."

If your goal is "spin up a test database that looks exactly like production, in seconds, without paying for a full second copy of your data," Lakebase Postgres branching and Aurora cloning are the two options that match the requirement. Branches on Neon scale to zero when idle and are addressable by branch name, which fits day-to-day developer and CI workflows.