Mock Data Generator

Realistic vs. random — and why the difference matters

There's a real gap between random bytes and realistic data, and which you want depends on what you're building. Random is fine for load-testing a column's storage. But the moment a human looks at the output — a demo, a UI screenshot, a stakeholder walkthrough — realism carries its weight: plausibly-formatted names, street addresses that look like addresses, phone numbers that match a country's pattern, emails shaped like real ones. A table full of 'asdf qwerty / x7z2k@k.io / 999999999' makes a polished UI look broken; the same table with 'Sarah Mitchell / s.mitchell@example.com / (503) 555-0142' makes it look shipped. This generator draws from sample-data dictionaries and combines them so the result reads as authentic while being entirely invented.

Realism also surfaces bugs that random data hides. Real names contain apostrophes, hyphens, accents and varying lengths; real addresses have unit numbers and edge-case formats. Layouts that look fine on 'John Smith' break on a long accented hyphenated name — and you only catch that with data that looks like the real world, not seven random characters.

Seeding: the difference between a demo and a test

For demos, fresh random data every run is exactly right. For automated tests, it's a liability — a test that asserts against row 3 will pass or fail depending on what row 3 happened to be this run, which is the definition of a flaky test. Reproducibility is the property tests need: the same input producing the same data every time. The standard way to get it with a faker is a seed — a fixed starting value for the pseudo-random generator, so a given seed always yields an identical dataset. Same seed, same rows, forever; change the seed, get a different-but-equally-reproducible set.

This generator uses a fresh seed on every run (great for demos, wrong for fixtures), so the right pattern for tests is to generate once and commit the output to your repo as a fixture file. Your tests then load the same canned JSON or CSV every run and assertions stay stable. That commit-the-fixture approach is the dominant convention for snapshot and integration testing precisely because it makes the data reproducible regardless of how it was first produced.

The one rule that's non-negotiable: never use real PII

Reaching for a slice of the production users table to 'make the test realistic' is the mistake that becomes an incident. Real personal data — names, emails, phone numbers, addresses, anything identifying — should never land in tests, fixtures, seed scripts, demo environments, CI logs, or screenshots, because every one of those is a copy that escapes the controls protecting the original. Test databases get shared, fixtures get committed to public repos, CI output gets pasted into tickets, demo apps get left running on the open internet. Each is a path for regulated data (GDPR, CCPA, HIPAA) to leak, and 'it was only the test environment' is not a defence anyone has successfully made to a regulator.

Synthetic data removes the problem at the root: a generated 'Sarah Mitchell, 412 Oak Ave, Portland' is not a person at that address, so there is no breach if it leaks, no consent to obtain, and no compliance exposure to manage. That's the entire point of generating mock data rather than borrowing real records — realistic shape, zero real people. Make it a hard rule: production PII never leaves production.

Picking an export format that fits the target

The SQL export deliberately omits CREATE TABLE — column types, constraints and dialect vary too much for a generic schema to be safe. The INSERTs use your exact column names so they slot under your own schema. Need stable IDs across rows? Generate them with the [UUID tool](/utility/uuid/).