“Random” and “realistic” are treated as the same requirement in most seed scripts, and they pull in opposite directions. Knowing which one a given test needs is the difference between a fixture that finds bugs and one that just fills rows.
Last updated: 30 August 2026 · Tools SoShareIT editorial team
The actual difference
Random data is drawn without regard to what came before. Realistic data has the statistical shape of the real thing — the same distribution, the same clustering, the same awkward long tail.
A randomly generated postcode set spreads evenly across every valid code. A realistic one concentrates where people actually live, includes a few codes far more often than the rest, and has the lopsided shape that makes indexes and caches behave the way they will in production.
Neither is better. They answer different questions, and the cost of picking wrong is a test that passes for a reason unrelated to whether the code works.
When random is correct
Random wins whenever you are testing whether something handles a value rather than how it performs across many.
Validation logic is the clearest case. A regex either accepts the format or it does not, and feeding it a realistic distribution just means testing the common case repeatedly while the rare formats — the ones that break it — barely appear. Uniform random coverage across the format space is what you want, plus deliberately chosen edge cases.
The same applies to round-trip tests, encoding checks and column-limit checks. You are asking “does this survive”, and the answer does not depend on how often the value occurs in the wild.
When realistic is correct
Realistic wins whenever behaviour depends on the shape of the whole set rather than on any single row.
Query performance is the obvious one. An index on a uniformly random column behaves nothing like an index on a real one, because real data clusters — and clustering is what determines whether a query plan uses the index or gives up on it. A staging database seeded uniformly will happily report that a query is fast, right up until production disagrees.
Caching has the same property. A uniform key distribution produces a hit rate that means nothing, because real traffic is concentrated: a small number of keys account for most requests, which is the entire premise of caching. Test a cache with uniform random keys and you have measured a system nobody will ever run.
Anything involving aggregation, sorting or pagination sits in the same category. Sums, averages and page boundaries are all properties of the distribution, not of individual rows.
The third kind nobody plans for
There is a third category that both of the above miss, and it is where most production bugs actually live: the deliberately awkward row.
A postcode with a leading zero that an integer column silently eats. A name at exactly the column limit. An address with accented characters that survives the insert and breaks the CSV export. A country with no postal code at all. None of these appear reliably in random data, and in realistic data they are rare enough to miss on any given run.
They belong in a small, fixed, hand-written fixture that is checked into the repository and never regenerated — the regression suite. Every bug you fix adds a row. That file, not the bulk data, is what stops the same bug arriving twice.
Choosing, in one table
Swipe the table sideways to see every column.
| What you are testing | Use | Because |
|---|---|---|
| Field validation | Random + fixed edge cases | You need format coverage, not frequency |
| Query and index performance | Realistic distribution | Uniform data makes every plan look fine |
| Cache hit rates | Realistic distribution | Caching only works because traffic is skewed |
| UI layout and truncation | Fixed edge cases | You need the longest value, not an average one |
| Encoding round-trips | Fixed edge cases | The characters that break things are specific |
| Load and volume | Realistic, at real scale | Volume without shape tests the wrong bottleneck |
Most teams need all three and build only one. If you are starting from nothing, the fixed edge-case fixture is the one to write first — it is the smallest, it is the one that catches repeat bugs, and it is the only one that gets better every time something breaks.
For the random component, the generator on Tools SoShareIT produces format-correct postal codes for 15 countries, and the reference tables give you the state-by-state ranges you need if you are building the realistic set by hand. If you are wiring this into a staging environment, the practical steps are in our guide to seeding a staging database.
Frequently asked questions
What is the difference between random and realistic test data?
Random data is drawn without regard to what came before, spreading evenly across the possible values. Realistic data reproduces the statistical shape of the real thing — the clustering, the skew, the long tail. Neither is better; they answer different questions, and picking wrong gives you a test that passes for the wrong reason.
Which should I use for validation tests?
Random, plus a fixed set of edge cases. A regex either accepts a format or it does not, and a realistic distribution just means testing the common case repeatedly while the rare formats that actually break it barely appear.
Why do my queries slow down in production but not staging?
Almost always a uniform seed. An index on a uniformly random column behaves nothing like one on real data, because real data clusters — and clustering is what decides whether the planner uses the index or gives up on it. Uniform staging data will happily report that a query is fast.
Can I test a cache with random keys?
You can run the test; the hit rate it reports is meaningless. Caching works precisely because real traffic is concentrated on a small number of keys. Uniform random keys measure a system nobody will ever operate.
What is the one fixture worth building first?
The fixed edge-case set. It is the smallest, it catches repeat bugs, and it is the only one that improves every time something breaks — each fix adds a row. Bulk random and realistic data can come later; the regression fixture pays for itself immediately.