Databasebasic

Database Seeding

Populating a database with initial or test data to establish a consistent baseline for development, testing, and demonstrations.

Also known as: seed data, test fixtures, initial data loading

Description

Database seeding is the process of inserting a predefined set of data into the database after schema creation. Seeds serve multiple purposes: providing reference data that the application requires to function (countries, currencies, permission roles), establishing a realistic dataset for local development, and creating deterministic test fixtures for integration tests.

Seeds should be idempotent -- running them multiple times should produce the same result. Use upsert operations (INSERT ... ON CONFLICT DO UPDATE) rather than plain inserts to handle re-runs gracefully. Separate reference seeds (required for the app to work) from development seeds (sample data for local development) and test seeds (minimal fixtures for automated tests). Reference seeds should be part of the deployment pipeline; development seeds should be opt-in.

For realistic development data, use libraries like Faker.js to generate plausible names, emails, and addresses rather than using 'test123' values. This catches UI layout issues, encoding problems, and edge cases that artificial data misses. Keep seed data volumes proportional to production -- if production has millions of rows, your development seeds should include at least thousands to surface performance issues early. For integration tests, prefer factories (functions that create individual records on demand) over bulk seeds for better test isolation.

Prompt Snippet

Implement a seed system with three tiers: reference seeds (roles, permissions, config) that run in every environment via the CI pipeline using INSERT ... ON CONFLICT DO NOTHING, development seeds using Faker.js with a fixed random seed (faker.seed(42)) for deterministic output, and test factories using a builder pattern that create minimal records per test. Execute seeds inside a transaction so failures roll back cleanly. Gate development seeds behind a NODE_ENV !== 'production' check to prevent accidental execution.