Join CSV Files With SQL

Press Try with sample data and both slots fill. The left one takes sales-10k.csv, 10,000 orders with region, channel, units, amount and a refunded flag. The right one takes region-targets.csv, five rows carrying each region's manager, its office and its quarterly target. They become the tables sales_10k and region_targets, also reachable as t and t2.

Both carry a region column, so the page writes a join and puts it in the editor for you to read before you run it. That pause is deliberate: joining on the wrong pair of columns produces a number that looks fine and is wrong, and that is worth one click of consent rather than a silent result.

The question worth asking of these two files is whether each region hit its target, which needs the facts from one file and the target from the other:

SELECT
  s.region,
  r.manager,
  r.office,
  ROUND(SUM(s.amount) FILTER (WHERE NOT s.refunded), 2) AS net_revenue,
  r.quarterly_target,
  ROUND(100.0 * SUM(s.amount) FILTER (WHERE NOT s.refunded) / r.quarterly_target, 1) AS pct_of_target
FROM sales_10k AS s
LEFT JOIN region_targets AS r USING (region)
GROUP BY s.region, r.manager, r.office, r.quarterly_target
ORDER BY pct_of_target DESC

Five rows come back, one per region, sorted by how close each came. The LEFT JOIN matters: if a region appeared in the sales file but had no row in the targets file, an inner join would drop it silently and the total revenue on screen would be lower than the real one, with nothing to tell you why.

Before trusting any joined total, run the safety check. It takes ten seconds and it catches the single most common join bug:

SELECT region, COUNT(*) AS n
FROM region_targets
GROUP BY 1
HAVING COUNT(*) > 1

No rows means the key is unique on the right-hand side, which means the join cannot multiply your rows. Rows coming back means it can, and every sum in your result is inflated by exactly the amount of that duplication. This is why a joined revenue figure so often comes out mysteriously higher than the source file's own total.

A join is the exact place where hand-written browser SQL falls apart. Recognizing SELECT cols FROM csv WHERE col = value takes an afternoon; implementing a hash join with correct null semantics, four outer variants, multi-column keys and type coercion is a database. Tools built on the first thing either refuse joins outright or hide them behind a mode that downloads a proper engine on demand, which means the join you tested this morning may run on a different engine this afternoon.

This page runs DuckDB compiled to WebAssembly. One engine, the real one, live from the first query, with the same planner and the same SQL dialect as the desktop build. The join above is a plain SQL join with a FILTER clause and a USING key, and none of that is a special case here. The engine downloads once in the background when you hand the page a file, and your browser caches it after that.

It stays read-only. Statements have to start with SELECT, WITH, FROM, DESCRIBE, SUMMARIZE or EXPLAIN; only one runs at a time; and anything that writes, attaches a database or installs an extension is refused in the page before the engine ever sees it.