For product teams
The empty dashboard is killing your trials.
A new user signs up, lands on a screen with nothing in it, and is asked to imagine what the product would feel like with their data in it. Most of them do not bother. The empty state is the most under-engineered screen in most products, and it quietly does more damage than any feature you could ship this month.
The fix everyone recommends is the same: seed the account with sample data so the first screen shows the product working. The reason teams skip it is that generating believable, connected data for your real schema is genuinely annoying, and it is never the most interesting thing on the roadmap.
Why the usual approaches fail
Copy a slice of production
Real customer data on a laptop, and a compliance problem you now own.
A hand-written seed script
Rots on every migration, and the numbers stop making sense as the schema grows.
Faker in a loop
Names look fine, but orders point at customers that do not exist, so the first JOIN breaks the demo.
Ask an LLM for rows
Plausible-looking values that miss the distributions, and referential integrity falls apart past a few tables.
What Misata does instead
Reads your own schema
Point it at your dev database. It takes the tables, columns, and foreign keys from the database itself, so it stays correct as your schema changes.
Every foreign key resolves
Parents insert before children, and it queries the database afterwards to prove zero orphans. Your demo dashboard never renders an empty panel because a join missed.
The numbers tell the story you want
Declare the outcome, for example revenue climbing to a specific figure by December, and the rows are generated to hit it exactly. Demos should show a good quarter on purpose.
Identical for every account
Generation is deterministic from a seed, so every sandbox account looks the same and a demo you rehearsed does not drift the next morning.
No production data, ever
It generates rather than copies, so there is no real customer row to leak and nothing to scrub.
It is one command
Point it at the database you already have. It reads the schema, fills the empty tables, and then checks the database that every foreign key resolved.
pip install "misata[db]" misata seed postgresql://localhost/myapp_dev --dry-run # see the plan first misata seed postgresql://localhost/myapp_dev ✓ accounts — 200 rows ✓ users — 1,240 rows ✓ invoices — 4,800 rows 🔎 Verifying foreign keys against the database… ✓ users.account_id → accounts.id — 0 orphan(s) ✓ invoices.account_id → accounts.id — 0 orphan(s) ✓ Every foreign key resolves in the database.
Already have real rows in some tables, like an auth table you do not want touched? --append leaves them alone and points the new rows at the accounts that are already there.
Want me to build your demo dataset with you?
Send me your schema, or just describe what a good demo account should contain, and I will shape it and hand it back. I am the person who builds Misata, so you get a real answer rather than a support queue.
Misata generates data, it does not copy or anonymise yours. Production is never read, so there is no real customer record to expose. If you specifically need production shape rather than realistic shape, an anonymisation tool is the honest recommendation instead.