Snowflake Copilot: How to Use It to Write and Improve SQL

Update, October 2026: Snowflake is replacing Copilot with Cortex Code (CoCo) in Snowsight. The workflows below still apply wherever Copilot is available in your account. For the current assistant, see Snowflake’s Cortex Code documentation and the section on moving to Cortex Code below.

Snowflake Copilot turns a plain-English question into SQL, right next to your worksheet, using your schema as context.

For a data engineer, the useful question isn’t whether it has AI. It’s which parts of your SQL work it speeds up, and which cost and performance problems sit outside its reach.

Short answer: Copilot is very good at the SQL you write by hand. It doesn’t touch the warehouses that run it. This guide covers both sides, with examples.

What Is Snowflake Copilot? 

Snowflake Copilot is an LLM-powered assistant built into Snowsight. You ask a question in natural language, and it answers with SQL, an explanation, or guidance from Snowflake’s documentation.

Snowflake’s docs list what it’s built for:

• Exploring a new dataset by asking open-ended questions about its structure.
• Generating SQL from questions in plain English.
• Building complex queries through follow-up questions.
• Explaining what an existing query does, and suggesting optimizations or fixes.
• Answering questions about Snowflake features and SQL syntax.

How Does Snowflake Copilot Work?

Copilot runs inside Snowflake Cortex, Snowflake’s managed AI service. Snowflake describes it as “powered by a model fine-tuned by Snowflake that runs securely inside Snowflake Cortex.”

When you ask a question, Copilot first searches for the tables and columns most relevant to your request. It uses the names of your databases, schemas, tables, and columns, plus column data types, to work out what’s available to query. Then it generates a response.

It’s conversational. If the first query isn’t quite right, ask a follow-up (“show me this for each month”) and it refines the SQL.

Admins who need tight control over which models run in their account can turn on model-level RBAC. In that setup, Snowflake’s docs say Copilot uses Anthropic Claude Sonnet 3.5 where it’s available and falls back to Mistral Large 2.

Does Snowflake Copilot Present a Data Risk?

Copilot is designed to work inside your existing governance:

• The model runs inside Snowflake Cortex, and your data and metadata stay inside Snowflake.
• It respects RBAC, so suggestions only cover objects your role can access.
• It reads object names and column data types. It doesn’t read the data in your tables.

Access is controlled by the SNOWFLAKE.COPILOT_USER database role, which is granted to PUBLIC by default. That means every user in the account can use Copilot until you change it.

To limit Copilot to specific roles:

USE ROLE ACCOUNTADMIN;  -- Remove default access for all users REVOKE DATABASE ROLE SNOWFLAKE.COPILOT_USER FROM ROLE PUBLIC;  -- Grant access to the roles that should have it GRANT DATABASE ROLE SNOWFLAKE.COPILOT_USER TO ROLE analyst;

The role can’t be granted directly to a user, so grant it to an account role and assign that role to users.

How Do You Use Snowflake Copilot?

No setup is needed beyond the role above.

1. Open a SQL worksheet in Snowsight and select Ask Copilot in the lower-right corner. The Copilot panel opens on the right.

2. Make sure a database and schema are selected for the worksheet. Copilot needs both to generate relevant answers.
3. Type your question. To point Copilot at a specific table or column, prefix the name with @.
4. When the answer includes SQL, select Run to add it to the worksheet and run it, or Add to edit it first.
5. Keep refining with follow-up questions in the same chat.

Each chat is tied to its worksheet. A new worksheet starts a new chat.

You can also set custom instructions (up to 2,000 characters) from the Copilot menu: SQL style preferences, business definitions, or anything else you want considered in every response. They apply to your user only.

Is Snowflake Copilot Limited to a Specific Edition or Region?

No, Snowflake Copilot is not Edition-specific. Instead, Snowflake Copilot is region-based. If it’s available within your region, then you have access to it, regardless of which Edition you subscribe to. As of today, Snowflake Copilot is available in the following AWS and Azure regions:

