How Do You Manage Seed Data Across Environments?
Learn how to manage reference and sample seed data across dev, staging, and production with versioned, idempotent scripts.
Expected Interview Answer
Seed data should be managed as versioned, idempotent scripts checked into source control, with a clear split between environment-agnostic reference data needed everywhere and synthetic sample data used only in development and test environments.
Reference data — things like status enums, country codes, or default feature flags — must exist identically in every environment and should ship as part of the migration pipeline itself, applied through upserts so re-running never creates duplicates. Sample or demo data used for local development and automated tests is different: it is often large, fake, and regenerated freely, so it belongs in separate seed scripts or factories that are never run against production. Keeping these two categories separate, versioning both alongside schema migrations, and never hand-editing seed data directly in a database console prevents environments from drifting apart and keeps test fixtures reproducible.
- Reference data stays consistent across dev, staging, and production
- Sample data never accidentally reaches production
- Seed scripts are reproducible and reviewable like any other code
- New environments can be bootstrapped from scratch reliably
AI Mentor Explanation
Think of a cricket board maintaining two different lists: the official rulebook (over limits, dismissal types) that every ground must use identically, and a set of practice-match rosters used only for training academies, never for a real international fixture. The rulebook is versioned and distributed to every venue exactly as written, while the practice rosters are freely rewritten and never touched by the officiating system. Seed data management works the same way: reference data ships everywhere unchanged, and sample data stays confined to non-production environments.
Step-by-Step Explanation
Step 1
Classify the data
Split seed data into reference data (must match everywhere) and sample/demo data (dev and test only).
Step 2
Version reference data with migrations
Ship reference data as idempotent upsert scripts alongside schema migrations, applied to every environment.
Step 3
Isolate sample data generation
Generate sample or demo data through separate seed scripts or factories, gated so they never target production.
Step 4
Automate and review
Run seed scripts through the same CI review and testing process as application code, never hand-edited in a console.
What Interviewer Expects
- Clear distinction between reference/lookup data and sample/demo data
- Understanding that reference data ships via versioned, idempotent scripts
- Awareness of the risk of sample data leaking into production
- Mention of reproducibility for bootstrapping new environments
Common Mistakes
- Treating all seed data as one undifferentiated category
- Manually inserting reference data through a database GUI instead of versioned scripts
- Accidentally running development seed scripts against production
- Not making seed scripts idempotent, causing duplicate rows on re-run
Best Answer (HR Friendly)
“I split seed data into two kinds: small reference tables like status codes that must be identical everywhere and ship as versioned, idempotent scripts with the migrations, and larger sample or demo data used only in development and test, kept in a completely separate script path that is never pointed at production. That separation keeps environments consistent while avoiding fake data ever leaking into production.”
Code Example
-- seeds/001_order_status_reference.sql
-- Safe to run in dev, staging, and production alike
INSERT INTO OrderStatus (status_code, label)
VALUES
('PENDING', 'Pending'),
('SHIPPED', 'Shipped'),
('DELIVERED', 'Delivered'),
('CANCELLED', 'Cancelled')
ON CONFLICT (status_code) DO UPDATE
SET label = EXCLUDED.label;
-- seeds/dev/001_sample_orders.sql (dev/test only, never run in prod)
INSERT INTO Orders (customer_id, status_code, total)
VALUES (9001, 'PENDING', 42.50), (9002, 'SHIPPED', 15.00);Follow-up Questions
- How would you prevent a development seed script from accidentally running in production?
- How do factories in testing frameworks relate to seed data strategy?
- How would you keep synthetic sample data statistically representative of production without using real customer data?
- How do you handle reference data that legitimately differs between regions or tenants?
MCQ Practice
1. What kind of data should be versioned and deployed identically to every environment including production?
Reference data like status codes or country lists must match across every environment, so it ships as versioned scripts applied everywhere.
2. Why should reference data seed scripts be idempotent?
Deploy pipelines can retry a seed step, and an idempotent upsert ensures re-running it converges to the same state instead of duplicating rows.
3. What is the main risk of not separating sample data from reference data scripts?
Without a clear separation and environment gating, development-only sample data scripts risk being run against production by mistake.
Flash Cards
What is reference/lookup seed data? — Small, environment-agnostic data like status codes or country lists that must be identical everywhere.
What is sample/demo seed data? — Synthetic or fake data used for development and testing, never applied to production.
How should reference data be applied? — Through versioned, idempotent upsert scripts run as part of the migration pipeline.
Why keep seed scripts in source control? — So they are reviewable, reproducible, and can bootstrap a new environment reliably.