A demo database should tell a believable story: customers return, popular products sell repeatedly, and a few orders need attention. Random strings and evenly distributed numbers rarely achieve that. This walkthrough builds a synthetic storefront dataset that supports convincing demos without copying customer records.
1. Define the demo scenes before counting rows
Start with the screens you need to demonstrate. For a storefront, choose a customer profile, an order dashboard, a product report, and a refund workflow. Each scene needs supporting records, not just populated tables.
Set a manageable target: 200 customers, 30 products, and 1,000 orders across a fixed six-month window. Write down three stories the data must support: a repeat buyer, a seasonal sales increase, and a refunded purchase. Reserve explicit fixtures for these stories so random sampling cannot accidentally remove them.
2. Turn the schema into a generation contract
List the fields, relationships, and business rules before asking a model to generate anything. Use four core tables: customers, products, orders, and order_items. Keep refunds on orders for this demo, with a refund amount and timestamp.
- Customers: unique identifiers, synthetic names, unique email addresses, and account creation timestamps.
- Products: stable identifiers, categories, prices in integer cents, and active flags.
- Orders: valid customer references, status, placement timestamp, captured amount, and refund fields.
- Order items: valid order and product references, positive quantities, and purchase-time unit prices.
Specify that order totals equal the sum of their line items. For simplicity, exclude taxes, shipping, and discounts. State that explicitly rather than letting different generators invent incompatible accounting rules.
3. Use a model for believable variety, not identifiers
Ask a model for product descriptions, fictional customer personas, and plausible shopping patterns. Generate primary keys, foreign keys, money calculations, and timestamps in code. This separates creative variation from rules that must always hold.
SwiftRelay is useful here if your seed script already uses an OpenAI-compatible SDK. Set its base URL to https://api.fastapirelay.com/v1 and configure a supported model, such as Gemini 2.5 Flash, using its available API identifier. Sign up for SwiftRelay to use the small gift credit for an initial generation run; usage is billed per token.
Give the model a narrow request: Generate 30 fictional household products as JSON objects with name, category, and a one-sentence description. Use only the supplied categories. Do not include brands, prices, identifiers, or real personal information. Validate the response before accepting it.
4. Encode customer behavior with weighted sampling
Use a seeded pseudorandom generator, such as seed 42, for repeatable sampling. Make some customers frequent buyers and others occasional shoppers. Weight product selection so a handful of products become bestsellers instead of giving every product equal sales.
Choose explicit distributions for order size and status. For example, favor one-item and two-item orders, with fewer larger baskets. Allocate most orders to completed purchases and smaller groups to pending, canceled, and refunded states. These are demo assumptions, not claims about actual commerce behavior.
5. Build records in dependency and time order
Create customers and products first, then orders and their items. Generate each order timestamp after its customer's account creation date. Store purchase-time prices on order items so later catalog changes do not rewrite historical totals.
Calculate captured amounts from status: pending and canceled orders capture nothing; completed and refunded orders capture the full total. For this simplified dataset, refunds are full refunds only. Give refunded orders a refund timestamp after purchase and no later than the dataset's fixed cutoff.
6. Validate the dataset before loading it
Reject duplicate identifiers, missing references, empty item lists, invalid statuses, and negative amounts. Recalculate every order total independently. Check that refunds never exceed captured amounts and that timestamps follow the required sequence.
Also test the demo stories directly: confirm the repeat buyer has several purchases, the seasonal window contains the intended increase, and the refund fixture appears in the relevant query. Structural validity alone does not guarantee a useful demo.
7. Package a repeatable database reset
Load validated records inside a transaction and restrict the loader to a dedicated demo database. Require an explicit environment check before deleting existing rows. Save the seed, generation settings, schema version, and validated model output alongside the fixtures.
A random seed does not make fresh model responses deterministic. Reuse the saved output when rebuilding the same demo, and regenerate it only as an intentional dataset revision. Finish with a smoke test of the four demo screens.