Skip to main content

What are SQL warehouse sessions?

SQL warehouse sessions allow you to define variables, create temporary views, and maintain state changes across multiple query runs. With sessions, you can build SQL logic iteratively without needing to run all statements at once.

You can use sessions in the following contexts when attached to a SQL warehouse:

Example use case​

Sessions enable you to run statements individually while maintaining shared state. For example, you can declare a variable, create a temporary view that uses that variable, and then query the view separately.

The following example demonstrates this workflow:

SQL
-- Statement 1: Declare a variable
DECLARE VARIABLE row_limit = 10;

-- Statement 2: Create a temporary view using the variable
CREATE OR REPLACE TEMPORARY VIEW filtered_data AS
SELECT
  *
FROM
  main.default.sales_data
LIMIT row_limit;

-- Statement 3: Query the temporary view
SELECT
  *
FROM
  filtered_data;

With sessions, you can run each statement individually. The variable and temporary view remain available, allowing you to iterate on your queries without re-running all previous statements.

How sessions work​

A session is created when a user runs a query on a SQL warehouse. Sessions remain active as long as a command runs at least once every eight hours. Sessions persist even if the warehouse stops or restarts.

A session expires after eight hours of inactivity.

Shared session state​

All commands run within the same session share the following:

  • Variables declared with DECLARE VARIABLE
  • Temporary views created with CREATE TEMPORARY VIEW
  • Environment settings such as the current catalog and schema

Session scope and collaboration​

Sessions are tied to both the query object (query, notebook, or file) and the specific SQL warehouse it is attached to. All users who share access to that object and warehouse connection also share the same session.

For example:

  • User A defines a temporary view in Query 1 while connected to Warehouse X.
  • User B can run a SQL command in Query 1 on Warehouse X that references that same temporary view.
  • If Query 1 is reattached to a different warehouse, a new session is created with its own isolated state.

This collaborative behavior allows teams to work together on shared query development, but it also means that changes made by one user affect all other users sharing the same session.

Next steps​

Last updated on