Your schema as a DDL file

What changes without a connection

Answers: Cassis understands the structure and writes grounded SQL, but it cannot run that SQL or answer with data. An answer carries the SQL and the context objects it used, and results is null: the query was not run, which is different from a query that returned zero rows.
Evals: Neither the generated nor the gold SQL can run, so an LLM judge compares the two queries’ logic. See Build and run evals.
Schema changes: Cassis cannot notice them. Upload the new DDL when your schema changes.
Everything else: The same context, review queue, versions, MCP tools, and CLI.

Export your tables

Export the current definitions of the tables you chose for your first question. Keep their qualified names and complete column definitions. The file contains schema, not data rows. If you use views, include their definitions and the tables they depend on.

Snowflake

Run GET_DDL for each selected table, replacing the example names. The final argument keeps fully qualified names:

SELECT GET_DDL('TABLE', 'MY_DB.PUBLIC.CUSTOMERS', TRUE);
SELECT GET_DDL('TABLE', 'MY_DB.PUBLIC.ORDERS', TRUE);

Copy the returned SQL text, not the result-grid headings or CSV quoting, into one schema.sql file. Use the VIEW object type when exporting a view.

BigQuery

Read the ddl column in INFORMATION_SCHEMA.TABLES. Replace the project, dataset and table names:

SELECT ddl
FROM `my-project.my_dataset.INFORMATION_SCHEMA.TABLES`
WHERE table_name IN ('customers', 'orders');

Copy each returned statement into schema.sql, with its terminating semicolon. Use the dataset’s location when running the query.

PostgreSQL

Use pg_dump with your usual PostgreSQL connection settings. Replace the database and table names:

pg_dump --dbname=my_database --schema-only --no-owner --no-privileges \
  --table=public.customers --table=public.orders --file=schema.sql

Keep authentication in your usual PostgreSQL environment or password prompt. The export includes table definitions and constraints without rows. If an upload reports an unsupported statement, inspect the named statement; do not replace the export with a list of inferred columns.

Give Cassis the schema

Export the selected schema as one snapshot file of CREATE TABLE statements, with view definitions where needed. A replay of incremental migrations does not work.
When you create the project, choose DDL file under Data source, pick the SQL dialect (PostgreSQL, Snowflake, or BigQuery), and upload the file.
Check the Schema page. If a statement cannot be parsed, the upload fails and names the line or table instead of skipping it.

When the schema changes, use Update from DDL… on the Schema page. Cassis shows a plan of the tables and columns added, removed, or changed and what each change does to the context, and applies nothing until you confirm. From a pipeline, run cassis schema push with the new file.

Run the SQL with your own tools

The SQL Cassis returns is ready for your warehouse. An analyst can paste it into the SQL editor they already use. An analytics agent with its own warehouse access, such as a warehouse MCP server running on your side, can take the SQL from ask_question and run it with your credentials. Cassis never sees the rows.

Ask the agent to report back. When SQL that Cassis wrote fails or returns something wrong, the agent records it on the same chat with submit_feedback as its own observation. The mistake then reaches your review queue as evidence, exactly like a user’s correction.

The runner is your responsibility. Cassis only generates the SQL. Give the agent that runs it a read-only warehouse role, as you would any other client.

Connect later

Open Settings → Project settings and add a connection string under Connection. The context and the schema are kept, and from then on Cassis runs its SQL and you can Sync from warehouse. See Connect a warehouse.