Developer Interface
Chalk's built-in console for Chalk SQL
The SQL Explorer is built into Chalk’s web dashboard for exploratory and experimental Chalk SQL queries. Open it from SQL > SQL explorer.
Select the Databases tab in the sidebar to open the Database Explorer, an overview of the catalogs, schemas, and tables that Chalk SQL can query. Your deployment determines this catalog of items, so it changes as you make deployments to your environment.
Create Chalk SQL worksheets in the SQL Explorer from the Worksheets tab. Select Add new and choose a worksheet type (SQL query, Online query, or Offline query), or select Save to save changes to an existing worksheet. Worksheets are listed under Private or Shared, are tied to users, and persist across sessions, so you can revisit queries within the explorer.
Each worksheet’s toolbar includes a datasource dropdown that shows Chalk SQL by default. The default selection runs the worksheet on Chalk’s query engine, which can read from and join across every catalog listed in the Database Explorer.
Selecting any other datasource sends the worksheet’s SQL to that datasource verbatim. Chalk does not translate the query, so write it in the selected datasource’s own SQL dialect: Snowflake SQL for a Snowflake source, PostgreSQL for a Postgres source, and so on. Because the query executes inside the selected datasource, reference tables by the names the datasource itself uses, without a catalog prefix from the Database Explorer. To query across catalogs again, set the dropdown back to Chalk SQL.
The resource group dropdown, marked with a server icon, selects which of your environment’s
resource groups executes the query.
Every environment has a default group. Additional resource groups run on separate compute, which
keeps exploratory or analytical queries from contending with latency-sensitive workloads in
another group. The selected group applies to both synchronous and asynchronous runs of the
worksheet.
Run a worksheet in synchronous or asynchronous mode with the Run and Run async options, which are tailored for transactional and analytical workloads, respectively. Run waits for results from the query server: synchronous queries hit the gRPC query servers directly. Run async runs on a separate machine and persists the results: asynchronous queries create an isolated environment, which takes some time to provision.
Large synchronous Chalk SQL queries can cause gRPC query servers to run out of memory, which can affect any production traffic running on that engine. Clients can set memory limits for queries to mitigate this.