Production lives on Neon

You use Neon to run both production and non-production environments. This is the most common setup for teams that want a fully serverless Postgres workflow leveraging branching to isolate dev, test, and staging environments without duplicating infrastructure.

Single project

Your application has one primary database that serves all users. You manage all your environments (e.g. production, dev, staging, previews) within a single Neon project using branches to isolate workflows.

No PII in production

Not all production databases include personally identifiable information. If this is your case, you can safely use production-like data in non-production environments. Follow this pattern:

1. Use main as your production branch. This holds your live application data and schema.
2. Create a long-lived dev branch, calling it something like main-dev. You’ll use this as the base for all development and testing environments.
3. Derive non-prod environments from main-dev. Examples (see Common branching workflows):
   • dev-alice, dev-bob (per developer)
   • preview-pr-42 (per PR)
   • qa-metrics-test (for testing feature flags, upgrades, etc.)
4. Reset environments regularly. Use branch resets to keep them aligned with main-dev, or delete and recreate branches as needed.

PII in production

If your production database includes sensitive data such as user names and emails, payment or health information, or internal records, then non-prod environments must avoid exposing this data. Here’s a recommended branching architecture for this scenario.

1. Use main as your production branch. This is your live environment, containing real user data.
2. Create a schema-only branch from main. This duplicates only the database structure (tables, views, functions) without copying any sensitive data.
3. Load anonymized data into the schema-only branch. Use Neon’s integration with PostgreSQL Anonymizer, or your own masking scripts, to populate the branch with safe test data that mirrors production shape and scale.
4. Promote this branch as your template for non-prod environments. Name it something like main-anon or dev-anon. This becomes the base for all development, preview, and QA branches.
5. Derive all non-prod environments from main-anon. Examples (see Common branching workflows):
   • dev-alice, dev-bob (per developer)
   • preview-pr-42 (per PR)
   • qa-metrics-test (for load or feature testing)
6. Reset environments regularly. Use branch resets to keep them aligned with main-anon, or delete and recreate branches as needed.

Once this workflow is set up, you only need to maintain main-anon. All other branches, whether created by a developer or a CI job, can be reset, recycled, or deleted without risk. This makes it easy to support many environments without multiplying infrastructure or accidentally leaking sensitive data.

Project per customer

If your architecture provisions a dedicated Neon project for each customer, you’ll need to manage development and testing environments on a per-project basis.

This setup is common for multi-tenant SaaS platforms that offer database-level isolation per customer - for example, platforms handling sensitive or regulated data, or those offering enterprise-grade SLAs with strict data separation.

Here’s how to structure branching in this model:

1. Create a dedicated Neon project for development and testing. This non-prod project serves as the shared workspace for all ephemeral environments.
2. Load testing data into the main branch. This branch holds a sanitized dataset that reflects the structure and scale of production. It acts as the base for all dev/test environments.
3. Derive child branches from main as needed. Examples (see Common branching workflows):
   • dev-alice, dev-bob (per developer)
   • preview-pr-42 (per PR)
   • qa-metrics-test (for load or feature testing)
4. Reset environments regularly. Use branch resets to keep them aligned with main-anon, or delete and recreate branches as needed.