Is there a free cricket database I can query with SQL or point my AI at?

Yes. TigZig runs an open, read-only SQL endpoint over ball-by-ball cricket - men's and women's internationals plus the IPL - across ODI, T20 and Test. Roughly five million deliveries across about 11,000 matches, going back to December 2001. Free, no signup and no key, refreshed twice a day.

The whole database is published, not just an API over it. Three ways to take it, all free, no signup and no key:

• Download it by hand. Every table as Parquet or CSV, or the entire database as one DuckDB or SQLite file: db-mcp.tigzig.com/downloads.
• Download it by API. The same files over one plain GET, so a script or a scheduled job keeps its own copy current.
• Query it where it sits. Read-only SQL over Postgres or DuckDB, plus an MCP server so an agent writes the queries itself.

Rebuilt twice a day, so whichever route you take the data is current rather than a one-off snapshot.

The shape of it. One table of every delivery - ball_by_ball, with gender and team_type to filter on - plus seven ready-made slices of it (by format and gender, plus the IPL), and match_info, match_players and people, all joined on match_id. match_info carries venue, dates, teams, toss and result, so you can slice by any of those without pulling in a second source. That is what makes the ball-by-ball useful rather than merely large: strike rate against pace versus spin, run rates through the death overs, a head-to-head across a decade, or how a particular venue behaves batting first.

Two ways in. Write the SQL yourself against the REST endpoint, or connect it as an MCP server and let an agent write the queries. There is also a third route that needs no setup at all: point an AI with web access at db-mcp.tigzig.com and ask it about the cricket database. That address returns a plain JSON index - the agent reads it, finds the SQL endpoints, the OpenAPI spec and the download files, and works out the rest on its own, so you never have to explain the API. api.tigzig.com is the catalog one level up and works the same way if you do not know which service holds the data.

Whether your own AI can do this comes down to two capabilities. To query it over the API, the tool needs to fetch a URL. To take the file and work on it locally, it also needs to run code, either on your machine or in a sandbox. Full coding agents do both without fuss. The desktop and chat apps keep moving on this - sandboxes appear, tiers split and recombine - so ask your own tool what it can do today rather than trusting any list, including this one.

Fighting the row cap? Take the file instead. A download has no row cap, no rate limit and no query-length cap, so anything that scans the whole table is better done locally.

The player tables, added September 2026. match_players carries the playing XI, teams and match officials for every game, and people is a player registry that maps each identifier to an ESPN Cricinfo ID, which is what lets you join this data to anything else keyed on Cricinfo. Window functions and list aggregations work on both engines - dense_rank, lag, lead, string_agg, array_agg - so ranking and running-total work happens in the query rather than in your own code.

Three things to know before you query. The two engines are different SQL dialects, so a query that runs on one can fail on the other. There is a row cap - past it you get the first batch plus truncated: true, so always read that field, and setting your own LIMIT is faster and gives you a clean false as proof. And if your query fails, suspect the URL before the SQL: percent-encoding mangles queries sent over GET, which is the commonest failure by far.

Credit, because it is a condition of use: the data comes from Cricsheet under the Open Data Commons Attribution License 1.0 (ODC-BY). If you publish anything built on it, credit Cricsheet and make the licence clear. Docs: https://www.tigzig.com/apis/database. Need a competition outside this set, such as county cricket or the Big Bash? Converting the raw Cricsheet files yourself.