What this prompt does
This prompt makes the model act as a senior backend engineer building a staging data generator that returns working code, not pseudocode. Four placeholders tailor it: [orm] (the schema source it reads), [domain] (the application being seeded), [volume] (the target row count), and [pii_fields] (the fields needing fully synthetic values).
The structure works because hand-typed staging data hides the slow queries that only surface at production scale. By requiring a generator that reads the real schema via [orm] so it stays in sync, distributions that mirror production cardinalities (power-law for popular records, realistic null rates), fully synthetic non-reversible PII for [pii_fields], referential integrity across tables in dependency order, configurable [volume], and a CLI with flags for volume, seed, and table subset, the prompt produces prod-shaped data that exposes N+1 and index problems before they reach production. Describing the [domain] accurately lets the generator model the relationships that matter — tenants owning teams owning projects, for instance — so the seeded graph behaves like the real one under load.
When to use it
- Your staging database is a handful of hand-typed rows and slow queries only show up in prod.
- You want a generator that reads the live schema via
[orm]so it stays current as the model changes. - You need distributions that mirror production cardinalities, not uniform random data.
- You must synthesize non-reversible PII for
[pii_fields]without using real data. - You want referential integrity across related tables generated in dependency order.
- You need a CLI with configurable
[volume], a seed, and a table subset.
Example output
Expect the generator code, the CLI entry point, and example command invocations with sample rows. The generator reads the schema through [orm], applies distributions that mirror production cardinalities (power-law for popular records, realistic null rates), produces fully synthetic non-reversible values for [pii_fields], and maintains referential integrity by generating related tables in dependency order. The CLI exposes flags for [volume], a seed for reproducibility, and a table subset, with sample output rows shown for the [domain].
Pro tips
- Mirror the cardinalities in deliverable two honestly — uniform random data hides the N+1 and index problems you most need to catch.
- Keep
[pii_fields]fully synthetic and non-reversible; never use real or hashed-real data even in staging. - Use the seed flag for reproducible runs so a performance issue you find can be regenerated exactly.
- Set
[volume]to two profiles: a small dev set for quick iteration and a large set for performance-stress testing. - Let the generator read the schema via
[orm]rather than hardcoding columns, so it stays in sync as[domain]evolves. - Generate tables in dependency order so foreign keys always resolve; seeding children before parents is a common source of integrity errors.
- Start with a small subset via the CLI to sanity-check sample rows before committing to a full
[volume]run that takes time to produce.
