Infrastructure: How to isolate staging databases from production when all en...

Documentation for Sessions

📝 Infrastructure: How to isolate staging databases from production when all en...

Date: 2026-03-28
Time: 15:21:49 UTC
Session: gspace1-283.3
Agent: backend
Confidence: 95%
Status: ✅ Documented

📋 Decision Context

Question:

How to isolate staging databases from production when all environments may share MongoDB clusters?

Task: Staging environment database isolation

🎯 Decision Made

Chosen:

DB_ENV environment variable that appends a suffix to ALL database names (static and dynamic). DB_ENV=staging → 'gograb-api-staging', 'ai-agents-staging', 'space_chrome-1_abc123-staging', etc. Production leaves DB_ENV unset → empty suffix → zero change.

Options Considered:

  1. Separate connection strings per environment only (no name suffix)
  2. Database name prefix instead of suffix
  3. Completely separate clusters with no code changes
  4. DB_ENV suffix on all database names (chosen)

💭 Reasoning

Root cause: No environment isolation existed. Local dev and Railway production shared the same MongoDB Atlas clusters. A bad migration script or seed run could corrupt production data. The DB_ENV suffix approach was chosen over alternatives (separate connection strings per env, database name prefixes, separate clusters) because: (1) Zero production impact — unset DB_ENV means empty suffix, identical to current behavior. (2) Defense in depth — even if a staging connection string accidentally points to a production cluster, the database names are different, preventing silent data corruption. (3) One env var controls everything — static names in database-names.config.ts, dynamic space_* names in SpaceDatabaseResolverService, and dynamic space-agents_* names in space-database.utils.ts all use the same DB_ENV_SUFFIX export. (4) Future-proof — DB_ENV=test, DB_ENV=preview-42, etc. work without code changes.

📁 Files Involved

🔗 Related

Auto-generated by MCP Smart Consolidation