• AWS US West 2 (Oregon)
• AWS US East 1 (N. Virginia)
• AWS US East (Commercial Gov, N. Virginia)
• AWS Europe Central 1 (Frankfurt)
• AWS AP Northeast 1 (Tokyo)
• AWS Europe West 1 (Ireland)
• AWS AP Southeast 2 (Sydney)
• Azure East US 2 (Virginia)
• Azure West Europe (Netherlands)

Accounts in other regions can use Copilot by enabling cross-region inference with the CORTEX_ENABLED_CROSS_REGION parameter. Check Snowflake’s Copilot docs for the current list.

Does Snowflake Copilot Cost Extra?

No. Snowflake’s documentation lists Copilot as currently free to use, and says customers will be notified before any charges apply.

The queries you run from its suggestions are a different matter. They execute on your warehouse and bill like any other query. That’s where the cost conversation actually sits, and we’ll come back to it.

How to Get the Most Out of Snowflake Copilot

Copilot is only as useful as the questions you bring to it. These are the workflows where it saves the most time.

Exploring Unfamiliar Datasets

One of the biggest roadblocks to using Snowflake isn’t the platform itself, but the data contained within it.

Say you’ve just inherited a table called customer_events with ten date fields, half a dozen JSON columns, and hundreds of event types. No documentation. Your first move is probably a handful of queries like these:

-- What date range are we dealing with? SELECT   MIN(event_timestamp) AS first_seen,   MAX(event_timestamp) AS last_seen FROM customer_events;  -- Which event types exist? SELECT DISTINCT event_type FROM customer_events;  -- How many customers per event type? SELECT   event_type,   COUNT(DISTINCT customer_id) AS unique_customers FROM customer_events GROUP BY event_type ORDER BY unique_customers DESC LIMIT 10;

Writing a dozen of these by hand takes time. And every one of them runs on a warehouse and consumes credits.

Instead, ask Copilot for one profiling script:

“Write a query that profiles @customer_events: row count, null rate per column, distinct value counts for event_type and customer_id, and the top five values for event_type.”

You get a single script to review and run, and a baseline for deeper analysis.

