How it works

formulaDB puts a real SQL engine inside Excel. When you type =DB.QUERY(...), the query runs in DuckDB, compiled to WebAssembly and running inside the browser sandbox the add-in lives in. The result spills back into the grid like any other dynamic array.

Nothing round-trips through a formulaDB server. The browser reads the data — a remote file or a local one — runs the SQL locally, and returns the rows. There is no account, no upload step, and no backend that sees your data.

The query path

1. A cell calls =DB.QUERY(sql, ...sources).
2. DuckDB reads each source the query names.
3. It runs your SQL over those sources.
4. The result spills into the sheet, with the column names as the first row.

Because the query lives in the workbook, it refreshes with Excel’s normal recalculation. The query is the document — when an input changes, the answer updates.

Source cells

You don’t pass a URL straight into =DB.QUERY. First you name the source with =DB.SOURCE, which binds the source to a short SQL alias and returns a source cell:

A1: =DB.SOURCE("https://dev-fdb.sumpalabs.com/samples/sales.parquet", "sales")
B1: =DB.QUERY("SELECT region_id, SUM(revenue) FROM sales GROUP BY region_id", A1)

The query refers to the source by its alias (sales), and passes the source cell (A1) as an argument. This is deliberate: Excel’s recalc graph now knows that B1 depends on A1, so changing the source re-runs the query. It also lets one query reference several sources — pass one source cell per source and JOIN them by alias.

Remote or local

A source is either remote or local, and formulaDB tells them apart by whether the name is a URL:

• Remote — an https:// address. The browser fetches the file directly from wherever it’s hosted.
• Local — a file you choose with the task pane’s file picker. It’s read in the browser and never leaves your machine; you refer to it by its file name.

Either kind binds to an alias the same way, so a query can JOIN a remote dataset against a local file without either one being copied anywhere.

Partitioned datasets

Large datasets are usually split into many files — for example one file per year. Plain HTTP has no way to list the files in a folder, so formulaDB uses a small manifest: a JSON document that lives next to the dataset and lists its files. You point =DB.SOURCE at the manifest’s URL (a .json), and formulaDB reads the manifest first, then the files it names.

These datasets are often partitioned — the folder names encode a value, like year=2024. formulaDB exposes those partition keys as ordinary columns you can query and filter on. When your filter is on a partition column, whole files are skipped before anything is downloaded, so a query for one year doesn’t pull the others.

The first-party demo for this is PetroDB, a public corpus of oil-and-gas datasets — a year-partitioned production dataset is the canonical example of the manifest-plus-partitioning path.

Limits worth knowing

• Every query has a 60-second timeout and a 1,000,000-row result cap — see =DB.QUERY for what happens when you hit them.
• Local files live only for the current session; re-opening a workbook starts with no files picked, so you re-pick them when you need them again.

Next

• Install — get the add-in into Excel.
• Examples — worked queries, from one file to a multi-source JOIN.
• =DB.QUERY · =DB.SOURCE · =DB.SCHEMA — the full function reference.