B2B SaaS subscription analytics
Accounts, seats, MRR, churn and support load, where company size actually drives the plan.
A B2B SaaS business with 1,200 customer accounts. Company size follows a power law, so most customers are small and a few are large, and the plan each account is on follows from its size rather than being sprinkled at random. Seats fit the plan, MRR is exactly seats times the plan's price, and nobody licenses more seats than they have employees. Support tickets resolve faster as priority rises.
44,384 rows across 5 tables, 717 KB zipped. Public domain (CC0), no signup, no attribution required.
What is in it
account_id, company_name, industry, country, employee_count, signup_date, plan
user_id, account_id, full_name, role, email
work emails on the company's own domain
subscription_id, account_id, seats, status, mrr, started_on, ended_on
invoice_id, account_id, invoice_date, amount, status
ticket_id, account_id, opened_at, priority, category, satisfaction_score, resolution_hours, resolved_at
What holds, and how it was checked
Each line was measured against these exact files rather than asserted. The same checks ship inside the zip as INTEGRITY.txt, so you can re-run them yourself.
- 0 orphaned foreign keys, exactly one subscription per account
- 0 invoices or tickets dated before the account existed
- mrr equals seats times the plan's seat price, to the cent, for all 1,200
- 0 accounts licensing more seats than they have employees
- Seats rise with plan: 5, 23, 69, 189 median for Starter to Enterprise
- Churned subscriptions all carry an end date; active ones never do
- Median resolution: 4h urgent, 12h high, 34h normal, 77h low
- 8.4% of tickets are still open, and none of those carry a satisfaction score
- All 21,884 user emails are unique
Questions it can answer
- Does support load predict churn?
- What is net revenue retention by plan tier?
- Which industry has the worst satisfaction scores?
- How does seat utilisation vary between Starter and Enterprise?
Make your own version
The zip includes schema.yaml, which is this dataset's shape and runs as-is. Change a row count, add a column, rename a table: every foreign key still resolves, because referential integrity is a guarantee here rather than something the generator happens to get right.
pip install misata misata generate --config schema.yaml --output-dir ./dataRead the docs
Other datasets
- Retail star schema
A dimensional model you can actually practise joins on: one fact table, four dimensions, 63,170 rows, and every join resolving.
- Machine degradation
100 machines monitored from commissioning to failure, with an exact remaining-useful-life label on every one of 23,118 readings.
- Ecommerce storefront
A year of orders across five joined tables, with a real Q4 peak and totals that reconcile to the cent.