How to Run SQL Against a CSV File Without a Database

The gap between "I could answer this in SQL in thirty seconds" and "the data is in three CSVs on my desktop" is where a lot of afternoons go.

The short answer

Query the files where they are. In DataTray, open Data Explorer and switch to the SQL tab: files referenced by path in FROM are read in place, so

SELECT customer_id, sum(total)
FROM 'C:\exports\orders.csv'
GROUP BY customer_id
ORDER BY 2 DESC

just works. The file you already have open is pre-bound to a short alias, read_parquet('data/*.parquet') reads a whole folder, and you can join across formats. No import, no server, no connection string.

No import step is the whole point

The usual route is: install a database, create a schema, work out the types, load the CSV, discover three columns failed to load, fix them, reload, then finally write the query you wanted twenty minutes ago.

An embedded analytical engine skips all of it because the file is the table. That changes what SQL is useful for — it stops being something you set up for a project and becomes something you reach for on a file that arrived this morning.

Joining across formats

This is the part that surprises people. These are all tables:

SELECT o.order_id, c.region, o.total
FROM 'orders.parquet'      AS o
JOIN 'customers.csv'       AS c USING (customer_id)
WHERE o.total > 500

A Parquet file joined to a CSV, with no conversion of either. Add an Excel sheet or a JSON file to the same query and it behaves identically. Where you would previously have converted everything to one format first, you now just reference them.

Views, so a path becomes a name

Long absolute paths make queries unreadable. Save a named view and 'C:\exports\2026-08\orders.csv' becomes orders, which survives between sessions and makes the next query short.

There is a file and view sidebar with drag-to-insert, schema-aware autocomplete fed from the files' actual columns, Ctrl+Enter to run, a cancel button that works, and query history.

The guard rails, and why they exist

The connection is read-only against your files, and writes happen only through the explicit Export button — never through a COPY in the editor. More importantly, remote filesystems are disabled, so no query can reach http://, https:// or s3://.

That second one is not paranoia. People paste SQL from the internet, and a query that can read a remote path can also write to one. Removing the capability entirely means a pasted query cannot become an exfiltration path, which is what makes it safe to use this tab on a file you care about.

Results go back into the grid

Query results stream into the same grid as the Rows tab, with the same filtering and the same export. "Export what I am looking at" applies to a query result exactly as it applies to a file, in CSV, Excel, Parquet or JSON.

You do not have to use it

Worth saying plainly, because SQL tabs put people off: this is one of three tabs, and the other two do everything else. Rows and Columns handle viewing, filtering, sorting and profiling with no query language involved, and most people never open this tab at all.

It is here because the person who would write SQL should not have to install a database to write four lines of it.

No natural-language-to-SQL, deliberately

There is no "describe your question and we will write the query" feature, and there will not be one. A model writing SQL against a multi-gigabyte file produces confident answers you cannot audit, and on a file this size the audit is the entire job. If the query is wrong you want to see that it is wrong, which means writing it yourself.

---

Every other free way to do this asks you to upload the file first — and a SQL console that runs on somebody else's server has your data on somebody else's server.