A workflow I keep coming back to: point Claude at a folder, get it into DuckDB, and let SQL do the heavy lifting instead of the context window.
The whole thing rests on one idea: don't make Claude read the data. Large datasets and large language models are a bad financial match — every row you pour into the context window costs tokens, and it adds up frighteningly fast. So instead of loading the data into Claude, I load it into a database and let Claude query it. Claude reads the shape of the data and the results of questions, not the millions of rows in between.
Here's the flow.
Nothing clever here. Get all the files into one folder — CSVs, Parquet, whatever the source hands you. Keep it tidy, because the folder is the thing you're going to point Claude at.
Usually I do this on the command line, from inside the folder, so Claude can see the files directly. That way it can list them, peek at headers, and check row counts itself rather than me describing everything.
This is the key step. I tell Claude to spin up a project using DuckDB and load the files into it. DuckDB is built exactly for this — fast analytical queries over big local files, no server to run, reads CSV and Parquet natively.
It doesn't have to be DuckDB, though. That's just what I've settled on. SQLite works fine, and if you already run Postgres or query Parquet with something else, use that. The point isn't the specific tool — it's getting the data into something Claude can query with SQL instead of reading row by row. DuckDB is simply the one that's given me the least friction for local files.
Two things it buys me. Queries get much faster than repeatedly parsing raw files. And, more importantly, it kills the need to load the data into Claude at all — Claude writes SQL, the database returns a small result, and only that result comes back into the conversation. That's the difference between a cheap session and an eye-watering one.
Claude can often infer the relationships between files on its own. But it's usually safer to spend a few minutes spelling them out — which column joins to which, which files are just lookup/reference tables, where the keys live.
This matters most with messy real-world data. NHS prescribing data is the example I always hit: the main prescription files reference codes — BNF codes for drugs, practice and organisation codes — that only make sense once you join them to separate reference files. If you leave Claude to guess those joins, it might guess wrong and quietly give you plausible-but-off numbers. Ten minutes describing the schema up front saves an afternoon of doubting your results.
Once the data's queryable, asking for analysis is the easy part. What I've found actually useful is having Claude build the output as a self-contained HTML page — a little dashboard I can open, keep, and come back to, rather than a wall of numbers in a chat that scrolls away.
This is exactly what FigurePages is for, and honestly why it got built. Claude generates the page, publishes it, and hands back a link. A link I can message to someone, reopen next week, or line up next to last month's version. That's so much faster to manage than regenerating the same view every time I want to look at it.
Here's a real one built straight off this workflow — an NHS England medicines snapshot for April 2026. The prescribing data went into a local database, Claude queried it, and the whole thing came back as a single page I can just send to someone.
Strip it back and the trick is just moving the data out of the expensive place (the context window) and into the cheap place (a local database), then using Claude for what it's genuinely good at — writing the SQL, spotting the patterns, and turning a result set into something you can actually read. The data stays on your machine, the queries stay fast, and the bill stays small.
It's not the "right" way to run analytics at scale. It's just a setup that's quick enough and cheap enough that I use it constantly — and that counts for a lot.