Run real SQL against a SQLite database file or CSV files you open, with results shown in a table you can export. It is a full SQLite engine compiled to WebAssembly, not a simulation, so joins, aggregates, CTEs and window functions all work, and database files of several gigabytes open without being loaded into memory.
Query results download as CSV - one file per result set when a script returns several - and the whole database can be saved back out as a .sqlite file. It is free to use, with no account and no upload limit, and it runs entirely in your browser: nothing is uploaded, and while the page stays open, a feature you have already used keeps working offline.
- Is this real SQL or a simplified imitation?
- Real SQL. It is SQLite itself compiled to WebAssembly, so joins, aggregates, subqueries, CTEs, window functions and the full SQLite function library all behave exactly as they would on your desktop.
- Can I query a CSV without setting up a database?
- Yes - that is the quickest path here. Open the CSV and it becomes a table you can immediately SELECT from, which beats loading it into a spreadsheet to do a group-by.
- Can I query an Excel file or JSON with SQL?
- Yes. Open an .xlsx, .xls or .ods workbook and every sheet with a heading row becomes a table, named after the file and the sheet; dates come in as YYYY-MM-DD text, and codes with leading zeros stay text. A JSON file that holds an array of objects - or wraps one, as API responses often do - becomes a table with a column for every key, and nested values are kept as JSON text you can query with json_extract. Results go back out as CSV, Excel or JSON.
- Can I join two CSV files with SQL?
- Yes. Open them together or one after the other: each is added to the loaded database as its own table, named after the file (with _2 on the end if that name is already taken), so a JOIN across them works as it would across any two tables. Opening a .sqlite file is different - it replaces what is loaded.
- Can I look through a table without writing SQL?
- Yes. Press Browse beside a table in the list: its rows show as a grid, a hundred at a time, with the column headings to sort by and a box that filters on any column. Open as SQL writes the same view as a query in the editor, to carry on from there.
- Can I edit a cell without writing an UPDATE?
- Yes. In the Browse grid, double-click a cell, type the new value and press Enter, or press NULL to empty it. The column's type still applies, so 42 typed into a number column is stored as a number, and a change that breaks a rule of the table, such as a duplicate id, is refused with SQLite's reason. Add row puts a new row at the end to fill in, and the × beside a row deletes it. Views are read-only, since they are the result of a query.
- Is my database uploaded?
- No. The engine runs in your browser and the file is read in place there, a piece at a time, and nothing is sent to a server. A SQLite file is often an entire application's data, so this is not a small distinction.
- Can I write to the database, not just read it?
- Yes. INSERT, UPDATE, DELETE and CREATE TABLE all work: your changes are kept in memory on top of the file as it was read, and Save .sqlite writes the modified database back out as a file. Your original on disk is untouched unless you replace it yourself.
- How large a database can it open?
- Several gigabytes. A SQLite file is read where it sits on your disk, a piece at a time as queries need it, rather than being loaded into memory, so a 2 GB database opens at once and a lookup by key answers in milliseconds; a query that has to read every row of a huge table takes a few seconds per gigabyte. Changes are kept in memory until you save. CSV files are different: they are loaded into a table in memory, so tens or hundreds of megabytes suit them best.