SQL Editor

Raw T-SQL console (Admin + TOTP step-up required). Four output modes:

• Run — preview up to 10,000 rows (5-minute timeout). Larger results trip an abort panel routing you to CSV/Parquet/Save-to-Table.
• CSV / Parquet — full result set as a background export job; the browser polls progress and downloads when ready. Programmatic callers: the signed download URL waits ~45 s then streams (200), or returns 202 + Retry-After while still running — re-fetch until 200. The download is resumable (HTTP Range → 206 Partial Content), and short-budget/sandbox callers can add &wait=0 to get an immediate 202 instead of the ~45 s park — poll across calls, then pull the file in Range: bytes=<start>- chunks. Over MCP, export_table also batches: pass tables (up to 10) for one job + one signed URL per table in a single call.
• Save to Table — writes the result into a new table in your schema (adds dl_id BIGINT IDENTITY PK). Multi-statement scripts and top-level ORDER BY without TOP aren’t wrappable — use CSV/Parquet for those.

Export safety & limits. CSV exports neutralize formula-leading cells — a value beginning with =, +, -, or @ is prefixed with an apostrophe so a spreadsheet can’t execute it on open (Excel shows the value with that apostrophe stripped, so the data reads normally). Every export has a hard cap of 50,000,000 rows enforced while streaming — a run that would exceed it stops with a clear message rather than producing a truncated-looking file. Exports are also rate-limited per user and globally; over the limit you get a friendly HTTP 429 asking you to retry shortly. For genuinely oversized results, Save to Table and then export a filtered slice.

The interactive SQL editor runs one query per user (Cancel kills it server-side). The programmatic query tool allows up to 10 concurrent queries per user so analytics clients can fan out several reads at once; over the limit returns a 409. The limit is per user — it’s shared across all API keys issued under that user (and the user’s interactive sessions), not a per-key budget. Every Run/Export/Save-to-Table is audited (SQL_EXECUTE, SQL_EXPORT, SQL_SAVE_TO_TABLE).

Over MCP, two read-only SQL tools expose the same engine to agents: query runs a single SELECT and returns rows inline (10k cap); export_query exports an arbitrary SELECT (joins, computed expressions, aggregates) to CSV/Parquet via the signed-URL pipeline.

The system catalog is off-limits in raw SQL — use describe_entities to inspect shape. INFORMATION_SCHEMA.*, sys.* and other databases are rejected on purpose (raw SELECTs must not be able to scrape the catalog across schemas). To see an object’s columns, data types or column meanings — for views just as for tables — call the describe_entities tool, or use the Tables / Views pages. Raw SQL is for data, not metadata.

Both enforce SELECT-only (no writes/DDL/EXEC/multi-statement), require table names qualified with the tenant’s active schema (often DLO, not always — the get_active_schema tool returns it), apply RLS, and are refused for scope-restricted API keys (SQL_QUERY / SQL_EXPORT_QUERY in the audit log) — unless the key carries the AllowRawSql opt-in. An opted-in scoped key’s SQL is database-enforced against its scope grid: the key runs under its own SQL principal whose grants mirror the grid, so it can only read the entities/columns the grid allows (plus RLS on top). This is fail-closed — the request is denied rather than run with weaker enforcement. Note for keys with an exclude-mode field policy: select and count explicit column names rather than *.