Staging uses separate database with test data

A staging environment connected to the production database is not a staging environment — it is a second production environment with weaker access controls. Bugs discovered during staging testing can corrupt, delete, or expose real user data. Developers routinely write aggressive cleanup scripts, run schema migrations, and insert test data in staging, assuming isolation that doesn't exist. NIST SC-7 requires boundary protection between system components. OWASP A05 flags misconfiguration that allows unintended data access. A staging breach that exposes a shared database URL puts the production database password in the attacker's hands.

Provision a completely separate database for staging with its own credentials, host, and data. Never copy production data to staging — generate synthetic or anonymized test data instead.

# .env.staging
DATABASE_URL=postgresql://user:stagingpass@staging-db.internal/app_staging

# .env.production
DATABASE_URL=postgresql://user:prodpass@prod-db.internal/app_prod

For seeding, use a dedicated script that inserts synthetic records:

npm run db:seed:staging  # inserts test users, orders, etc. — no real data

Verify isolation by confirming that the staging DATABASE_URL host does not appear in any production configuration file.