Two things to know. Copilot can’t see your data, so if you want to filter on a specific value, put the value in the prompt (“event types that start with ‘checkout'”). And for wide tables, Copilot considers the top 10 columns it finds most relevant, so name the columns you care about.

Fast Query Generation

Plenty of queries come from BI tools and pipelines. But some still have to be written by hand:

• One-off deep dives. A team needs a custom analysis with CTEs, window functions, or conditional logic.
• Semi-structured transforms. Cleaning or flattening nested JSON.
• Troubleshooting. Queries specific to one error or one incident.
• Performance tuning. Rewrites that need someone who knows the data and the SQL.
• Pipeline debugging. Context-specific checks an auto-generated query won’t cover.

These often take a long time relative to their value. Copilot shortens the first draft:

“Show me any columns in @orders where more than 5% of values are null, and write a script that replaces those nulls with the column median.”

You get a multi-step script to start from. Treat it as a first draft. Snowflake’s docs note that Copilot “may sometimes suggest queries that contain invalid SQL syntax or non-existent tables or columns,” so review and test before anything reaches production. Your time goes into checking logic, not typing boilerplate.

Why a native assistant? A general-purpose assistant outside Snowflake only knows your schema if you paste it in, and pasting table and column names into an external tool may conflict with your data policies. Copilot already has the schema context, and it stays inside your Snowflake governance boundary.

SQL Optimization

Paste an existing query into Copilot and ask it to assess efficiency, find optimizations, or explain what the query does. Because it reads your schema metadata, its suggestions reference your actual tables and columns. Typical suggestions cover join and filter rewrites or logic that does more work than the result needs.

Know the boundary: Copilot sees query text and schema, not execution statistics. It can’t tell you whether a query spilled, how many partitions it pruned, or where its time went. For that, open the query’s Query Profile. The two work well together: the profile shows where the time went, and Copilot helps you rewrite the SQL.

Searching Snowflake Documentation

Snowflake’s documentation is extensive. Copilot gives you a faster way into it. Ask how to do something in Snowflake (“How do I ingest data from S3?”) and it answers from the docs, next to your worksheet.

Learning SQL Syntax

Ask Copilot to explain a function, a join pattern, or someone else’s query step by step. For newer engineers, that’s in-context coaching without waiting on a senior engineer. For senior engineers, it’s time back.

Getting Better Answers: Curated Views

Snowflake’s own tip for improving Copilot’s answers is to give it well-shaped views:

• Use descriptive names for views and columns, in the terms your team actually uses (sale_date, not dt2).
• Assign the right data types. A date column should be DATE.
• Define common metrics as columns, such as (revenue – cost) AS profit.
• Capture common joins in the view, using your preferred join path.

This also works around a documented limit: Copilot doesn’t support cross-database or cross-schema queries, so a view that brings those objects together gives it one place to look.

What Copilot Is Built For, and What It Isn’t

Copilot is strong where the work is a person writing or reading SQL:

• Suggestions are grounded in your schema, so they reference your real tables and columns.
• It shortens first drafts for exploration, one-off analysis, and rewrites.
• It explains queries and Snowflake features in context, which speeds up onboarding.
• It runs inside Snowflake’s governance: RBAC, no access to table data, and admin-controlled access.

Its scope ends where the work stops being a person writing SQL. These limits come from Snowflake’s documentation or from what Copilot is designed to do:

• It answers the questions you ask. It won’t surface a problem nobody thought to look for.
• It works on the SQL you bring to it. Queries generated by BI tools and pipelines run without passing through Copilot.
• It reads metadata, not data. By design, it can’t see data distribution or runtime statistics.
• It considers a subset of your schema. For each response, the top 10 most relevant tables and the top 10 columns in each.
• No cross-database or cross-schema queries. Use views as the workaround.
• New objects take time to appear. Up to 3 to 4 hours for new databases, schemas, and tables.
• It suggests, you decide. Warehouse sizing, suspend settings, and scheduling are outside its scope.

Where Keebo Fits Alongside Snowflake Copilot

Copilot works on the SQL you bring to it. Keebo works on the layer underneath: the warehouses that run every query, including the ones your BI tools and pipelines generate without anyone writing them by hand.

Each covers ground the other doesn’t:

• Faster queries + rightsized warehouses. Copilot speeds up query writing. Keebo continuously adjusts warehouse settings so resources match the workload as it shifts.
• Query-level insight + account-level insight. Copilot shows you how a query is structured. Keebo shows you how your warehouses, users, and workloads behave over time.

Moving to Cortex Code

Snowflake is replacing Copilot with Cortex Code (CoCo), which Snowflake describes as an agentic assistant. Instead of answering one question at a time, it plans and runs multi-step tasks. It works in Workspaces and Notebooks, shows suggested changes in a diff view, offers inline SQL suggestions as you type, and covers account administration tasks like finding high-cost warehouses or queries.

Two practical differences for admins:

• Access uses Cortex roles. CoCo needs SNOWFLAKE.CORTEX_USER or SNOWFLAKE.CORTEX_AGENT_USER. Until behavior change BCR-2445 reaches your account, the role also needs SNOWFLAKE.COPILOT_USER.
• It consumes credits, and Snowflake gives you controls for it. Options include budgets, per-user quotas, and daily credit limits per surface. For example, to cap CoCo in Snowsight account-wide and allow one user a higher limit:

ALTER ACCOUNT SET CORTEX_CODE_SNOWSIGHT_DAILY_EST_CREDIT_LIMIT_PER_USER = 0; ALTER USER power_user SET CORTEX_CODE_SNOWSIGHT_DAILY_EST_CREDIT_LIMIT_PER_USER = 20;

See Cost controls for CoCo for the full set.