Database guides

CSV files

Updated 2026-08-01 · 3 min read

Open a CSV and query it with real SQL — joins, aggregates and all — without importing it into a database first.

Point AddisDB at a CSV and it becomes a queryable table. The file is loaded into an in-memory analytical engine at connect time, so you get real SQL — GROUP BY, JOIN, window functions — against a file that was never in a database.

Who it is for

CSV is the universal export format. Every system produces it, which means the fastest way to answer a question about someone else’s data is usually to get a CSV of it. The problem is that a spreadsheet chokes past a few hundred thousand rows and cannot do a join.

It is also a format with no schema and no standard. Delimiters, quoting, encodings and date formats all vary by producer, which is why the loader has to infer rather than read a specification — and why the occasional column comes back as text when you expected a number.

Use this when you have been sent an export and want to actually interrogate it: filter it, group it, join it against another file, and chart the result — without an import step, a schema definition, or a staging database.

Preparing the file

  1. Keep the header row — column names come from it.
  2. Delimiters, quoting and types are detected automatically, so tab- and semicolon-separated files usually just work.
  3. Very messy files (ragged rows, multiple header blocks) are worth tidying first; the loader is forgiving but not psychic.
  4. Strip the title rows some tools put above the header — a file whose first line is a report name gets that line as its column names.
  5. The file is opened read-only — nothing AddisDB does can modify it.

Open it in AddisDB

  1. New Connection → Files → Common → CSV.
  2. Choose the file. There is no host, port or password.
  3. Give it a Display name so it is recognizable in the sidebar.
  4. Test, then Save.
Choosing a local CSV file in the AddisDB connection dialog.

When a column has the wrong type

Type inference samples the file, so a column that is numeric for its first thousand rows and holds "N/A" on row 40,000 comes back as text. The fix is a cast in the query rather than a change to the file.

-- TRY_CAST returns NULL instead of failing on the bad rows
SELECT region,
       sum(TRY_CAST(amount AS DOUBLE)) AS total,
       count(*) FILTER (WHERE TRY_CAST(amount AS DOUBLE) IS NULL) AS unparsed
FROM   sales
GROUP  BY region
ORDER  BY total DESC;

That second column is the useful habit: counting the rows that failed to parse tells you whether you are looking at three stray values or a systematically mis-typed column.

Joining a CSV to something else

Two exports that should agree and do not is the most common reason to open a CSV at all. An anti-join answers it in one statement — open both files as connections and compare them directly.

-- Rows in the export that are missing from the system of record
SELECT e.*
FROM   export e
LEFT   JOIN warehouse w ON w.order_id = e.order_id
WHERE  w.order_id IS NULL;

What AddisDB gives you

  • Full SQL over the file, with the columns and inferred types listed in the sidebar.
  • The Chart view for turning an aggregate into a visual immediately.
  • Notebooks, for analysis you want to be readable later.
  • AI chat that knows the file’s columns, so you can ask for what you want in plain English.
  • ⌘K search across every connection, files included.
  • A source file that is never written to — every query reads from an in-memory copy.
An aggregation over a CSV file rendered on the AddisDB Chart view.