How we approach database seeding
By Admin User
There are two ways to fill a demo database: insert the finished rows, or replay the actions that produce them. The difference shows up the first time somebody asks "what happens if I click this?"
Rows lie convincingly
A row can be inserted in a state no code path would ever produce -- a payment that was never charged, a subscription with no customer. It looks right on the dashboard and falls over the moment a real action touches it.
Replay instead
The demo data here is a schedule of events -- sign-ups, checkouts, renewals, refunds -- sorted by time and replayed through the same actions the app uses. If the app has a bug in a renewal, the seeder hits it too.
Deterministic, and idempotent
The random draws are seeded, so the same demo comes out the same every time. And a re-seed checks whether the data already exists before writing anything, so a redeploy never resets an operator's edits.
The rule we ended with
If a seeder needs to know something the application itself does not know, the seeder is wrong. Delete the shortcut and call the real code.
