Built and run by one person.

What are the limits on the public cricket SQL endpoint, and what do I do when I hit one?

Four limits, and each has an obvious move when you hit it.

Two engines answer the same SQL, and picking the right one is often the whole fix. On big aggregations over the ball-by-ball table DuckDB is faster by a wide margin, and Postgres is the one that runs into the thirty second limit. Point lookups are fine on either. So if a heavy query times out on Postgres, try it on the DuckDB endpoint before you rewrite it.

Write the portable spelling of a percentile. quantile_cont and quantile_disc are the DuckDB spellings and Postgres does not have them. percentile_cont and percentile_disc work on both, so those are the ones to reach for if you want a query that runs on either engine.

The function allow-list grows from what callers actually try. Percentile, quartile and ranking functions went in because they kept turning up as refusals in the logs. If something you need is refused, it is worth asking for.

When a limit genuinely binds, stop fighting it and take the file. The whole database is published and rebuilt twice a day, so a heavy analysis runs locally with no limits at all: the manifest lists every file with its build time and row count, and the download route is described here.

Hub: https://www.tigzig.com/apis/database. The other cricket trap worth reading first is the columns that do not mean what they look like. Full write-up: https://www.tigzig.com/post/cricket-sql-stats-functions-and-limits-sep2026.

Building something like this? How I work covers the rates, the availability and what I take on.

← All Agents FAQ