SQL Playground
SQL playground running a real SQLite engine: query a sample schema or open your own .sqlite file, then pretty-print the query in any of eleven dialects.
or open your own — .sqlite, .db or .sqlite3 · read into tab memory, sent nowhere
Schema
press a table to query it · from sqlite_master and pragma_table_info
no tables yet — load a sample or open a file; a query still runs on an empty database
Results
the rows land here
In tab memory
No database in memory
tables live in tab memory and a reload empties them — Download database is the only way anything survives
Start here
- Pick something from Load a sample database if you just want a schema to poke at, or drop a .sqlite, .db or .sqlite3 file on Open .sqlite file to query your own.
- Write SQLite in the SQL box and press Run query. The first press pulls the engine down, so it takes a beat; after that there is no wait.
- Read the line over the results: it counts the rows and the result sets apart. Several statements in one go all execute, but only the last one that returns columns gets drawn.
- Set Format dialect, then press Format SQL to reindent the editor at two spaces with keywords capitalised. Undo format puts your own layout back until you type again, and Ctrl+Z works too.
- Export CSV and Export JSON save the result set as results.csv and results.json. Download database saves the file itself as database.sqlite, which is the only way anything survives a reload.
About this tool
SQLite compiled to WebAssembly is what does the work here, which is why the SQL playground can handle CREATE TABLE, a five-way JOIN, a window function or a recursive CTE with no database server anywhere in the picture. It is the same engine sitting inside your phone and inside half the apps on your laptop, so what runs here runs there. The download is about 640 KB and it only happens the first time you press Run query. Format SQL never touches it, so the formatter works on a page that has not loaded the engine at all.
Two sample databases are in the dropdown, one HR schema and one small store, and picking either fills the editor with a query and executes it right away. Your own file works the same way: .sqlite, .db and .sqlite3 all open, and the rows are read straight into memory rather than posted to anybody, which is the only reason I would ever point a web page at a production database. Results arrive as a table you can send out as results.csv or results.json, and Download database writes the whole thing back to database.sqlite with your changes in it. The editor text is saved to this device as you type. The tables are not.
A worked run on the employees sample
Choose Employees & departments from Load a sample database. Six employees across three departments go into memory, the editor fills itself with a GROUP BY over the join, and that query runs before you have touched anything.
The table underneath comes back Engineering 3 145000, Sales 2 94500, Marketing 1 87000, sorted on average salary, and the line over the results reads 3 rows · 1 result set. Swap ORDER BY avg_salary DESC for ORDER BY headcount and press Run query: the same three rows, now smallest department first. Export CSV writes exactly what you are looking at to results.csv.
Good to know
- Execution is SQLite and nothing else. The formatter will tidy T-SQL or PL/SQL happily, then the engine will reject the same statement the moment you press Run query.
- Tables live in tab memory, so a reload hands you an empty database. Your SQL text comes back because it is written to local storage on every keystroke; the data does not come back at all. A file in the hundreds of megabytes strains the tab too, much sooner on a phone than a laptop.
Frequently asked questions
How do I look at the tables inside a .sqlite file I already have?
Drop it on Open .sqlite file. Every table lands in the Schema rail with its row count and its columns, typed, with the primary key and NOT NULL marked, and the first table's first 50 rows run at once. Press any other table in the rail to put its SELECT into the editor. The picker accepts .sqlite, .db and .sqlite3.
I refreshed the page and my tables are gone. Can I get them back?
Only if you pressed Download database beforehand. Everything the engine holds lives in tab memory, so a reload starts you on an empty database. What does survive is the editor contents, saved to local storage on every keystroke, so the query you spent half an hour on is still sitting in the box waiting for a schema to run against.
Can I run Postgres or MySQL syntax here?
Not on the engine. Format dialect only decides how the formatter parses and lays out your text, which is why PostgreSQL, MySQL, MariaDB, T-SQL, PL/SQL, BigQuery, Redshift, Snowflake and Spark are all in that list. Execution is always SQLite, so a Postgres-only function will format beautifully and then fail on Run query.
Why does a column show [BLOB 4096 bytes] instead of a value?
Because the column holds binary. A BLOB has no sensible text form, so the table prints its length in place of the bytes, and Export JSON writes that same placeholder string into the file. Wrap the column in hex() or length() in your SELECT if you want to see what is actually in there.
A cell said NULL in the table but came out empty in the CSV.
Both are doing the right thing for their format. The grid prints the word NULL where a value is missing, which keeps it apart from an empty string while you are reading rows on screen. CSV has no way to write a null, so the field is left empty. Export JSON is the one that keeps the difference, writing a real null into the file, and that is the export to take if something downstream cares.
I ran an UPDATE and the results table disappeared.
A statement that hands back no columns has nothing to draw, so the results pane says so and the line under the toolbar reports how many rows were affected instead. Follow it with a SELECT to see the new values. The strip counts the change as unsaved, and Download database is the way to keep it.
Does Format SQL change what my query does?
It reparses the statement and lays it out again at two-space indentation with keywords capitalised, and it leaves the logic alone. It rewrites the editor in place, so Undo format sits beside it until your next keystroke, and Ctrl+Z steps back through it as well.
Missing something in SQL Playground? Suggest a feature →
Tell someone who needs this.