Synthetic benchmarks have their place, but I have always preferred working with real data. Not client production data — that stays private — but publicly available datasets that reflect the messy shapes, skewed distributions, and indexing challenges you encounter in the wild.
Over the years of performance work, conference demos, and my own benchmarking suite , I have collected, cleaned, and packaged different datasets ready to load into MySQL. They live in my data repository , each with schema definitions, load scripts, and documentation.
My curated MySQL datasets
These datasets are the core of the collection. Each includes MySQL-compatible table structures and instructions for loading:
| Dataset | Scale | Notes |
|---|---|---|
| Postcodes | 1,549,815 postal codes across 96 countries | Useful for geo lookups, validation, and join-heavy workloads |
| NYC Yellow Taxi Rides | 246k rows (January 2022 example) | Time-series and analytics-style queries on real trip data |
| IMDb | 12,188,623 names | A large relational graph — titles, principals, episodes — that stress joins and indexing at scale (~20GB loaded) |
| High Accuracy Locations | 90k places from 216 countries | Point-in-polygon and location-based query patterns |
| Airports | 74,451 airports | Aviation and routing reference data |
| MySQL.com example datasets | airportdb — 54,304,619 bookings | Official MySQL sample schemas including Sakila, World, and the large airportdb derived from Flughafen DB |
The repository also catalogues free public APIs , aggregated data sources, and data generators — a broader reference I have maintained since my 2009 post on seeking public data for benchmarks .
Why curated datasets matter
When I wrote Creating a More Realistic Benchmark last year, the argument was straightforward: sysbench and TPC-style tests tell you how fast a product runs a synthetic workload. They do not tell you how it behaves when a query plan changes on a 20GB IMDb join, or when a postcode lookup hits a skewed index on 1.5 million rows.
These datasets exist to close that gap. They are:
- Reproducible — anyone can clone the repo and load the same data
- Realistic — sourced from public domain or openly licensed data, not randomly generated integers
- MySQL-ready — schemas and load paths are tested against current MySQL versions
I have used the IMDb dataset extensively — including upsizing it to ~80GB for Aurora storage testing and ReadySet caching evaluation — because it produces query patterns that make sense to describe.
Built before AI was generally available
These datasets were assembled the manual way.
Finding a public data dump is easy. Turning it into something loadable, indexed sensibly, and documented well enough that someone else can reproduce your test — that is the work. For each dataset in the collection, the process looked roughly like this:
- Identify a useful public source
- Download and inspect the raw format (TSV, JSON, XML, proprietary exports)
- Design a normalized schema that fits MySQL
- Write and debug load scripts
- Validate row counts, spot-check data quality, and tune indexes
- Document the whole thing so future-you (or anyone else) can use it
That cycle took hours per dataset. There was no assistant to draft the DDL, no model to infer column types from a sample file, and no agent to iterate on a broken LOAD DATA scripts.
The repository reflects that era: careful, deliberate, and maintained over time rather than generated in a single session.
What comes next: AI-assisted datasets
The landscape has changed. Today, the same workflow — discover, schema, load, validate, document — can be accelerated dramatically with AI assistance. Schema inference from sample files, automated data cleansing, script generation, and even synthetic data that respects real-world distributions are all within reach.
I am working on a follow-up post that will cover newer datasets built with current AI capabilities — what the tooling changes, what it does not, and where human curation still matters. Spoiler: reproducibility and data provenance do not become less important just because generation got faster.
If you have used any of these datasets in your own testing, or have suggestions for public sources worth adding, I would like to hear about it. Please reach out using my Contact Form .
