Set a SQL task on DuckDB, with a data file
SQL (DuckDB) is a second SQL language beside SQLite, with the same two tabs: the query the student writes and the schema that builds the database it runs against. DuckDB is made for analysis, so it teaches what SQLite does not: window functions, reading a CSV file straight from its name, and reading a query plan.
What it is, and when to pick it
Pick SQL (DuckDB) when the lesson is about analysing data: running totals and rankings with `OVER`, `QUALIFY`, grouping a file of readings, or why one query is slower than another. Pick SQLite when it is about tables, keys and the first `select`. A task is one or the other for good, so a student never finds the dialect has changed under them.
Every run builds a fresh, empty database in memory in its own container, applies your schema and then the query, exactly as SQL does. Nothing a student does reaches anybody else, and nothing is kept from one run to the next.
A new DuckDB task opens with a small table of sales and a query using a window function, with a model answer that already passes.
Bring a data file
Beside the output, a data file control lets you attach one file to the task. The query reads it by its name: `select * from 'readings.csv'`, or `read_json` for JSON lines. Every student doing the task reads the same data, and a student may add one of their own beside it under a different name.
It takes CSV, TSV and JSON lines files, as text, up to 64 KB each. Parquet files are not accepted, because a data file has to be text, and so is a file that merely has the wrong ending: the page says which kinds it reads when it refuses one. The schema may be empty when the file is all the data a task needs.
What a query cannot do
DuckDB runs with no network and no way to add anything to itself. A query can read the task’s data file and nothing else: it cannot read another file, write one, attach a database, install an extension or run a command. Each attempt is refused with DuckDB’s own words, for example that file system operations are disabled, so a student who tries sees why and a teacher can show the class.
It has the same time, memory and process limits as an SQL run. A query that wants more memory than it is given stops with DuckDB’s out-of-memory message.
Running and marking it
Run executes the query and shows the rows as a plain table; Run Schema rebuilds the database and refreshes the tables shown beside it. `EXPLAIN ANALYZE` prints the plan with the rows and time at each step, which is the way to teach why a query is fast.
Marking is SQL’s. Give the task a model answer and Run tests runs the student’s query and yours against the same schema and data file and compares their rows, ignoring order but not duplicates. The result is a single pass or fail, and a query that cannot run reads Could not run rather than failed.
What it costs, and how to try it
A school or college has its first 365 days free, for up to 50 students and with no card, and everything on this page is part of it. After that the price is per student a year, with staff free and labs, virtual machines and AI included on a fair-use basis. The pricing page has the figure in your currency and a calculator.
Questions people ask
- Can students use Parquet files?
- Not yet. A data file is text, so CSV, TSV and JSON lines are accepted and Parquet is refused with a sentence saying so.
- Can a query install an extension or read from the internet?
- No. The run has no network and its configuration is locked before the query starts, so neither can be switched back on.
- Can I use DuckDB in a lesson?
- Yes. A DuckDB code block in a lesson has the same two tabs and runs on DuckDB.