Yes, and for a lot of work it is the better route. Every TigZig dataset is published as a downloadable file alongside the live API. Free, no signup, no key.
What is available: India mutual fund NAV (the full AMFI master back to 2006, 37 million records), cricket ball-by-ball (men's and women's internationals plus the IPL - Tests, ODIs and T20s from 2001), global macro (300+ indicator series across the US, India, Europe and the OECD), and India red-flag data (related-party transactions, insider trading, pledges, credit ratings and surveillance). Each one comes table by table as Parquet or CSV if you want a slice, or as a single DuckDB or SQLite file if you want the lot.
Cricket is the fullest worked example of this. The entire ball-by-ball database - every table, over 11,000 matches and more than 5 million deliveries from 2001 onwards - is published as files and rebuilt twice a day, alongside the same data as a live SQL endpoint and an MCP server. File list: db-mcp.tigzig.com/downloads; what is in it: the free cricket database.
Which one you want:
- Take the file when you want the whole thing, when you are building your own service on top of it, when you want to work offline, or when you would rather not carry an API dependency and its constraints at all.
- Call the API when you want a small slice of something current, or when you do not want to manage a copy.
If you are scheduling it rather than pulling it by hand, read the manifest first. Every dataset publishes one at /downloads/manifest with the generation timestamp, the size of each file and the row counts. A scheduled job can check that stamp and skip the download entirely when nothing has changed, which turns a nightly transfer into a few hundred bytes on most days. The same timestamp answers "is my copy stale", because the files are rebuilt back to back with the live data.
One thing worth knowing about the formats: where several are offered they are built from the same run and carry identical row counts, so pick the one your stack actually reads. Parquet is smallest and fastest to load, but a compressed CSV you can open beats a Parquet you cannot.
The techniques for pulling a large dataset efficiently - range requests into a remote Parquet file, conditional downloads, what to do instead of a paginated loop - are set out separately in how do I pull a large dataset without hammering the API. If a download is arriving incomplete, that is a different problem with its own page. Catalog: https://www.tigzig.com/apis, or point an agent at api.tigzig.com and ask it for the dataset you want. Full write-up: https://www.tigzig.com/post/tigzig-whole-database-downloads-aug2026.
Building something like this? How I work covers the rates, the availability and what I take on.