SQL Lab

Editor

The editor is Monaco — the same editor that powers VS Code — so syntax highlighting, multiple cursors, and inline errors work exactly as you’d expect.

Keyboard shortcuts

Autocomplete & the schema browser

Monaco autocompletes SQL keywords out of the box. Table and column names come from the schema browser on the left: select a database to load its tables, then expand a table to pull in its columns. Once loaded, those names feed autocomplete as you type.

Multi-tab sessions

Every query runs in its own tab. Open more with the + button in the tab bar; each tab keeps its own query text and results for the session.

Selecting a database

The database selector in the toolbar lists every active data source. Pick one before running a query and the schema browser updates to match. If nothing is selected, the editor falls back to the metadata database (where the demo datasets live) — so you can always explore the platform’s own metadata without wiring up a source first.

Running queries

Kaveon exposes two execution endpoints. The Run button always uses the cancellable one.

Cancellable execution (the Run button)

POST /api/v1/lab/query — used by the primary Run button for every query you execute. The backend runs the query in an executor thread and polls for client disconnect every 500 ms. If you close the tab or navigate away, it sends a cancel signal to the database cursor (cursor.cancel()) and returns 204 No Content. Executed queries are also recorded in Query History.

KaveonDB sources stream their rows

On a KaveonDB catalog the Run button submits the statement with stream: true, and rows appear in the grid while the statement is still running, the way the kaveon shell shows them. A running line above the grid reports the coordinator’s state, the elapsed time, tasks completed, rows scanned and the workers involved, with a Cancel action that stops the statement on the coordinator and keeps the rows that had arrived. Which rows appear early is a property of the plan: a scan, filter, projection or join streams from its first batch, while a statement whose result is only known at the end — ORDER BY, GROUP BY, DISTINCT — lands its rows when it finishes. The grid holds at most the selected row limit; the summary still reports the statement’s full row count and where it was answered from. The routes behind this are listed in the API reference.

Synchronous helper

POST /api/v1/lab/execute — a plain synchronous endpoint used internally for side queries such as row-count estimates. It returns columns, rows, and a row count in one response and deliberately does not write to Query History. It is not an auto-selected fast path for the Run button.

Execution response

{
  "success": true,
  "columns": ["order_id", "total", "region"],
  "rows": [
    [1001, 249.90, "West"],
    [1002, 88.00,  "East"]
  ],
  "rowCount": 2,
  "executionTime": 0.143
}

Fields are camelCase; executionTime is reported in seconds (the UI formats sub-second timings as milliseconds).

Saving & history

Save Query stores the SQL plus its source database so you can reopen it later. Every executed query is also written to Query History — a per-user audit trail you can search, re-run, or promote into a saved query. Both live under /lab/queries.

Asking in plain language

SQL Lab is for SQL. To ask a question in plain language, use Chat: the DLM resolves it deterministically against the compiled dataset context, and the generated SQL is shown with the answer. See DLM · NL→SQL.