For databases with an audience
Describe your domain once. Hose backfills your database with years of believable history — regulars who order every morning, a long tail who never came back, weekends that dip and Decembers that spike — then keeps writing new rows while you present. Reload the dashboard mid-call and the numbers have moved.
The trouble with demo data
They know what a retention curve is supposed to do. Random-row generators give you columns without a business — no regulars, no churn, no cause and effect, every trend a flat line. Static demo datasets go stale the day you load them and reshuffle every id when you regenerate. A copy of production is a compliance problem with a screen-share button. So the moment someone on the call asks a real question, you end up steering the demo away from the data instead of through it.
What you get instead
The first pass backfills as much history as you ask for, as fast as the machine will go, then rolls into real time without a seam. Orders keep landing while your screen is shared: the dashboard moves, the today column climbs, and nobody has to imagine what live would look like.
Populations behave like populations. A few regulars carry most of the revenue, most customers come once and never return, retention decays and then flattens the way real cohorts do. Whatever the person on the call asks you to group by, the shapes are the ones they see in their own data.
Ids are hashes of their own causal history, so referential integrity holds by construction, not by cleanup. Click from a chart to an order to the customer who placed it and someone is there — no orphan rows, no empty joins, no dead end with an audience watching.
Same seed, same database, byte for byte. The run you rehearsed against on Tuesday is the run you present on Thursday, the screenshots in the deck stay true, and the recording you keep as a backup matches the live demo it stands in for.
Every id, timestamp and attribute is a pure function of the seed and an event's lineage. Edit one corner of your domain and the rest of the data stays put instead of reshuffling. Kill the container mid-write and restart it — the database ends up identical to one that was never interrupted.
A coffee chain ships in the box and a railcar fleet runs on it, but neither is the point. Yours is a short description of what happens in your business and what causes what — written once, kept next to your own code, with no second language to learn.
Point it at Postgres, give it a start date, and let it run. A few minutes later you have a database that looks three years into production and is still moving when the call starts — ready for Metabase, Grafana, dbt or whatever your demo runs on. Prefer a file? The same universe lands in SQLite, CSV or JSONL — same rows, same joins.