DEV Community: Tsubasa Kanno

I Asked Snowflake to Analyze Data by Voice from My Even G2 Smart Glasses

Tsubasa Kanno — Sun, 11 Oct 2026 03:34:40 +0000

Introduction

I recently got my hands on the Even G2 smart glasses!

Plenty of companies make smart glasses these days, but I'd personally felt it was still a little early to jump in. Then the Even G2 came along with specs that looked good enough for everyday use, and I ended up buying a pair on impulse.

After using them for a while, an idea hit me: "Wouldn't it be incredibly handy if I could work with my Snowflake database by voice, right from these glasses?" Imagine asking "How are sales this month?" in the middle of a meeting, or whenever the thought crosses your mind, and seeing the answer appear right in front of your eyes. Just picturing it is exciting, right? So I went ahead and tried it!

This one is a side story with a slightly different feel from my usual feature introductions. I'll set things up so I can ask Snowflake's Cortex Agents (Coding Agent) for data analysis by voice from the Even G2, by way of AWS Lambda. Think of it as a little break, and I'd be happy if you read it in a relaxed mood.

The Even G2 smart glasses

Note: This article reflects my personal views and does not represent Snowflake's official position.

Note: (October 2026) Some features introduced in this article are in development or Preview. They may change significantly in future updates.

Note: In particular, Cortex AI Gateway is a Preview feature, available to accounts in AWS commercial regions (with some exceptions). Also, the request body format sent by the Even G2's Agent Configuration isn't covered in the official documentation; what I describe here is based on community analysis.

What is Even G2?

Even G2 is a pair of smart glasses with a built-in display from Even Realities. The official site describes them as "everyday," and they're designed to be worn all day long. Green text appears to float inside the lenses, so you can check answers to what you say, notifications, translations, and navigation at the edge of your vision. There are also features such as conversation support (Conversate) and a teleprompter that shows your talk script.

The display is visible only to you, so you can check your notes mid-conversation without the other person really noticing. That's a nice touch (the official Conversate help also describes it as "visible only to the wearer"). On top of that, if you pair the glasses with the R1 ring, you can switch screens with just a tap or a scroll of your fingertip, without touching the glasses at all. It feels more natural than I expected, and it's really handy.

Even G2 official site

What I like most is that there's deliberately no camera or speaker. The official site says "Camera-free. By design.", and the developer documentation states "No camera, no speaker on the glasses." You won't make people around you worry about being recorded. And at an official 36 g, they weigh about the same as regular glasses, so wearing them in the office doesn't feel odd at all. If anything, I think they look a little stylish.

Overview (Even Hub Documentation)

Another interesting point is how much room there is for customization. The Even G2 comes with a standard AI assistant (Even AI) that you call up with "Hey Even." But once you sign in to Even Hub, the developer platform, a setting called Agent Configuration appears in the Even app. It lets you point Even AI's requests at an endpoint of your own. The official help even includes a tutorial on connecting to an agent running on your own PC.

Tutorial: Bridging G2 to OpenClaw - Bring Your Own Agent

When I found this setting, it clicked right away: "Then couldn't I connect this to Snowflake, too!?"

How It Works

The setup is pretty simple. All it takes is one small Lambda function sitting between the Even app and Snowflake as a relay server.

Even G2: connects to the phone over Bluetooth
Even app on the phone: converts speech to text, then sends it to Lambda over HTTPS (with the PAT as a Bearer token)
AWS Lambda (function URL): forwards the request to Cortex Agents via agent:run
Snowflake Cortex Agents (Coding Agent): runs read-only SQL
Snowflake tables: the data being analyzed

As the list shows, Lambda works as a relay server. The Even app sends requests in the OpenAI Chat Completions format, which doesn't match the request format of Cortex Agents' agent:run. The model name it sends is also fixed (this part comes from community analysis), so the request can't be forwarded as-is. Instead, Lambda reshapes the request into the Cortex Agents format, forwards it, and turns the answer back into a form the glasses can display. Lambda itself never reads any table data.

For authentication, I use a Snowflake programmatic access token (PAT). You enter the PAT in the Even app, and Lambda passes it straight through to Snowflake. Lambda never stores the PAT or writes it to logs.

Warning: For this test, I've exposed the Lambda function URL without authentication (Snowflake still authenticates the PAT). If you connect to a production database, always put Amazon API Gateway in front and add security layers such as authentication, a WAF (Web Application Firewall), and rate limiting.

What is Coding Agent?

The star of this article is Coding Agent in Cortex Agents. Coding Agent became generally available (GA) on August 26, 2026. It brings the same coding capabilities as Snowflake CoCo (formerly Cortex Code) to your own apps through the Cortex Agents REST API.

Coding Agent (Snowflake Documentation)

It's surprisingly easy to use: just specify code_toolset_all as a tool when you call Cortex Agents' agent:run. You don't even need to create an agent object beforehand. With that alone, the agent builds its answer inside a Snowflake-managed sandbox, using tools for running SQL, web search, file operations, and more.

Even better, SQL is limited to operations that read tables (SELECT and SHOW). Here's how the official documentation describes snowflake_sql_execute:

Execute SQL against Snowflake (read-only: SELECT and SHOW commands; can write to stages)

Writing to stages is the one exception. The role I create in this article has no stage privileges, though, so it can read the tables but can't change them.

This "read-only" constraint is exactly why I think it pairs so well with smart glasses. It's hard to carefully review the SQL being run from a pair of glasses. Knowing the data can't be modified lets me talk to it with peace of mind.

On top of that, the SQL the agent runs only works within the privileges of a Snowflake role. If you restrict the PAT to a specific role when you create it, the agent's SQL runs with that role. Even though you can now ask questions casually by voice, Snowflake's governance still applies, so you can keep what's visible tightly scoped by role!

What I actually verified The official documentation says Cortex Agents determines privileges based on the user's default role. So I tested it with a user whose default role is ACCOUNTADMIN, using a PAT restricted to PUBLIC. All of the agent's SQL ran as PUBLIC, and queries against a view that PUBLIC had no privileges on were rejected (confirmed in `QUERY_HISTORY`). When I tried switching to a different role, the request was rejected with the following error: ``` Role '...' specified in the connect string is not granted to this user, or is not permitted for the credentials being used. ```

Setup

From here, I'll walk through the steps to get it running, one at a time.

1. Create a Read-Only Role for the G2

First, create a dedicated role for the glasses and allow read access to the schema you want to analyze, and nothing else. I'm using my own sample e-commerce data in GLACIERSTYLE_DB.EC_ANALYTICS_SCHEMA, so replace it with the database and schema you want to analyze.

USE ROLE ACCOUNTADMIN;

-- Role used by Even G2 for read-only access
CREATE ROLE IF NOT EXISTS G2_READER COMMENT = 'Read-only role for Even G2';

-- Allow read access to the schema you want to analyze, and nothing more
GRANT USAGE ON DATABASE GLACIERSTYLE_DB TO ROLE G2_READER;
GRANT USAGE ON SCHEMA GLACIERSTYLE_DB.EC_ANALYTICS_SCHEMA TO ROLE G2_READER;
GRANT SELECT ON ALL TABLES IN SCHEMA GLACIERSTYLE_DB.EC_ANALYTICS_SCHEMA TO ROLE G2_READER;

-- Warehouse for running SQL, and the privilege to use Cortex Agents
GRANT USAGE ON WAREHOUSE COMPUTE_WH TO ROLE G2_READER;
GRANT DATABASE ROLE SNOWFLAKE.CORTEX_AGENT_USER TO ROLE G2_READER;

-- Grant the role to your user and set a default warehouse
GRANT ROLE G2_READER TO USER <username>;
ALTER USER <username> SET DEFAULT_WAREHOUSE = COMPUTE_WH;

SNOWFLAKE.CORTEX_AGENT_USER is a database role that grants access to Cortex Agents only. You can also use SNOWFLAKE.CORTEX_USER, which covers all the Cortex AI features. Also, Cortex Agents runs SQL with the user's default warehouse, so make sure your user has one set.

2. Create a Role-Restricted PAT

Next, create the PAT you'll enter in the Even app. The key points are to restrict it to the role above with ROLE_RESTRICTION, and to keep the expiration short (7 days here).

ALTER USER <username> ADD PROGRAMMATIC ACCESS TOKEN g2_even_ai
  ROLE_RESTRICTION = 'G2_READER'
  DAYS_TO_EXPIRY = 7
  COMMENT = 'Even G2 -> Cortex Agents relay';

The token is shown only once, so enter it directly into the Even app.

Note: By default, a PAT can only be used for authentication by users who have a network policy. On top of that, Lambda's source IP address isn't fixed, so a network policy that only allows your home or office IP will block calls from Lambda. If you're only trying it out briefly, you can temporarily lift the network policy requirement by specifying MINS_TO_BYPASS_NETWORK_POLICY_REQUIREMENT when you create the PAT (up to 1 day, and not recommended in the official docs). For production, fix Lambda's source IP with something like a NAT gateway, and allow that IP in your network policy.

Using programmatic access tokens (Snowflake Documentation)

3. Create the Lambda Function

Now for the relay Lambda function itself. It fits in about 90 lines using only the Python standard library. The code is a bit long, so expand the section below to see it.

Lambda function code (lambda_function.py) ```python """A minimal relay from Even G2 (Even AI's Agent Configuration) to Snowflake's Coding Agent. Runs behind an AWS Lambda function URL. Standard library only; the PAT is forwarded as-is and never stored.""" import base64 import json import os import urllib.error import urllib.request SNOWFLAKE_HOST = os.environ["SNOWFLAKE_HOST"] # e.g. myorg-myaccount.snowflakecomputing.com PATH_TOKEN = os.environ["PATH_TOKEN"] # Marker appended to the end of the URL (any long string) MODEL = os.environ.get("MODEL", "auto") # With auto, Snowflake picks the model # Telling the agent where the data lives saves it from searching through every database DATA_LOCATION = os.environ.get("DATA_LOCATION", "") # e.g. GLACIERSTYLE_DB.EC_ANALYTICS_SCHEMA SYSTEM_PROMPT = ( "You are an assistant whose answers are shown on smart glasses. " "Answer in the same language as the question, lead with the conclusion, and use plain text of about 70 words or fewer. " "Do not use headings, bullet points, tables, or URLs. " "Use read-only SQL when you need Snowflake data, and web search when you need up-to-date information. " ) + (f"The data is in {DATA_LOCATION}." if DATA_LOCATION else "") # Guidance on which tools to use. It isn't enforced, so apply the real restriction through the PAT's role ORCHESTRATION_PROMPT = "Use only the snowflake_sql_execute and web_search tools." def reply(text): """Return an OpenAI-style response the Even app can read. The content is what appears on the glasses.""" body = { "object": "chat.completion", "choices": [{"index": 0, "message": {"role": "assistant", "content": text[:350]}, "finish_reason": "stop"}], } return {"statusCode": 200, "headers": {"Content-Type": "application/json"}, "body": json.dumps(body, ensure_ascii=False)} def lambda_handler(event, context): # Reject requests to URLs without the marker if event.get("rawPath", "").strip("/") != PATH_TOKEN: return {"statusCode": 404, "body": "not found"} auth = (event.get("headers") or {}).get("authorization", "") if not auth.startswith("Bearer "): return {"statusCode": 401, "body": "missing token"} raw = event.get("body") or "{}" if event.get("isBase64Encoded"): raw = base64.b64decode(raw).decode("utf-8") try: messages = json.loads(raw).get("messages") or [] question = next(m["content"] for m in reversed(messages) if m.get("role") == "user") except (ValueError, AttributeError, KeyError, StopIteration): return reply("Sorry, I couldn't catch that. Please try asking again.") if not isinstance(question, str) or not question.strip(): return reply("Sorry, I couldn't catch that. Please try asking again.") # Even always sends a fixed model name, so reshape the request into the Coding Agent format here payload = { "stream": False, "models": {"orchestration": MODEL}, "instructions": {"system": SYSTEM_PROMPT, "orchestration": ORCHESTRATION_PROMPT}, "messages": [{"role": "user", "content": [{"type": "text", "text": question}]}], "tools": [{"tool_spec": {"type": "code_toolset_all", "name": "code_toolset_all"}}], # The glasses can't approve tool use, so let the agent use tools without confirmation "tool_resources": {"code_toolset_all": {"permission_policy": {"type": "always_allow"}}}, } req = urllib.request.Request( f"https://{SNOWFLAKE_HOST}/api/v2/cortex/agent:run", data=json.dumps(payload, ensure_ascii=False).encode("utf-8"), headers={"Authorization": auth, "Content-Type": "application/json", "Accept": "application/json"}, method="POST", ) try: with urllib.request.urlopen(req, timeout=25) as resp: data = json.load(resp) except urllib.error.HTTPError as e: return reply(f"An error occurred in Snowflake ({e.code}).") except Exception: # Timeouts, connection failures, etc. return reply("Couldn't get a response from Snowflake. Please try again.") # content is ordered tool_use -> tool_result -> text. The text after the last tool is the answer answer = [] for item in data.get("content") or []: if item.get("type") == "text": answer.append(item.get("text", "")) elif item.get("type") in ("tool_use", "tool_result"): answer = [] return reply("\n".join(answer).strip() or "The answer came back empty. Please try rephrasing your question.") ```

All it does is pull out the utterance sent from Even, send it to agent:run with code_toolset_all attached, and wrap the answer in the OpenAI format before returning it. There are three key settings:

Set permission_policy to always_allow: By default, Coding Agent asks the user for approval before using tools that change state (such as bash or snowflake_sql_execute). You can't approve anything from the glasses, so I've set it to run without confirmation (I'll cover the caveats of this setting later)
Ask for "short plain text for the glasses" in the system prompt: The glasses can only show so much text, so I ask for answers of about 70 words or fewer, with no headings or tables (just in case, the code also cuts the returned string at 350 characters)
Tell the agent where the data lives: If you set DATA_LOCATION, the agent doesn't have to search through every database from scratch, which greatly shortens the time it takes to answer

The system prompt in particular comes down to personal taste, so please customize it and find an answer style that's easy to read on the glasses.

In the AWS Management Console, create the function with the following settings:

Runtime: Python 3.13
Environment variables: SNOWFLAKE_HOST (your account's host name), PATH_TOKEN (a long, hard-to-guess string), DATA_LOCATION (the schema you want to analyze), and optionally MODEL (defaults to auto if omitted; the examples in this article specify claude-sonnet-5-5)
Timeout: 30 seconds (the default of 3 seconds isn't enough)
Function URL: create it with the auth type NONE (as mentioned earlier, put API Gateway or something similar in front for production)

4. Configure the Even App

Finally, set the destination in the Even app on your phone.

As I mentioned earlier, though, Agent Configuration only shows up for Even Hub developers. So first, enable the developer features with the steps below. The web version of Even Hub has no sign-up screen, so create your account in the Even app beforehand.

Sign in to the web version of Even Hub (hub.evenrealities.com/login) with the same account you use in the Even app
Quit the Even app once (close it from the app switcher instead of just sending it to the background), then reopen it

According to the current Even Hub documentation, your account switches to developer mode as soon as you sign in, and the developer menu appears when you reopen the app. However, the tutorial I mentioned earlier also says the setting appears once you're approved. If it still doesn't show up after reopening the app, check your Even Hub developer registration status, too.

Hardware - Enable Developer Mode (Even Hub Documentation)

Once Agent Configuration appears, set it up as follows:

In the Even app, open Settings → Even AI → Agent Configuration
Enter https://<function URL host>/<PATH_TOKEN> as the Endpoint (unlike the example in the official tutorial, don't add /v1/chat/completions at the end)
Enter the PAT you created in step 2 as the API Key
Tap Save & Activate

The Agent Configuration screen in the Even app

And that's it for the setup!

Talking to It

Now, let's ask Snowflake for some analysis. Say "Hey Even" to the glasses and then ask your question, and the Even app converts it to text and sends it to Lambda. And when it's hard to speak out loud, like in a meeting or on a train, you can also type your question in the Even app on your phone. Either way, the answer shows up on the glasses, which really widens the range of situations where you can use it.

For these examples, I'm asking about sample e-commerce data (500 orders covering all of 2024), with the MODEL environment variable set to claude-sonnet-5-5 (I'll explain why I picked this model later).

Note: The smart glasses display was hard to photograph, so in this article I show what appears on the glasses in code blocks. The text is the agent's answer exactly as it came back.

First, let's ask for total sales. When I asked "What were Glacier Style's total sales in 2024?", here's the answer I got:

Total sales for 2024 were about ¥97.97 million,
counting only completed orders (excluding
cancellations and returns). Including cancellations
(about ¥9.53 million) and returns (about ¥3.21
million), all orders totaled about ¥110.70 million.
Amounts are tax-inclusive order totals, and I've
assumed the currency is yen.

Amazingly, without any instructions from me, it checked the order statuses and gave me both totals: one without cancellations and returns, and one with them!

Behind the scenes, it checked the list of tables and columns and then ran the SQL below. To check the answer, I ran the same SQL in Snowsight. It matched exactly: completed orders totaled ¥97,970,139.81 (456 orders). (Note that "tax-inclusive" is the agent's own guess; the column descriptions don't say so.)

SELECT ORDER_STATUS, COUNT(*) n, SUM(TOTAL_AMOUNT) total
FROM GLACIERSTYLE_DB.EC_ANALYTICS_SCHEMA.FACT_ORDERS
WHERE YEAR(ORDER_DATETIME)=2024
GROUP BY ORDER_STATUS

ORDER_STATUS	N	TOTAL
completed	456	97970139.81
cancelled	29	9525519.80
returned	15	3212132.95

Next, I asked for a month-by-month comparison: "What were Glacier Style's best and worst months for sales in 2024?"

Based on completed orders, the best month for sales
in 2024 was September at about ¥16.28 million, and
the worst was April at about ¥3.92 million.
Cancellations and returns are excluded. Even with
all statuses included, the best month is still
September and the worst is still April.

I also asked about the breakdown by membership tier: "How many Glacier Style customers are in each membership tier, counted by customer ID?"

By membership tier, there are 31 Silver customers,
26 each for Gold and Standard, and 17 Platinum.
That's 100 customers in total, counted with
duplicate customer IDs removed.

The customer master in this sample data contains two rows for each customer, but it properly removed the duplicate customer IDs before counting! Both the monthly and the membership tier answers matched the correct values.

Each answer took about 10–15 seconds to come back. That's a bit of a pause for a conversation, but it feels a lot like asking someone to "look that up for me," and I found it plenty practical.

It Can Search the Web, Too

Coding Agent's tools include web search, so you can also ask about information outside Snowflake. The first time I tried, though, it answered "How much does the Even G2 weigh?" from the model's own knowledge without using web search. So I added one sentence to the system prompt: "Use web search when you need up-to-date information." After that, it started using web search properly (the Lambda code above already includes this sentence).

When I asked "How many grams does the Even Realities Even G2 weigh?", here's what came back:

The Even G2's official weight is about 36 g. In
hands-on measurements, MoguLive got 37.7 g, and AI
Watch got 44.4 g with prescription lenses. The
weight varies a little by lens and by unit.

The official 36 g matches the official site. This answer came back in about 7 seconds, a bit faster than the questions that aggregate data. It's great to be able to ask about both your company's data and the wider world from the same "Hey Even"!

Going Further: Combining Semantic Views and Cortex Search

So far, I've had Coding Agent build its SQL from scratch. With Cortex Agents, you can also pick the tools you give the agent to suit your purpose. This will be familiar to anyone already using Cortex Agents, but I'm covering it because it made a real difference in "time to answer" and "answer consistency" on the smart glasses, too.

Cortex Analyst (semantic views): If you pin down definitions such as sales in a semantic view, the agent builds SQL along those definitions. It no longer needs to hunt through tables, and you can narrow the range of what can be asked
Cortex Search: Lets the agent answer by searching documents such as FAQs and manuals

In the Lambda code, all you do is swap the tools and tool_resources passed to agent:run as shown below. Since code_toolset_all isn't used, permission_policy is no longer needed. I've also removed the ORCHESTRATION_PROMPT instruction that narrows the tools (orchestration in instructions). Note that you need to create the semantic view and the Cortex Search service in advance (here I'm using the ones that come with my sample data).

tools = [
    {"tool_spec": {"type": "cortex_analyst_text_to_sql", "name": "sales",
                   "description": "Aggregate orders and sales for the e-commerce site"}},
    {"tool_spec": {"type": "cortex_search", "name": "faq",
                   "description": "Search the e-commerce site's frequently asked questions (FAQ) documents"}},
]
tool_resources = {
    "sales": {"semantic_view": "GLACIERSTYLE_DB.EC_ANALYTICS_SCHEMA.EC_ANALYSIS_SEMANTIC_VIEW",
              "execution_environment": {"type": "warehouse", "warehouse": "COMPUTE_WH"}},
    "faq": {"search_service": "GLACIERSTYLE_DB.EC_ANALYTICS_SCHEMA.SEARCH_FAQ"},
}

Also grant the glasses' role SELECT on the semantic view and USAGE on the Cortex Search service. The role needs SELECT on the tables the semantic view references as well. Step 1 already allowed every table in the schema, though, so these two grants are the only additions.

GRANT SELECT ON SEMANTIC VIEW GLACIERSTYLE_DB.EC_ANALYTICS_SCHEMA.EC_ANALYSIS_SEMANTIC_VIEW TO ROLE G2_READER;
GRANT USAGE ON CORTEX SEARCH SERVICE GLACIERSTYLE_DB.EC_ANALYTICS_SCHEMA.SEARCH_FAQ TO ROLE G2_READER;

If a tool is missing privileges, by default you don't get an error. The answer simply comes back without that tool being used (the reason shows up in the response's warnings). If an answer looks off, check the privileges first.

Here are the results with the same model (claude-sonnet-5-5):

Question	Tool used	Time to answer
What were total sales in 2024?	Cortex Analyst	10.7 seconds
What were the best and worst months for sales in 2024?	Cortex Analyst	10.1 seconds
How much is gift wrapping?	Cortex Search	9.5 seconds
How many days after delivery can I return an item?	Cortex Search	7.2 seconds

Every answer matched the semantic view's definitions and the FAQ content. When I asked Coding Agent the same questions, total sales took 12.2 seconds and the monthly question took 13.9 seconds. So the semantic view cut the wait by about 1.5–4 seconds. Coding Agent checked the list of tables and columns every time, so I think building SQL from the definitions saves that step.

Unlike with Coding Agent, the total sales came back as the total of all orders (¥110,707,792.56), following the semantic view's definition. Being able to decide in the definition which number counts as "sales" is another nice thing about semantic views.

As for Cortex Search, when I asked "How much is gift wrapping at Glacier Style?", it answered from the FAQ documents like this:

Gift wrapping starts at ¥330 per item (tax
included). Standard wrapping is ¥330, large items
are ¥550, and premium wrapping is ¥880. Message
cards, gift labels, and carrier bags are free.

Semantic views for questions with established data definitions, Cortex Search for questions about documents, and Coding Agent for exploratory analysis beyond that: splitting the work this way looks like a good approach.

Cortex Agents Run API (Snowflake Documentation)

Overview of semantic views (Snowflake Documentation)

Cortex Search (Snowflake Documentation)

Things to Watch Out For

This setup is a lot of fun to play with. If you're thinking about using it for work, though, there are a few points to keep in mind.

Pair always_allow with a Least-Privilege Role

always_allow lets the agent run any tool without confirmation. The official documentation cautions that you should make sure every input to the agent is trustworthy, including content pulled in through prompts and web search. It also advises running the agent with a least-privilege role that can access only the data the task needs. Keep in mind that whatever you say to the glasses becomes input to the agent as-is.

Also, the Lambda code tells the agent to use only snowflake_sql_execute and web_search, but that instruction isn't enforced. Depending on the situation, the agent may use other tools. As I mentioned earlier, apply the real restriction through the PAT's role.

Add Business Context with Semantic Views

Coding Agent infers what the data means from the structure of the tables and columns, then aggregates it. So the more business assumptions you share, such as "which orders count as sales" or "how customers are counted," the more accurate the answers get. In the membership tier example earlier, just adding "counted by customer ID" was enough to get an accurate customer count with duplicates removed.

I recommend defining this kind of business context in a semantic view, as in the Going Further section. Once you define metrics such as sales and the relationships between tables, the agent aggregates along those definitions. That gives you more accurate analysis, based on the same criteria no matter how many times you ask.

Latency, Token Usage, and Models

If you don't tell the agent where the data is, it starts by exploring the databases, so answers can take a while. The Lambda in this article gives up after 25 seconds, so I recommend giving the agent hints like DATA_LOCATION (how long the Even app is willing to wait isn't officially documented either).

And the feature that automatically tells the agent "what data lives where" is Cortex Sense, announced at Snowflake Summit 26. It automatically assembles business context from past queries, metadata, semantic views, and more, and hands it to the agent. That way, the agent knows where to look and what to query without inspecting tables and schemas one by one. Cortex Sense is coming very soon. Once it's here, it should answer questions from the glasses faster and more accurately, without you having to spell out where the data lives. I'm really looking forward to it!

Introducing Cortex Sense: Grounded Context for the Data You Never Modeled (Snowflake Blog)

Also, Coding Agent builds its answers with the same rich instructions and tool definitions as CoCo. So when the agent explores a wide range of data, the input token count can grow. That said, caching covers most of the input, and narrowing the exploration scope with DATA_LOCATION or a semantic view cuts down on wasted exploration. You can check usage in SNOWFLAKE.ACCOUNT_USAGE.CORTEX_AGENT_USAGE_HISTORY (it can take up to about an hour for usage to show up), so take a look once you start using it.

Keep in mind that latency also varies a lot by model. The official documentation recommends choosing auto for the model, so the code uses auto as the default. When I compared the same questions, though, auto and claude-sonnet-5 took about 18–25 seconds, and some questions hit the 25-second timeout.

The claude-sonnet-5-5 model I used in the examples (a Public Preview model) isn't on the official Cortex Agents model list yet. Still, it works when you specify it, and it responded faster. For production, choose a model from the official list and check the balance between latency and the Lambda timeout. Also note that Cortex Agents models run on cross-region inference, so you may need to set the account parameter CORTEX_ENABLED_CROSS_REGION.

You Can Also Connect to Cortex AI Gateway

In fact, the same setup also lets you connect to Cortex AI Gateway, which entered Preview on September 15, 2026. Cortex AI Gateway accepts inference requests for a wide range of LLMs (large language models) through a single entry point. It lets you apply access control, tracing, and cost management to those requests.

Cortex AI Gateway (Snowflake Documentation)

You only need to change three things in the Lambda code: the destination URL, the request body format, and how the answer is extracted. Claude models go to /v1/messages in the Anthropic Messages format, and all other models go to /v1/chat/completions in the OpenAI format.

# Claude models go to /v1/messages in the Anthropic Messages format (with the Gateway, you specify the model name)
req = urllib.request.Request(
    f"https://{SNOWFLAKE_HOST}/api/v2/aigateways/snowflake/v1/messages",
    data=json.dumps({
        "model": "claude-sonnet-5-5",
        "max_tokens": 600,
        "system": SYSTEM_PROMPT,
        "messages": [{"role": "user", "content": question}],
    }, ensure_ascii=False).encode("utf-8"),
    headers={"Authorization": auth, "Content-Type": "application/json", "anthropic-version": "2023-06-01"},
    method="POST",
)
with urllib.request.urlopen(req, timeout=25) as resp:
    data = json.load(resp)
answer = "".join(b.get("text", "") for b in data.get("content") or [] if b.get("type") == "text")

You can find the Gateway endpoint with SHOW AI GATEWAYS or DESCRIBE AI GATEWAY SNOWFLAKE. Using the Gateway requires the USAGE privilege on it, which is granted to the PUBLIC role by default. Note that the official documentation recommends short-lived tokens such as OAuth over PATs for Gateway authentication.

Comparing the two with the same question makes the difference clear:

	Coding Agent	Cortex AI Gateway
What it calls	An agent (uses tools such as SQL and web search)	An LLM on its own
Answer to "What were total sales in 2024?"	Aggregates the data and answers with the amount	"I don't have that information, so I can't say"
Time to answer (measured)	10–15 seconds (over 25 seconds with some models)	3–4 seconds (depends on the model)
Best for	Data-driven analysis and checks	Quick responses such as casual chat, brainstorming, and translation

As of now, the official documentation lists three capabilities for Cortex AI Gateway: inference, observability, and cost management. It doesn't describe any way to run tools the way Coding Agent does. Meanwhile, the July 28, 2026 announcement positions Cortex AI Gateway as a foundation for governing access not just to models, but also to tools and MCP (Model Context Protocol) servers. As those capabilities become available, you'll be able to switch between "fast LLM responses" and "data-driven analysis" from a single entry point. I expect that to open up even more possibilities.

Snowflake Advances the Trusted Agentic Enterprise Era with Unified Monitoring and Cost Management (Press Release)

Taking It into the Business

This was just a playful experiment, but while trying it out, I kept picturing situations where it could be useful at work.

One example is workplaces where your hands are full, such as warehouses, stores, and factory maintenance. Imagine asking "How many of this item are left in stock?" or "When was this equipment last inspected?" without stopping what you're doing, and checking the answer at the edge of your vision. You'd no longer need to pull out a device. Store staff could also check a customer's question with Cortex Search while serving them, without flipping through a manual. Salespeople could check "How much has this customer bought this fiscal year?" right before a meeting. Managers could type a question about KPIs (key performance indicators) on their phones during a meeting and quietly glance at the numbers on their glasses. As I mentioned earlier, the display is visible only to the wearer, so not interrupting the flow of the meeting is a big plus.

And these are exactly the situations where Snowflake's governance shines. If you give each person on site their own role, the same setup can "show only the data they're allowed to see." Snowflake also keeps a record of who used it and when.

Conclusion

What did you think? Just by combining the Even G2, a small Lambda function, and Coding Agent, I can now ask Snowflake for analysis by voice! SQL against tables is read-only and runs only within the role's privileges. That makes playful experiments like this one easy to take on, which I really appreciate.

Smart glasses are still a device in the middle of evolving. Even so, this experiment reminded me that the place where we use data isn't just in front of a computer screen. Going forward, I'd like to build on this in various ways: growing an agent that combines semantic views and Cortex Search, as in the Going Further section, and trying out how to split the work as Cortex AI Gateway gets updated. If I build something fun, I'll share it here on the blog again. Stay tuned!

Coding Agent can be called from your own app just by specifying a single tool. Please try challenging yourself with interesting uses of Coding Agent!

Promotion

App Runtime Explained on the Official Snowflake Japan YouTube Channel

The official Snowflake Japan YouTube channel has launched, and it includes a walkthrough of Snowflake App Runtime. If you're interested in building apps right next to your data in Snowflake, this video is for you. It covers what App Runtime is and how to get an app deployed, with a live demo. It's in Japanese, but the demo sections are easy to follow.

Snowflake What's New Updates on X

I share Snowflake What's New updates on X. Follow for the latest insights:

English Version

Snowflake What's New Bot (English Version)

Japanese Version

Snowflake's What's New Bot (Japanese Version)

Change Log

(20261011) Initial post

Original Japanese Article

スマートグラス Even G2 から声で Snowflake にデータ分析を頼んでみた

zenn.dev

Give Your Snowflake App Runtime App a Real Backend with Snowflake Postgres

Tsubasa Kanno — Fri, 24 Jul 2026 14:31:03 +0000

⚠️ Major revision notice (September 2026)

Since the original July 2026 post, Snowflake App Runtime has reached GA and its configuration file layout has changed, so I rewrote the integration steps in September 2026.

The App Runtime updates themselves (GA, and the consolidation into app.yml) are covered in detail in the previous article, Snowflake App Runtime - Deploy Full-Stack Web Apps Right Next to Your Data from a Single Prompt. Two changes matter for the integration steps here:

You can now declare the running app's external access in external_access_integrations in app.yml. The centerpiece of the original post — "attach the EAI with ALTER APPLICATION SERVICE after deploying" — is no longer needed.

Deploys also became declarative, so anything you add with ALTER APPLICATION SERVICE is reverted on the next deploy. I've added that as a new thing to watch out for.

Introduction

In a previous article, Snowflake App Runtime - Deploy Full-Stack Web Apps Right Next to Your Data from a Single Prompt, I introduced a mechanism that lets you deploy a full-stack web app (Next.js and friends) right next to your data — inside Snowflake itself. In that article, I built a sales dashboard that reads and displays analytical tables in Snowflake.

Snowflake is an extremely strong platform for aggregating and analyzing large volumes of data (OLAP). Business apps, on the other hand, often have moments where row-level transactions happen at high frequency — inserting a single request, or updating and deleting statuses one at a time. For these OLTP (online transaction processing) workloads, a database purpose-built for that job is the right fit.

Snowflake offers Snowflake Postgres for exactly this space. Because you can have a PostgreSQL-compatible database inside Snowflake, using it as the backend DB for an app built on App Runtime lets you keep a business app — one where inserts, updates, and deletes happen frequently — entirely within Snowflake's security perimeter.

In recent years, PostgreSQL has been getting renewed attention as the backend DB for AI agents and applications. Behind this is the fact that it is a proven, standard database in the enterprise, while its rich extension ecosystem lets you stretch it to many use cases. Snowflake Postgres makes it possible to ride this trend on top of the Snowflake platform.

In this article, I'll walk through how to connect an App Runtime app to Snowflake Postgres — in the order of benefits, use cases, and concrete steps. I've also included the record of the verification I ran by hand to confirm "does this really connect?"

Want to get hands-on right away?

The explanation of how things work can wait. Integration Steps opens with a prompt you can paste as-is, and CoCo can handle everything from creating the Snowflake Postgres instance through deploying the app and setting up the network permissions.

The verification part in the first half is the record of why the configuration ends up the way it does. Come back to it whenever you want to understand the mechanics.

Note: This article reflects my personal views and does not represent Snowflake's official position.

Note: (September 2026) Snowflake App Runtime reached general availability (GA) on September 1, 2026, and Snowflake Postgres on February 24, 2026. The data mirroring feature discussed later is still in Preview, so it may change significantly.

A Quick Recap of Snowflake App Runtime

Snowflake App Runtime is a platform that lets you deploy web apps like Next.js directly onto Snowflake. No infrastructure to build, no Docker expertise required, and authentication (SSO) is applied automatically. The app runs as a dedicated object called an APPLICATION SERVICE on Snowpark Container Services (SPCS).

Configuration lives in a single app.yml file (version: 2), where you declare the deploy destination, scale, secrets, and external access. The app.yml in this article follows that format.

For a fuller overview and how to build one with CoCo (Cortex Code was renamed CoCo at Snowflake Summit 2026), please see my previous article.

Tsubasa Kanno

Jun 5

Snowflake App Runtime - Deploy Full-Stack Web Apps Right Next to Your Data from a Single Prompt

#snowflake #llm #agents #nextjs

25 min read

In this article, I'll focus on making the data store for that App Runtime app be Snowflake Postgres.

What is Snowflake Postgres?

Snowflake Postgres is a fully managed PostgreSQL service where you can create and manage PostgreSQL instances directly from Snowflake. Here's a quick summary of its characteristics.

Aspect	Details
What it is	A PostgreSQL server running on a dedicated virtual machine managed by Snowflake
Compatibility	Existing PostgreSQL tools, drivers, and ORMs work as-is (`psql`, Prisma, `pg`, etc.)
Versions	Choose from PostgreSQL major versions (16 / 17 / 18)
Best at	High-throughput, high-concurrency transaction processing (OLTP) with writes and updates
How to connect	Connect directly from any PostgreSQL client via host name, port `5432`, and SSL
Status	Generally available (GA, February 24, 2026)

While Snowflake's regular tables are strong at aggregating and analyzing large volumes of data (OLAP), Snowflake Postgres is good at OLTP such as "inserting, updating, and deleting one row at a time." The official documentation positions Postgres as the choice when you need a high-throughput, high-concurrency operational database. Combined with an App Runtime app, this division of labor works as-is.

Official docs: About Snowflake Postgres

Why App Runtime × Snowflake Postgres?

You could point your app's backend at an external DB (say, an OLTP database in another cloud), but choosing Snowflake Postgres brings the following benefits.

Benefit	Details
Everything stays inside the perimeter	Both the app and the DB live inside Snowflake. You can build a business app with writes and updates without letting data leave your organization
Less data movement	Handle OLTP and analytics on the same platform. `pg_lake` and data mirroring make the handoff to the analytics side smooth
Standard Postgres assets work as-is	Use the `pg` driver and ORMs (Prisma, etc.) directly. No special SDK required
Simpler operations	Provisioning, patching, and backups of the DB are left to Snowflake

If you shape it as "transactions in Snowflake Postgres, analysis of the accumulated data in Snowflake tables," you can do both operational work and analytics within a single platform.

One thing I'm especially watching is data mirroring (Preview). It lets you sync writes to Snowflake Postgres into your Snowflake analytics environment in near real time — without building an ETL pipeline.

Under the hood, changes captured by PostgreSQL logical replication are written to Apache Iceberg™ tables through pg_lake. That design gives you a couple of useful properties:

Changes land while preserving the source transaction boundaries, so joining mirrored tables keeps consistency intact
Even with a longer refresh interval configured, the $live view shows the latest state including changes that haven't been merged yet

In other words, you can achieve "OLTP in Snowflake Postgres, analytics in Snowflake" without sacrificing freshness and without ETL. And Snowflake Postgres itself can be stood up quickly, in just a few clicks.

Data mirroring isn't used in this article's steps, but there's a constraint worth knowing if you're planning ahead. It's currently available on AWS and Azure, and BURSTABLE tier instances (BURST_S / BURST_M) are out of scope. The steps below use the lightweight BURST_S, so if mirroring is on your roadmap, pick a STANDARD or HIGHMEM family instead.

Official blog: How we pushed CDC into Postgres, and turned replication into clockwork

Use Cases

Request / entry forms: Business apps that write user input to a DB, such as expense requests or inquiry logging
Approval workflows: Apps that advance a record's state, like request → approval → done
Master data tools: Apps that add and edit product or customer master data from the screen
Stateful internal tools: Apps with frequent updates, such as task management or inventory management

All of these are apps where "inserts, updates, and deletes happen frequently" — cases where an OLTP database fits better than an analytical table.

The Sample App We'll Build

In this article, I'll take the approval workflow from the list above and build an "expense approval app." The key points are:

Beyond just listing (SELECT), it also performs new requests from a form (INSERT) and status updates via approve/reject (UPDATE)
KPI cards (total requests, pending, approved, and so on) let you grasp the situation at a glance
The data store is Snowflake Postgres, and writes are reflected instantly

Here's what the finished app looks like. The frontend is built with Next.js, and pending / approved / rejected states are color-coded with status badges.

From here, I'll connect this app to Snowflake Postgres.

Integration Architecture

Here's the overall picture as a diagram. The App Runtime app (Application Service) connects to Snowflake Postgres by way of an External Access Integration (EAI), which I'll cover below.

The key point is that the connection from the app to Snowflake Postgres is treated as "egress to an external network." This is the crux of the whole thing, so in the next chapter I'll verify it hands-on.

Verification: Can App Runtime Really Reach Snowflake Postgres?

The official documentation states that "external connections from a running App Runtime app require an EAI." But since Snowflake Postgres lives inside the same Snowflake, it's natural to wonder, "do I really need an EAI? Won't it just connect without doing anything?" So I deployed a minimal app to find out.

Verification 1: Without an EAI, even name resolution fails

First, I deployed the app without an EAI and tried to connect to Snowflake Postgres. Looking at the app's logs, here's what I saw.

SELFTEST#1 {"connected":false,"error":"getaddrinfo ENOTFOUND <instance-host>.us-west-2.aws.postgres.snowflake.app"}

getaddrinfo ENOTFOUND — in other words, even the host name resolution fails. By default, the running App Runtime container has no egress to the outside at all, so it can't even resolve the Postgres host name. This made it clear that "an EAI is required."

Verification 2: With an EAI, the behavior changes

Next, I created an EAI that allows the Snowflake Postgres host:port, declared it in external_access_integrations in app.yml, and redeployed (I'll show the concrete SQL in the steps later). The same app's log then changed like this.

SELFTEST#12 {"connected":false,"error":"timeout expired"}

The error changed from ENOTFOUND to timeout expired. Name resolution now succeeds and the connection is being attempted — but this time it times out. That's because Snowflake Postgres is not accepting the connection from the app.

Snowflake Postgres rejects inbound connections by default. To allow one, you need to attach a network policy that includes a network rule in POSTGRES_INGRESS mode to the instance. The official documentation is explicit that without a network policy, the instance can't accept incoming connections. So the integration requires both of the following permissions:

The egress permission on the app side (EAI)
The ingress permission on the Postgres side (network policy)

Verification 3: Which IPs to allow — Snowflake's egress IP ranges

What's left is "which IPs to allow on the Postgres ingress." The thing to keep in mind here is that the IP address Snowflake uses when it connects out is not fixed — it's dynamic. So rather than allowing a single specific IP, you need to know the range of egress IPs Snowflake uses.

The function that tells you this is SYSTEM$GET_SNOWFLAKE_EGRESS_IP_RANGES. It returns the egress IPs Snowflake uses when it reaches out, as stable CIDR ranges.

The uses the official documentation lists are three: external access from UDFs and stored procedures, SPCS external access, and integration with IP-restricted Git servers. App Runtime isn't named in that list, but because the app runs as an APPLICATION SERVICE on SPCS, I was able to confirm in this verification that allowing the same ranges does get you connected.

Stable egress IP addresses are generally available (GA) on AWS commercial regions and in Preview on Azure. Also, in Azure regions this function returns JSON with inline comments, so pass the argument to suppress them: PARSE_JSON(SYSTEM$GET_SNOWFLAKE_EGRESS_IP_RANGES(TRUE)).

SELECT
  value:"ipv4_prefix"::VARCHAR   AS ip_cidr_range,
  value:"effective"::TIMESTAMP   AS effective_date,
  value:"expires"::TIMESTAMP     AS expiration_date
FROM TABLE(FLATTEN(INPUT => PARSE_JSON(SYSTEM$GET_SNOWFLAKE_EGRESS_IP_RANGES())));

When you run it, you get CIDR ranges and expiration dates per region.

IP_CIDR_RANGE      | EFFECTIVE_DATE          | EXPIRATION_DATE
<CIDR range 1>     | 2025-08-01 00:00:00.000 | 2026-10-22 ...
<CIDR range 2>     | 2025-08-01 00:00:00.000 | 2026-10-22 ...

When I allowed these ranges on the Postgres ingress, the app connected to Snowflake Postgres without issue, and the writes succeeded too. Even though the source IP is dynamic, allowing the range keeps the connection stable.

Note: These ranges have an expiration. As the expiry approaches, new ranges are added, so for production I'd recommend setting up a mechanism to re-fetch them periodically and update the network policy. For details, see the official docs: Protect request inbounds with Snowflake egress IPs.

With that, the correct configuration comes into view. From the next chapter, I'll summarize it as concrete steps.

Integration Steps

Through the verification, the pieces needed for the integration are settled (the EAI on the app side, the ingress permission on the Postgres side). There are two broad ways to proceed. Let me start with the fastest route.

The Fastest Route: Let CoCo Handle It All

The quickest approach is to tell CoCo Desktop (or the CLI) not only to create the app, but also to prepare Snowflake Postgres, create the EAI, and set up the ingress permission — all in one go — and have the snowflake-apps skill run it end to end.

When I wrote the original post, attaching the EAI to a running app was a separate task after deploying, so the order of operations needed care. Now that you can declare the EAI in external_access_integrations in app.yml, it's enough to prepare the EAI first and then deploy.

Create the Snowflake Postgres instance (and get its host)
Store the credentials in a Secret
Create the egress network rule and the EAI
Build the app with CoCo, declaring the EAI and Secret in app.yml
snow app deploy
Allow the egress IP ranges with POSTGRES_INGRESS
Connection established — verify it works

The key is to pin down the Postgres host and the EAI before you deploy. Once the values that go into app.yml are settled, a single deploy is all it takes.

If you tell CoCo this order and configuration up front in the prompt, it will proceed without getting lost. For this expense approval app, the prompt would look something like this.

/snowflake-apps
Build an "expense approval app" in Next.js with Snowflake Postgres as the backend.

[Features]
- List requests, submit a new request from a form (INSERT), and update status via approve/reject (UPDATE)
- KPI cards for total requests, pending, approved, and so on
- Color-code the status (Pending / Approved / Rejected) with badges

[Deploy & connection plan]
- If needed, create the Snowflake Postgres instance from scratch (use its host if one already exists)
- Write app.yml in the version: 2 format, with name / database / schema / query_warehouse spelled out
- Deploy the app to the APP_DB.APP schema
- Create a Snowflake Secret (APP_DB.APP.PG_CRED) and read it by mounting it via secrets in app.yml
- Pass the host, port (5432), and DB name via environment_variables in app.yml
- Enable SSL for the connection
- Before deploying, create an EAI that allows egress to Snowflake Postgres,
  and list its name under external_access_integrations in app.yml
- Finally, take the IP ranges from SYSTEM$GET_SNOWFLAKE_EGRESS_IP_RANGES and
  set them as a POSTGRES_INGRESS network policy on the Postgres instance

The key is to state up front that it should "mount and read the Secret," "declare the EAI in app.yml," and "allow ingress with the egress IP range." Skip these, and the credential handoff or network permissions tend to fall through the cracks — leaving you stuck wondering why it won't connect after deploy.

Just a few rounds of back-and-forth with CoCo based on this prompt, and the whole configuration for this article (deploying the app, the EAI, and the ingress permission) comes together. For everyday use, this fastest route alone is plenty.

So, what is CoCo actually doing behind the scenes? In the next chapter, I'll build the same thing by hand, one piece at a time, to see what's inside. If you're not interested in the internals and just want it to work, you can skip the rest.

Doing It Step by Step

If you do it yourself one step at a time, the flow looks like this. It's also a useful reference when you want to fold this into an existing workflow.

Create the Snowflake Postgres instance
Check the connection info (host / 5432 / SSL)
Store the credentials in a Secret
Create the egress network rule and the EAI
Implement the app and app.yml (EAI / Secret / environment variables)
snow app deploy
Allow the Postgres ingress (egress IP ranges)
Verify it works

The SQL below assumes a database/schema to hold the network rules and Secret (APP_DB.APP in the examples) and a role that can create EAIs (ACCOUNTADMIN in the examples).

Step 1: Create the Snowflake Postgres Instance

First, create the Snowflake Postgres instance. You can do this in SQL or in the Snowsight GUI.

CREATE POSTGRES INSTANCE MY_PG_INSTANCE
  COMPUTE_FAMILY = 'BURST_S'
  STORAGE_SIZE_GB = 10
  AUTHENTICATION_AUTHORITY = POSTGRES
  POSTGRES_VERSION = 17
  COMMENT = 'Backend DB for App Runtime app';

When it's created, the connection info (password) for the snowflake_admin user is returned. This info is not shown again, so be sure to keep it somewhere safe. Creation takes a little while, so wait until the state becomes READY.

DESCRIBE POSTGRES INSTANCE MY_PG_INSTANCE
  ->> SELECT "value" AS state FROM $1 WHERE "property" = 'state';

Step 2: Check the Connection Info (Host Name)

The host name your app connects to is available via DESCRIBE POSTGRES INSTANCE.

DESCRIBE POSTGRES INSTANCE MY_PG_INSTANCE
  ->> SELECT "value" AS host FROM $1 WHERE "property" = 'host';

You'll get a host name like <instance-id>.<...>.us-west-2.aws.postgres.snowflake.app. Connections use port 5432 and SSL is required.

Prepare the table at this stage. There are two ways to do it.

Create it from a local PostgreSQL client (psql, etc.): In this case, you first need to allow your local IP in POSTGRES_INGRESS the same way as PG_INGRESS_LOCAL in Step 7 (finish the network permission before connecting).
Create it in the app's initialization or a migration: Have the app itself run CREATE TABLE after deploy.

Either way, note that this CREATE TABLE runs against Postgres, not in a Snowflake worksheet. The DESCRIBE POSTGRES INSTANCE calls in Steps 1–2 are Snowflake SQL, but from here on it's Postgres dialect.

-- Example: expense requests table (run this against Postgres)
CREATE TABLE IF NOT EXISTS expense_requests (
  id         SERIAL PRIMARY KEY,
  applicant  TEXT NOT NULL,
  department TEXT NOT NULL,
  category   TEXT NOT NULL,
  amount     INTEGER NOT NULL,
  purpose    TEXT NOT NULL,
  status     TEXT NOT NULL DEFAULT 'pending',
  created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  updated_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

Step 3: Store the Credentials in a Snowflake Secret

You want to avoid hardcoding the password in the app, so store the credentials in a Snowflake Secret. App Runtime can mount this Secret into the container via app.yml.

CREATE OR REPLACE SECRET APP_DB.APP.PG_CRED
  TYPE = PASSWORD
  USERNAME = 'snowflake_admin'
  PASSWORD = '<YOUR_POSTGRES_PASSWORD>'
  COMMENT = 'Snowflake Postgres credentials for the app';

For production, I'd recommend preparing a role/user with least-privilege access for the purpose at hand, and using those credentials.

Step 4: Create the egress Network Rule and EAI

So the app can reach out to the Snowflake Postgres host:port, create an egress network rule and an External Access Integration (EAI). Specify port 5432.

-- Network rule allowing egress to Snowflake Postgres
CREATE OR REPLACE NETWORK RULE APP_DB.APP.PG_EGRESS_RULE
  MODE = EGRESS
  TYPE = HOST_PORT
  VALUE_LIST = ('<instance-host>.us-west-2.aws.postgres.snowflake.app:5432');

-- EAI bundling the rule above
CREATE OR REPLACE EXTERNAL ACCESS INTEGRATION APP_PG_EAI
  ALLOWED_NETWORK_RULES = (APP_DB.APP.PG_EGRESS_RULE)
  ENABLED = TRUE;

Note that since the credential Secret is mounted and read from app.yml in the next Step, you don't need to include the Secret in this EAI (ALLOWED_AUTHENTICATION_SECRETS). The EAI is solely responsible for permitting the egress path.

Step 5: Implement the App and `app.yml`

On the app side, connect with the standard pg driver. Read the credentials from the Secret files mounted in Step 3 (/secrets/PG_CRED/username, /secrets/PG_CRED/password), and receive the host and port from environment variables — that keeps things easy to manage. SSL is required.

// lib/db.ts (excerpt of the connection part)
import { readFileSync } from "node:fs";
import { Pool } from "pg";

// Read credentials from the Secret mounted via app.yml
function readSecret(name: string): string {
  return readFileSync(`/secrets/PG_CRED/${name}`, "utf8").trim();
}

export const pool = new Pool({
  host: process.env.PGHOST,
  port: Number(process.env.PGPORT ?? 5432),
  user: readSecret("username"),
  password: readSecret("password"),
  database: process.env.PGDATABASE ?? "postgres",
  ssl: { rejectUnauthorized: false }, // SSL required (equivalent to sslmode=require)
});

If you want stricter server certificate verification for SSL, you can specify the certificate returned by DESCRIBE POSTGRES INSTANCE as the CA.

The host, port, target DB, the Secret to mount, and the EAI you created in Step 4 all go into app.yml. This is the crux of the integration.

version: 2

name: MY_APP
database: APP_DB
schema: APP
query_warehouse: APP_WH

environment_variables:
  - name: PGHOST
    value: "<instance-host>.us-west-2.aws.postgres.snowflake.app"
  - name: PGPORT
    value: "5432"
  - name: PGDATABASE
    value: "postgres"
secrets:
  - name: PG_CRED
    secret: APP_DB.APP.PG_CRED

# EAI for the running app to reach out to Snowflake Postgres
external_access_integrations:
  - APP_PG_EAI

The thing to watch here is that build time and run time use different fields.

Field	Timing	What it's for here
`build_eai`	Build time	npm and Google Fonts are allowed by default. Not needed here
`external_access_integrations`	Run time	This is the one you need to reach Snowflake Postgres

The original post predated this run-time field, so the EAI had to be attached with ALTER APPLICATION SERVICE after deploying. Now that it lives in the manifest, it's wired up as part of the deploy.

Step 6: Deploy

Deploy to App Runtime with snow app deploy. Uploading the source → remote build → creating the APPLICATION SERVICE all proceed automatically, and the EAI you declared in app.yml is wired up at the same time.

snow app deploy

If you want to check the service state after deploying, use:

SHOW APPLICATION SERVICES IN SCHEMA APP_DB.APP;

⚠️ Since the move to app.yml, deploys are declarative. Every snow app deploy applies the whole manifest with CREATE OR ALTER APPLICATION SERVICE ... SPECIFICATION, so any field you leave out goes back to its default.

That means even if you add an EAI afterwards with ALTER APPLICATION SERVICE, it comes off again on the next deploy unless external_access_integrations is in your app.yml. This is the classic "it was working, then I deployed and it stopped connecting" case, so always keep connection settings in the manifest.

Step 7: Allow the Snowflake Postgres Ingress

Finally, allow inbound connections from the app on the Snowflake Postgres side. As we saw in the verification, the source IP is not fixed, so allow the egress IP range you get from SYSTEM$GET_SNOWFLAKE_EGRESS_IP_RANGES.

-- 1. Check the egress IP ranges
-- On Azure, pass TRUE to suppress the inline comments
SELECT value:"ipv4_prefix"::VARCHAR AS ip_cidr_range
FROM TABLE(FLATTEN(INPUT => PARSE_JSON(SYSTEM$GET_SNOWFLAKE_EGRESS_IP_RANGES())));

-- 2. Ingress rule for the app (App Runtime)
CREATE OR REPLACE NETWORK RULE APP_DB.APP.PG_INGRESS_APP
  MODE = POSTGRES_INGRESS
  TYPE = IPV4
  VALUE_LIST = ('<fetched CIDR range>');

-- 3. Ingress rule for your local client (used for the psql checks)
CREATE OR REPLACE NETWORK RULE APP_DB.APP.PG_INGRESS_LOCAL
  MODE = POSTGRES_INGRESS
  TYPE = IPV4
  VALUE_LIST = ('<your global IP>/32');

-- 4. Bundle both into a network policy
CREATE OR REPLACE NETWORK POLICY MY_PG_POLICY
  ALLOWED_NETWORK_RULE_LIST = (
    'APP_DB.APP.PG_INGRESS_APP',
    'APP_DB.APP.PG_INGRESS_LOCAL'
  );

-- 5. Attach it to the instance
ALTER POSTGRES INSTANCE MY_PG_INSTANCE SET NETWORK_POLICY = 'MY_PG_POLICY';

What matters here is putting both the app rule and the local rule into the policy. Attaching a policy replaces what was there before, so an app-only policy leaves you unable to check from psql.

Because these ranges can change and expire, if the app suddenly can't connect one day, the first thing to check is re-fetching SYSTEM$GET_SNOWFLAKE_EGRESS_IP_RANGES and updating the network rule to the latest ranges. Note also that network policy changes can take a few minutes to take effect — if it won't connect right after you set it, wait a little and try again.

Step 8: Verify It Works — Confirm Writes Land in Snowflake Postgres

At this point, the app can read from and write to Snowflake Postgres. Let's confirm that "the app's operations really do change the data in Snowflake Postgres."

First, submit a new expense request from the app's form (INSERT).

At that moment, on the Snowflake Postgres side, a record has actually been added. Peeking at the same table from outside App Runtime (e.g., a local client) shows the new row.

 id |  applicant   | category | amount | status
----+--------------+----------+--------+---------
  6 | Maria Lopez  | Travel   |   340  | pending   ← the row submitted from the app

Next, let's "approve" this request in the app (UPDATE). The status on the Postgres side flips instantly.

 id |  applicant   | status   | updated_at
----+--------------+----------+------------
  6 | Maria Lopez  | approved | 12:32:55    ← updated by the approve action

Just like that, submissions and approvals in the App Runtime app are reflected directly in the Snowflake Postgres data. I confirmed that a "writable business app running right next to the data" is actually working.

Things to Watch Out For

Here are the points I found worth knowing up front so you don't stumble when you actually wire this up.

1. Write the running app's EAI in `app.yml`

The egress EAI for the running app (Application Service) goes in external_access_integrations in app.yml. build_eai is a build-time-only field, so putting it there won't let the running app reach out. Having separate fields for build time and run time is the easy spot to mix up.

2. Settings added with `ALTER APPLICATION SERVICE` are reverted on deploy

Since the move to app.yml, deploys are declarative and each one applies the whole manifest. So an EAI or an auto-suspend setting you add later in SQL comes off on the next deploy unless it's in the manifest. Using ALTER for a quick experiment is fine, but fold it back into app.yml afterwards.

3. Connecting needs both egress and ingress permissions

Neither the egress (EAI) on the app side alone, nor the ingress (network policy) on the Postgres side alone, is enough. The connection is established only when both are set.

4. The source IP is not fixed

The App Runtime source IP is not fixed, so allow the range from SYSTEM$GET_SNOWFLAKE_EGRESS_IP_RANGES rather than an individual IP. The ranges have an expiration, so for production, set up a mechanism for periodic updates.

5. SSL is required

Connections to Snowflake Postgres require SSL. If SSL isn't enabled on the driver side, you can't connect.

6. An app deployed to a personal database can't be shared

If you don't specify a deploy target, the app may be placed in a personal database (USER$...) and can't be shared with other roles. If you have internal sharing in mind, specify a regular database/schema. Note that app.yml won't fill in database / schema from your connection, so spelling them out in the manifest is the safe move.

7. Mind the instance family if mirroring is on your roadmap

The examples here use the lightweight BURST_S, but the BURSTABLE tier is out of scope for data mirroring. You can change the family later with ALTER POSTGRES INSTANCE ... SET COMPUTE_FAMILY, but if you're thinking "get the app running now, wire up analytics later," picking a STANDARD or HIGHMEM family from the start means less rework.

Conclusion

What did you think of the App Runtime × Snowflake Postgres integration?

Let's recap the key points of this article:

With an App Runtime app + Snowflake Postgres, you can keep a full-fledged, write-heavy business app entirely within Snowflake's security perimeter
The connection from the app to Snowflake Postgres is treated as egress, so an EAI is required (without it, even name resolution fails)
The EAI for the running app goes in external_access_integrations in app.yml. Deploys are declarative, so adding it later in SQL means it comes off on the next deploy
On the Postgres side, allow inbound connections with a POSTGRES_INGRESS network policy. Since the source IP is not fixed, allow the range from SYSTEM$GET_SNOWFLAKE_EGRESS_IP_RANGES
When building with CoCo, it goes smoothly if you convey the order — "create Postgres → create the Secret → create the EAI → build the app (declaring the EAI in app.yml) → deploy → allow ingress" — up front in the prompt

I was able to confirm the "running a writable business app right next to your data" setup all the way through to INSERTs and UPDATEs landing in Postgres behind an authenticated URL. Request forms and master data management are good places to start. I'd love for you to get hands-on and share what you discover. Let's grow this new app-building experience together!

Promotion

App Runtime Explained on the Official Snowflake Japan YouTube Channel

The official Snowflake Japan YouTube channel has launched, and it already includes a walkthrough of Snowflake App Runtime — the foundation this article builds on. The video covers what App Runtime is and how to get an app deployed, with a live demo. It's in Japanese, but the demo sections should still be easy to follow alongside this article.

Snowflake What's New Updates on X

I share Snowflake What's New updates on X. Follow for the latest insights:

English Version

Snowflake What's New Bot (English Version)

Japanese Version

Snowflake's What's New Bot (Japanese Version)

Change Log

(20260724) Initial post
(20260830) Added the App Runtime walkthrough from the official Snowflake Japan YouTube channel
(20260923) Major revision. Reflected App Runtime's GA (September 1, 2026). Rewrote the integration around declaring the running app's EAI in external_access_integrations in app.yml, and dropped the original post's centerpiece — attaching it with ALTER APPLICATION SERVICE. Added a new caveat for declarative deploys (settings added in SQL are reverted on the next deploy). Consolidated the walkthrough from nine steps to eight, and replaced the CoCo prompt and the flow outlines. Split the Postgres ingress rule into app and local rules so the psql checks keep working. Noted data mirroring's availability (AWS / Azure, BURSTABLE tier out of scope) and the Azure specifics of the egress IP function

Original Japanese Article

Snowflake App Runtime のバックエンドを Snowflake Postgres にして本格的な業務アプリを作る

zenn.dev

Snowflake App Runtime - Deploy Full-Stack Web Apps Right Next to Your Data from a Single Prompt

Tsubasa Kanno — Fri, 05 Jun 2026 10:26:48 +0000

⚠️ Major revision notice (September 2026)

Snowflake App Runtime has reached GA since this article was first published in June 2026, and the configuration file layout changed substantially along the way. So I rewrote this article from top to bottom in September 2026. Here's what changed:

Snowflake App Runtime became generally available (GA) on September 1, 2026. Everything written on the assumption of Public Preview has been revisited.

Configuration has consolidated into a single app.yml manifest (version: 2). The snowflake.yml that the first version centered on is now treated as legacy.

You can now set scale (min_instances / max_instances) and auto-suspend (auto_suspend_secs) in app.yml, so I added a dedicated section for it.

Deploy targets for switching between dev / stage / prod (targets / --target) are now supported, so I added a section for those too.

I corrected how Caller's Rights is configured. The first version said you needed a setting in app.yml; in fact the correct shape is a flag in your code combined with GRANT CALLER.

The snow app deploy flags, the required Snowflake CLI version, and other details that have moved on since the first version are now aligned with the current spec.

Introduction

Snowflake App Runtime, announced at Snowflake Summit 2026, reached general availability (GA) in September 2026. It's one of the features I've been keeping a close eye on since it was first announced.

Have you ever felt one of these frustrations?

Your data is neatly organized inside Snowflake, but the web app that surfaces it runs somewhere else entirely
To ship an app, you have to stand up Docker, infrastructure, and an auth layer every single time
You just want to build an internal tool, but you end up copying data out to the app side, and governance goes out the window

Snowflake App Runtime answers exactly these pain points. In a nutshell, it lets you deploy a full-stack web app (Next.js and friends) right next to your data — inside Snowflake itself. No infrastructure to build, authentication handled for you, and no data movement.

On top of that, when you pair it with the AI coding agent Snowflake CoCo (formerly Cortex Code), you can go from a prompt to a scaffolded app and all the way to deployment.

Note: Cortex Code was renamed CoCo at Snowflake Summit 2026, so I'll use CoCo throughout this article. That said, parts of the official documentation and some URLs still carry the Cortex Code name.

Configuration now lives in a single file: app.yml with version: 2. I'll walk through the current way to build one — starting from the overview, then the snowflake-apps skill bundled with CoCo, and on to how you write scale and auto-suspend settings.

Want to get hands-on right away?

The explanation of how things work can wait. Once you have CoCo Desktop, a recent Snowflake CLI, and Node.js 22 or later on your machine, skip ahead to Hands-On: Building a Sales Dashboard from a Prompt. Three steps — hand over a prompt, check it locally, deploy — and you land on an authenticated URL.

How to write app.yml, along with the scale and auto-suspend settings, is worth coming back to in "Basic Workflow" when you're ready to run the app in production.

Note: This article reflects my personal views and does not represent Snowflake's official position.

What is Snowflake App Runtime?

Snowflake App Runtime is a platform for building and deploying full-stack web applications on Snowflake. The official documentation describes it like this:

Snowflake App Runtime lets you go from an idea to a live, deployed web application in minutes. No infrastructure to provision, no credentials to configure, no Docker expertise required.

Here's a summary of its characteristics:

Aspect	Details
Status	Generally available (GA). It moved from Public Preview to GA on September 1, 2026
Supported stack	Builds Node.js apps (especially Next.js). Python support is also planned
Runtime	Runs as a dedicated `APPLICATION SERVICE` object on Snowpark Container Services (SPCS)
Authentication	Snowflake SSO is applied automatically — no auth code required
Data access	Directly queries data in the same Snowflake account. No data copies, no external API layer
Public URL	An authenticated URL in the form `https://<id>-<org>-<account>-<region>.snowflakecomputing.app/` is issued automatically
Where you can use it	AWS, Azure, and Google Cloud commercial regions. Trial accounts and government regions are out of scope

Here's a point that's easy to trip over. When you hear "runs on SPCS," you might picture the SPCS services you know — the ones where you build a container yourself and run CREATE SERVICE. But App Runtime uses a different object type, APPLICATION SERVICE. The big difference is that instead of writing a service specification (spec) file yourself, it deploys from a versioned package.

The official docs spell this out:

Unlike a Snowpark Container Services service, an Application Service deploys from a versioned package rather than from a user-supplied service specification.

So when you want to check a deployed app, just remember to use SHOW APPLICATION SERVICES rather than SHOW SERVICES (I'll come back to this in the "Things to Watch Out For" section).

Architecture at a Glance

Here's the flow of how App Runtime gets an app running (this uses a Next.js project as the example, but the basic flow is the same for any Node.js app):

All the developer does is "write the app code and run snow app deploy." Building the container, placing it on SPCS, and wiring up authentication are all handled by Snowflake.

Official docs: About Snowflake App Runtime

Three Ways to Build Apps — How to Choose

There are currently three main ways to build apps on Snowflake. Plenty of people wonder "which one should I actually use?", so let's sort out where each fits.

	Streamlit in Snowflake	Snowflake App Runtime	Native App Framework
Primary language	Python	JavaScript / TypeScript	Any (packaged for distribution)
Best at	Data exploration, dashboards, analyst self-serve	Custom UI, multi-step business flows, rich web experiences	Distributing/monetizing apps and data across accounts
Frontend	No need to write it (handled for you)	Fully customizable	Fully customizable
Main use	Internal analytics tools	Internal web apps in general	Marketplace publishing, etc.

The official docs position Streamlit and App Runtime like this:

Streamlit in Snowflake: Python-first and guardrailed. You can build a polished data app without writing any frontend code
Snowflake App Runtime: The full power of the web. Ideal when you need custom UI or rich interactions that leverage the React / Next.js ecosystem

Put simply: Streamlit when you want to visualize data quickly, App Runtime when you want a web app with elaborate UI or business workflows, and Native Apps when you want to distribute to other companies or accounts.

My past articles on Snowflake apps & UI (some details may be a bit dated)

Snowflake Data UI Guide - Choose the Right Tool for Every Analytics Use Case
SiS Container Runtime - Run Streamlit Apps at a Fraction of the Cost

One note on scope: what I build in this article is a dashboard that reads Snowflake tables and displays them. If you want a business app with frequent writes — a request form or an approval workflow, say — putting Snowflake Postgres behind it as the backend is the better fit. I cover that configuration in the follow-up article.

Give Your Snowflake App Runtime App a Real Backend with Snowflake Postgres

A Closer Look at the snowflake-apps Skill (CoCo)

This is the heart of the article. Snowflake App Runtime works on its own, but pairing it with CoCo makes the experience much smoother.

CoCo ships with a skill called snowflake-apps (a workflow definition specialized for a particular task), and it supports App Runtime app creation end to end.

Prerequisite: Setting Up CoCo Desktop

This article assumes the CoCo Desktop native app for Mac / Windows. If you haven't set it up yet, see the official documentation first:

Official docs: Cortex Code Desktop
Official docs: Building apps (Cortex Code Desktop)

Since you'll be running a dev server locally, things go more smoothly if you have Node.js 22 or later and a recent Snowflake CLI on your machine.

What the snowflake-apps Skill Takes Care Of

The snowflake-apps skill does more than just "scaffold an app." Following App Runtime's conventions, it sets up a foundation like this:

What the skill provides	Role
Next.js template	Copies a scaffold with Next.js + React + snowflake-sdk. No need to start from zero
`lib/snowflake.ts`	A Snowflake connection helper. Just call `querySnowflake()` to run SQL
`app.yml`	Auto-generates a single manifest covering the deploy destination, build commands, and display metadata (title, description, icon)
Authentication conventions	Built-in patterns for switching between Owner's Rights and Caller's Rights

Accessing Data with querySnowflake()

querySnowflake(), provided by lib/snowflake.ts, is the function you use to run SQL from the app's server side (server components or API routes) and fetch data from Snowflake. The helper takes care of authentication and connection pooling, so you can fetch data by simply calling querySnowflake().

import { querySnowflake } from "@/lib/snowflake"

// Run SQL from the app's server side to fetch data
const rows = await querySnowflake("SELECT * FROM MY_DB.MY_SCHEMA.SALES")

When you pass user input into SQL, use bind variables rather than string concatenation. This is the basic defense against SQL injection.

const rows = await querySnowflake(
  "SELECT * FROM ORDERS WHERE CUSTOMER_ID = ? AND STATUS = ?",
  { binds: [customerId, status] }
)

For work that might run longer than a few seconds — aggregations, large scans, stored procedure calls — there's querySnowflakeLongRunning(). It submits the statement, waits for it to finish, and then returns the rows, so you can write it without worrying about timeouts.

const rows = await querySnowflakeLongRunning("CALL MY_LONG_JOB()")

For how data access permissions are handled (the authentication mode), you have two choices. This is a spot that's easy to get confused about if you're not used to Snowflake's privilege model, so let's lay it out in a table (Owner's Rights / Caller's Rights are also concepts that come up frequently on the SnowPro certification exams!).

Mode	Whose privileges run the SQL	When to use
Owner's Rights (default)	The app's execution role (on a standard database, the role that owns the app)	Shared dashboards / reference data where all users see the same thing
Caller's Rights	The signed-in user's own privileges	When data should differ per user, or you want row-level security to apply

To use Caller's Rights, you just add an option to the query.

// Run SQL with the signed-in user's privileges (row-level security and so on apply)
const rows = await querySnowflake(
  "SELECT * FROM MY_DB.MY_SCHEMA.SENSITIVE_TABLE",
  { callersRights: true }
)

Note: Caller's Rights is available automatically on an Application Service. You don't need to write any setting for it in app.yml.

That alone isn't enough to make it work, though. App Runtime's Caller's Rights sits on top of a mechanism called Restricted Caller's Rights, and data becomes readable only when both pieces are in place: the calling user's own privileges and the caller grants held by the app's execution role. So an administrator needs to issue GRANT CALLER ahead of time, like this:

GRANT CALLER USAGE ON DATABASE MY_DB TO ROLE SERVICE_OWNER_ROLE;
GRANT CALLER USAGE ON SCHEMA MY_DB.MY_SCHEMA TO ROLE SERVICE_OWNER_ROLE;
GRANT CALLER SELECT ON ALL TABLES IN SCHEMA MY_DB.MY_SCHEMA TO ROLE SERVICE_OWNER_ROLE;

If you want tables created later to be covered as well, use GRANT INHERITED CALLER instead of GRANT CALLER. That form applies to both current and future objects.

GRANT INHERITED CALLER SELECT ON ALL TABLES IN SCHEMA MY_DB.MY_SCHEMA TO ROLE SERVICE_OWNER_ROLE;

Note that running these GRANT CALLER statements requires the account-level MANAGE CALLER GRANTS privilege. If you hit a privilege error, that's the first place to check.

In other words, Caller's Rights is a two-part setup: pass { callersRights: true } in your code, and issue GRANT CALLER on the administrator side. Being able to choose "whose privileges this runs as" per query, while administrators keep the scope bounded, is a genuinely convenient point from a governance standpoint.

No connection string, no external auth layer. Call querySnowflake() from the server side and you can read tables in the same account. Only when you want what each user sees to differ do you need those separate GRANT CALLER statements from an administrator.

Official docs: Query Snowflake / Restricted caller's rights

The `snow app` CLI Command Surface

Deployment and lifecycle management are done with the Snowflake CLI's snow app command. snow app handles both Native Apps and App Runtime, and routes automatically based on your project layout.

That said, you don't need to memorize these commands one by one. Basically, CoCo gets the context from the snowflake-apps skill and runs the right commands for you, so all you have to do is say "deploy it." I'm listing the main commands here just so you understand "what's happening behind the scenes."

The main subcommands are as follows:

Command	Role
`snow app setup`	Initialize the project and generate `app.yml`
`snow app bundle`	Resolve the artifacts to upload, locally (no connection required)
`snow app validate`	Validate `app.yml` and confirm the deploy destination exists
`snow app deploy`	Run upload → remote build → deploy in one shot
`snow app open`	Open the deployed app in a browser
`snow app events --last N`	Fetch the app's container logs
`snow app teardown`	Remove the app and related resources

snow app deploy is made up of three phases — upload, build, and deploy — and you can run just one of them with a flag.

Flag	What runs
(none)	All three phases, in order
`--upload-only`	Upload the source only
`--build-only`	Remote build only
`--promote-only`	Skip upload and build, and apply the manifest only

Note: When you want to skip the build and reflect only configuration changes, use --promote-only. The --deploy-only you'll see in older material is treated as a deprecated alias for the same thing. It still works, but --promote-only is the one to reach for going forward.

Official docs: Snowflake Apps CLI commands

Note: Writing your deploy configuration in app.yml requires a recent Snowflake CLI. You can check with snow helpers check-version (more on this in "Things to Watch Out For" below).

Basic Workflow

The basic flow for getting an App Runtime app up and running is these five steps.

One app.yml for Everything

It used to be a two-file arrangement: the deploy destination in snowflake.yml, and build settings alone in app.yml. Today it's all consolidated into app.yml. The key point is to put version: 2 at the top. Without that one line, the CLI won't read the deploy configuration in app.yml at all.

Running snow app setup generates this app.yml. The minimal form looks like this:

version: 2

name: SALES_DASHBOARD            # Application Service name
database: SNOWFLAKE_APPS         # destination database
schema: PUBLIC                   # destination schema
query_warehouse: MY_QUERY_WH     # warehouse the app uses for queries

Only those five keys are required (version / name / database / schema / query_warehouse). Add display metadata and build commands on top of that, and you get something like this:

version: 2

name: SALES_DASHBOARD
database: SNOWFLAKE_APPS
schema: PUBLIC
query_warehouse: MY_QUERY_WH

# App title, description, and icon
label: Sales Dashboard
description: An app that visualizes online retail sales
icon: public/icon.svg

# Patterns excluded from upload
ignore:
  - node_modules
  - .env*
  - .next
  - .git

# Build and start commands
install:
  commands:
    - [npm, ci]
build:
  commands:
    - [npm, run, build]
run:
  command: [node, .next/standalone/server.js]

If you omit install / build / run, they default to npm ci / npm run build / npm start respectively. You declare run explicitly when you need a start command that differs from the default — for example running Next.js with output: 'standalone'. Note that those three keys are top-level only (putting them under targets, covered below, has no effect).

Note: Title, description, and icon go in the top-level label / description / icon. The profile: block used by the older format is no longer read, and leaving it in place means the title, description, and icon disappear on every deploy. When migrating an existing project, don't forget to fix this.

One more thing: deploying with app.yml is declarative. The whole manifest is applied each time, so any field you don't write goes back to its default. That property comes up again in the next section, so it's worth keeping in the back of your mind.

Official docs: app.yml manifest for Snowflake App Runtime / Migrate from snowflake.yml to app.yml

Scale and Auto-Suspend in app.yml

Instance counts and stopping on idle are just a few lines in app.yml.

# Add instances as traffic grows
min_instances: 2
max_instances: 5

# Auto-suspend after 15 minutes of idle time, and resume when a request arrives
auto_suspend_secs: 900
auto_resume: true

Here's what each one means, along with its default:

Setting	Meaning	Default	Constraint
`min_instances`	Fewest instances to run while the app is up	`1`	At least 1
`max_instances`	Most instances to scale up to	`1`	At least `min_instances`, and no more than 10
`auto_suspend_secs`	Auto-suspend after this many idle seconds	`0` (disabled)	If non-zero, must be 300 or more
`auto_resume`	Whether to resume automatically when a request arrives	`true`	—

Set max_instances higher than min_instances and Snowflake adds and removes instances based on CPU utilization. It's the same CPU-based autoscaling mechanism as SPCS.

The thing to internalize here is that you're billed per node, not per instance. Multiple instances are packed onto the same node while there's room, and a new node is added only once the existing ones are full. So raising max_instances doesn't directly translate into more nodes.

Going the other way, lowering the instance count won't take you to zero. A running service keeps at least one instance, so to stop it completely you suspend it explicitly.

-- Stop it
ALTER APPLICATION SERVICE MY_DB.MY_SCHEMA.MY_APP SUSPEND;

-- Resume it
ALTER APPLICATION SERVICE MY_DB.MY_SCHEMA.MY_APP RESUME;

Set auto_suspend_secs and you can automate that stop. Apps basically keep running once deployed, so it's worth setting for any app that has idle stretches in its day.

Note: If you change instance counts or auto-suspend with ALTER APPLICATION SERVICE, the next snow app deploy rolls that change back to what's in app.yml (or to the defaults, if you didn't write it there). Anything you want to stick permanently belongs in app.yml. This is where the declarative deploy from the previous section comes into play.

Official docs: Scale and suspend Snowflake App Runtime apps

Environment Variables, Secrets, and External Access in app.yml Too

Configuration values, credentials, and permission to reach external networks all go in app.yml as well.

# Environment variables passed to the container (non-sensitive config values)
environment_variables:
  - name: LOG_LEVEL
    value: "INFO"

# Mount a Snowflake secret object
secrets:
  - name: API_KEY
    secret: MY_DB.MY_SCHEMA.API_KEY_SECRET

# External Access Integration (EAI) for the running app's egress to external hosts
external_access_integrations:
  - my_api_integration

A secret listed under secrets is mounted as files under /secrets/<name>/ rather than as an environment variable. Handy when you'd rather not put a password in an environment variable.

For external access, note that build time and run time use different fields.

Field	When it applies	What it's for
`build_eai`	Build time	npm and Google Fonts are allowed by default. Use this when the build needs additional destinations, such as a private registry
`external_access_integrations`	Run time	When the app connects to an external API or to Snowflake Postgres

Note: External access for a running app used to require attaching the integration with ALTER APPLICATION SERVICE (the follow-up article mentioned earlier shows that approach). You can now write it in app.yml under external_access_integrations.

Switching Between dev / stage / prod (Deploy Targets)

When you want to deploy the same project to multiple environments, use targets. The trick is to put shared configuration at the top level and give each target only the differences.

version: 2

# Everything below is the baseline that every target inherits
database: SNOWFLAKE_APPS
schema: PUBLIC
query_warehouse: MY_QUERY_WH
label: Sales Dashboard
icon: public/icon.svg

default_target: dev

targets:
  dev:
    name: SALES_DASHBOARD_DEV
    database: USER$              # place it in the personal database
  stage:
    name: SALES_DASHBOARD_STAGE
  prod:
    name: SALES_DASHBOARD_PROD
    query_warehouse: PROD_WH
    min_instances: 2
    max_instances: 5

You switch with --target at deploy time. Omit it and default_target is used.

snow app deploy --target prod

snow app open / events / teardown / validate all accept --target too, so you can keep working per environment without breaking stride.

Writing database: USER$ deploys to that user's personal database. It's convenient for experimenting during development, but an app placed in a personal database can't be shared with other roles. For an app your team will use, specify a standard database.

Official docs: Deploy targets

Hands-On: Building a Sales Dashboard from a Prompt

From here, I'll walk through how I actually built a sales dashboard app in CoCo Desktop. The subject is the sales data of a fictional online retailer, "Glacier Style" (GLACIERSTYLE_DB.EC_ANALYTICS_SCHEMA).

The app.yml covered in the previous chapter is something CoCo generates for you as part of this flow. If you started reading here, there's nothing you need to write by hand.

Step 1: Give CoCo a Prompt

In the CoCo Desktop chat, select /snowflake-apps (or use the "Build an app" starter card), then describe the app you want in natural language. Here's roughly the prompt I gave:

/snowflake-apps
Using the sales data in GLACIERSTYLE_DB.EC_ANALYTICS_SCHEMA,
build a sales dashboard that runs on Snowflake App Runtime, in Next.js.
Deploy the app itself to the GLACIERSTYLE_DB.APPS schema.

- Show KPIs (sales, order count, average order value, completion rate) as cards
- Filters to narrow by period, channel, and category
- Charts for sales by category, by channel, and the monthly trend
- Use a cool, glacier-inspired color palette

There are two points worth highlighting here. First, the prompt explicitly invokes the /snowflake-apps skill at the top. Second, it explicitly specifies GLACIERSTYLE_DB.APPS as the deployment target. If you don't specify a target, the app may be placed in your personal database and become impossible to share with other roles — so if you have internal sharing in mind, it's best to specify it up front.

When CoCo receives this prompt, it launches the snowflake-apps skill, first runs DESCRIBE on the target tables to understand the schema, then copies the Next.js template and implements app/page.tsx, the API routes, the chart components, and the styling — all in one pass, according to your requirements.

Step 2: Preview Locally

Once the implementation is done, CoCo starts a local development server (npm run dev) and checks that it works. During local development, the Snowflake connection automatically falls back to your local connection info (connections.toml), so you can verify the look and the numbers against real data before deploying.

Step 3: Deploy

Once the look and the numbers check out, it's time to deploy. Tell CoCo to "deploy it," and snow app deploy runs.

snow app deploy --verbose

This single command automatically runs through uploading the source → building the container remotely → creating the APPLICATION SERVICE. The first build takes a little while (more on that below), and when it's done, an authenticated URL is issued.

Step 4: Verify It's Running

Once deployment completes, you can access the app at a URL of the form https://<id>-<org>-<account>-<region>.snowflakecomputing.app/. This URL is protected by Snowflake SSO, so only authenticated users can use it.

You can also confirm the deployed app via SQL:

SHOW APPLICATION SERVICES IN SCHEMA GLACIERSTYLE_DB.APPS;

name                  : GLACIER_SALES_APP
status                : RUNNING
database_name         : GLACIERSTYLE_DB
schema_name           : APPS
query_warehouse       : GLACIERSTYLE_WH
compute_pool          :
url                   : <id>-<org>-<account>-<region>.snowflakecomputing.app
auto_resume           : true
auto_suspend_secs     : 0
min_instances         : 1
max_instances         : 1
current_instances     : 1
source                : {"artifactRepository":"GLACIERSTYLE_DB.APPS.GLACIER_SALES_APP_REPO","version":"VERSION$2","alias":"LATEST","package":"GLACIER_SALES_APP"}
additional_properties : {"label":"Glacier Style Sales Dashboard","icon":"public/icon.svg"}

The status is RUNNING, and you can see it's deployed to GLACIERSTYLE_DB.APPS exactly as specified, under version management. The min_instances / max_instances / auto_suspend_secs / auto_resume settings from the previous section show up as columns here as well. In this example auto_suspend_secs is 0, so auto-suspend is still disabled and the app stays up around the clock.

The compute_pool column is empty because App Runtime runs on a Snowflake-managed compute pool (I'll add a note on this in "Things to Watch Out For").

Scaffold from a prompt, confirm the numbers with npm run dev, then check for RUNNING with SHOW APPLICATION SERVICES after snow app deploy. You can get all the way through that without writing a container definition file.

An aggregation SQL aside: watch for duplicates in dimension tables There's one thing to watch in your aggregation SQL too. If a dimension table contains duplicate rows for the same ID, joining it directly will inflate your counts (fanout). Deduplicate first with `QUALIFY ROW_NUMBER() OVER (PARTITION BY ORDER BY ) = 1` before joining, and you'll get correct aggregates. Checking the nature of your data is essential even when building an app.

Things to Watch Out For

Here are some points worth keeping in mind when you actually build an app — things you won't see by just skimming the official docs. Knowing them up front should help you move along smoothly without stumbling.

1. Mind the CLI version

Writing your deploy configuration in app.yml requires a recent Snowflake CLI. An older CLI silently ignores the deploy configuration in app.yml and goes looking for snowflake.yml, which shows up as the confusing symptom of "I changed the setting but nothing happened" or "it deployed with the old values." Check with snow helpers check-version and update with pip install --upgrade snowflake-cli before you start.

2. `app.yml` is declarative, so anything you forget to write disappears

snow app deploy applies the contents of app.yml as a whole every time. So removing a field you had written previously resets that setting to its default. Manual changes made with ALTER APPLICATION SERVICE get rolled back on the next deploy too.

The case that trips people up most is leaving an old-format profile: block in place. Since profile: is no longer read, the title, description, and icon disappear on every deploy. Move label / description / icon to the top level.

Adopt "anything I want to stick permanently goes in app.yml" as your rule and you won't get lost.

3. `snow app setup` needs a warehouse, and watch the deploy target

snow app setup requires a query warehouse. If you see a Missing warehouse error, pass --warehouse or set the account parameter DEFAULT_SNOWFLAKE_APPS_QUERY_WAREHOUSE.

The deploy target deserves extra care. Unlike snowflake.yml, app.yml doesn't fill in the database or schema from your connection info. If name / database / schema / query_warehouse can't be resolved from the manifest alone, the deploy fails with Missing required field(s).

Also, an app placed in a personal database with database: USER$ can't be shared with other roles, so if you have internal sharing in mind, it's best to specify a standard database and schema. State the destination in your prompt and CoCo will reflect it in this configuration for you.

4. The compute pool is Snowflake-managed, by design

App Runtime runs on an SPCS compute pool, but the pool is Snowflake-managed and fixed — you can't point it at a pool you created yourself, and app.yml has no field for specifying one.

As a result, you don't need to create a compute pool yourself, nor set up an External Access Integration for fetching npm packages (remote builds already allow npm and Google Fonts by default). Being able to start without worrying about infrastructure is a big plus. This is also why the compute_pool column is empty on a deployed app.

5. Next.js standalone builds need an explicit static asset copy

The build service used to copy .next/static and public/ into the standalone directory automatically when Next.js was set to output: 'standalone'. The current build service runs only the commands you write under build:.

So if you migrate a project that got by with just npm run build, you'll see the symptom where the app opens but CSS and images come back 404. Write the copy steps out explicitly.

build:
  commands:
    - [npm, run, build]
    - [cp, -r, .next/static, .next/standalone/.next/static]
    - [cp, -r, public, .next/standalone/public]

If your project has no public/ directory, you don't need that last line.

6. Deployment spends more time on "endpoint provisioning" than the build

With snow app deploy, the remote build itself finishes relatively quickly, and the subsequent endpoint provisioning (Endpoints provisioning in progress...) can take a few minutes. Even if the log looks stuck on the same line, work is progressing — so wait until App ready at https://... appears. When you want to reflect a configuration-only change quickly without touching code, snow app deploy --promote-only lets you skip the upload and build.

7. Watch the connection's role during local development

During local npm run dev, querySnowflake() automatically falls back to the default connection in ~/.snowflake/connections.toml. If the connection has no role set, it runs with the default role, which can lead to a Database '...' does not exist or not authorized error. Set a role that can access the target data on the connection, or specify it via the SNOWFLAKE_ROLE environment variable.

Note that { callersRights: true } has no effect when running locally. The helper just uses your local connection and emits a warning. If you want to confirm Caller's Rights behavior, check it after deploying.

8. A deployed app doesn't show up in `SHOW SERVICES`

Because App Runtime runs as a separate object type, APPLICATION SERVICE, a deployed app does not appear in SHOW SERVICES. Use SHOW APPLICATION SERVICES to check it. The ordinary SPCS commands CREATE SERVICE / ALTER SERVICE don't work either, so reach for the APPLICATION SERVICE variants. The reliable way to judge a successful deploy is to look at the CLI output (App ready at https://... and the URL).

9. Stop apps you're not using

Apps basically keep running once deployed. Compute stays up even with no traffic, so an app you've stopped using is worth suspending with ALTER APPLICATION SERVICE ... SUSPEND or removing with DROP APPLICATION SERVICE. For an app that's only used during certain hours, setting auto_suspend_secs is the easy option.

You can check account-wide usage by the hour in SNOWFLAKE.ACCOUNT_USAGE.SNOWFLAKE_APP_RUNTIME_COMPUTE_HISTORY.

SELECT START_TIME, END_TIME, CREDITS_USED
FROM SNOWFLAKE.ACCOUNT_USAGE.SNOWFLAKE_APP_RUNTIME_COMPUTE_HISTORY
WHERE START_TIME >= DATEADD('day', -7, CURRENT_TIMESTAMP())
ORDER BY START_TIME DESC;

Since every app in the account shares a single managed compute pool, what this view gives you is account-level credits. Per-app cost attribution isn't available. Billing is per node, not per instance: App Runtime packs multiple instances onto a node while there's room, and only adds a node once the existing ones are full. So you don't need to think about "how many apps fit" as a compute pool sizing question.

Cost is the only thing that's account-level. Service state, logs, and metrics are all available per app, as follows.

10. Check state, logs, and metrics per app

There's no need to go poking at the compute pool. App Runtime's observability is built around the app (APPLICATION SERVICE).

Start with state, via DESCRIBE APPLICATION SERVICE. A service reports states such as PENDING, RUNNING, SUSPENDED, and FAILED, which is how you catch the "I thought it was up, but it had died" case.

DESCRIBE APPLICATION SERVICE APP_DB.APP.MY_APP;

For logs, you can pull the container logs directly. From SQL, use SYSTEM$GET_APPLICATION_SERVICE_LOGS: the second argument is the line count (default 500), and the third selects an instance by number. The role running it needs the MONITOR privilege on the service.

SELECT SYSTEM$GET_APPLICATION_SERVICE_LOGS('APP_DB.APP.MY_APP', 500);

The CLI is handier still, and gives you CPU / memory / network metrics and lifecycle events on top of logs.

# Recent logs (500 lines by default; size it with --last)
snow app events

# Historical logs via the event table (works even after a suspend)
snow app events --type log --since 6h

# CPU / memory / network metrics
snow app events --type metric --metric cpu --since 1h

# Service and container state changes
snow app events --type lifecycle --since 2d

Ask CoCo to "show me the logs for this app" and it will run these for you and walk through what they say. When a deploy fails, this is the fastest path to narrowing down the cause.

Official docs: Observability for Snowflake App Runtime

Business Value and Use Cases

The technical ease is what we've seen so far, but where App Runtime really shines is the business and organizational angle.

Value	Details
Governance stays intact	Because the app runs inside Snowflake's security perimeter, it inherits RBAC, audit logging, SSO, and data governance as-is
No data movement	No data copies or external API layer needed, reducing the risk of data leaking outside or to the app side
Integrated authentication	An authenticated URL is issued automatically — no separate login infrastructure required
Easier to build in-house	Since Snowflake handles infrastructure, Docker, and server management, you can ship internal apps without creating shadow IT

Concrete use cases include:

Internal data visualization dashboards: Department-level KPIs delivered in an easy-to-read custom UI
Internal search / reference tools: Reference apps that control what each user can see via Caller's Rights
Entry forms and approval workflows: Business apps where requests get created and updated. For these write-heavy cases, start with the configuration that puts Snowflake Postgres behind the app

For organizations where "the data is in Snowflake, but the apps that use it rely on outsourcing or a separate platform," this looks like an option that shortens the path to building in-house.

Limitations

As handy as it is, there are some limitations to be aware of.

Note (limitations):

Not available on trial accounts (a paid account is required)

Not available in government regions. AWS, Azure, and Google Cloud commercial regions are in scope

Apps deployed to a personal database (USER$...) can't be shared with other roles. To share, place it in a standard database

Each build produces an immutable version. You can't overwrite an existing version, so every change needs a new build

CREATE OR REPLACE APPLICATION SERVICE isn't supported. Use CREATE OR ALTER APPLICATION SERVICE instead

UNDROP isn't supported, so a dropped APPLICATION SERVICE can't be brought back. That said, the artifact repository that holds your built versions (<app_name>_REPO) is a separate object from the service, so dropping the service leaves the repository in place. To bring the app back, you deploy it again

The supported stack centers on Node.js / Next.js (Python support is also planned, and coverage is expected to expand over time)

Please check the official documentation for the latest limitations.

Official docs: Snowflake App Runtime limitations

Conclusion

So, what did you think of Snowflake App Runtime?

Let's recap the key points of this article:

App Runtime is a platform that lets you deploy full-stack web apps (Next.js and friends) inside Snowflake, as an SPCS APPLICATION SERVICE. It reached GA in September 2026
No infrastructure, Docker, or auth implementation needed — you can publish an app while inheriting SSO and governance
Configuration is consolidated into a single app.yml file (version: 2), where you declaratively write the deploy destination, scale and auto-suspend, secrets, external access, and deploy targets
With CoCo's snowflake-apps skill, you go from prompt to scaffold to local preview to deploy in one continuous flow
When you actually build one, there are points worth knowing up front — the CLI version, how declarative deploys behave, specifying the deploy target, and the role during local development

The approach of "running a real web app right next to your data" looks set to make in-house app development — previously a time-consuming effort — much more approachable. Now that it's GA and the configuration side has settled, I'd expect the supported stack and features to keep expanding.

I'd love for you to get hands-on and share what you discover. Let's grow this new app-building experience together!

Promotion

App Runtime Explained on the Official Snowflake Japan YouTube Channel

The official Snowflake Japan YouTube channel has launched, and it already includes a walkthrough of Snowflake App Runtime — the very topic of this article. The video covers what App Runtime is and how to get an app deployed, with a live demo. It's in Japanese, but the demo sections should still be easy to follow alongside this article.

Snowflake What's New Updates on X

I share Snowflake What's New updates on X. Follow for the latest insights:

English Version

Snowflake What's New Bot (English Version)

Japanese Version

Snowflake's What's New Bot (Japanese Version)

Change Log

(20260605) Initial post
(20260830) Added the App Runtime walkthrough from the official Snowflake Japan YouTube channel
(20260923) Major revision. Reflected App Runtime's GA (September 1, 2026). Rewrote the configuration around the single app.yml manifest (version: 2), and added sections on scale (min_instances / max_instances) and auto-suspend (auto_suspend_secs), on environment variables / secrets / external access, and on deploy targets (targets / --target). Corrected how Caller's Rights is configured (no app.yml setting required; GRANT CALLER is) and the snow app deploy flags (--deploy-only → --promote-only). Added migration notes such as the static asset copy for Next.js standalone builds
(20260923) Added a section on per-app observability (DESCRIBE APPLICATION SERVICE, SYSTEM$GET_APPLICATION_SERVICE_LOGS, and the log / metric / lifecycle streams of snow app events). Clarified that cost is the only thing reported at the account level. Noted that when an app is dropped, its artifact repository remains as an object independent of the service

Original Japanese Article

Snowflake App Runtime 入門 - プロンプトひとつでデータの隣に本格Webアプリをデプロイする！

zenn.dev

Beyond Transcription - Multimodal Video and Audio Analysis with Snowflake AI_COMPLETE

Tsubasa Kanno — Sun, 17 May 2026 12:50:45 +0000

⚠️ Major revision notice (September 2026)

This article was originally published in May 2026. Cortex AI's multimodal support has expanded considerably since then, so I rewrote it in September 2026. The main changes are:

gemini-3.1-flash-lite joined the models that accept video and audio directly, adding a lighter-weight option

AI_TRANSCRIBE now accepts video files as-is, so you no longer need to extract the audio track first. The comparison section has been rewritten accordingly

AI_MULTI_EMBED enables semantic video search, which is covered in a new section

Per-request limits are now broken down by images, audio, and video, and there's a new section on passing multiple files in one call

AI_TRANSCRIBE's 10-second minimum billing duration is now documented, and is noted in the comparison section

The sample app is now model-selectable, and a new section covers how to create a stage for media files

Introduction

Snowflake's unstructured data analytics has just taken another big leap forward. After progressively adding support for images, documents, and audio, AI_COMPLETE can now accept video and audio files as direct input!

This update — the multimodal video and audio extension of AI_COMPLETE — is one of the Cortex AI Functions updates I've been watching most closely. You can now hand a video or audio file directly to AI from SQL, and get summaries, classification, sentiment analysis, and structured extraction in a single shot.

Until now, audio analysis usually meant a two-step pipeline with transcription in the middle, and video analysis required building your own preprocessing stack on something like Snowpark Container Services (SPCS). With this update, you can skip those steps and let the model directly understand vocal tone, pauses, and visual content — opening the door to analyses that were previously hard to attempt.

With images, documents, audio, and now video — nearly every major unstructured data format used in business is queryable from SQL. This means you can now build multimodal analytics in a much simpler way than before.

We'll work through the basics, how AI_COMPLETE compares with AI_TRANSCRIBE, semantic video search, and a sample app built with Streamlit in Snowflake — running each piece along the way.

Note: AI_COMPLETE's video and audio input is in Public Preview, so expect it to change in future updates. AI_TRANSCRIBE and AI_MULTI_EMBED, which this article also covers, are generally available (GA). Supported models and limits are expected to keep expanding.

Note: This article reflects my personal views and does not represent Snowflake's official position.

What's New: AI_COMPLETE Multimodal Extension

AI_COMPLETE is the central general-purpose LLM function in the Snowflake Cortex AI Functions family. It already supported text, images, and documents as multimodal input, but with this update you can now pass video and audio files directly.

Audio analytics used to follow a "transcribe with AI_TRANSCRIBE → analyze text with AI_COMPLETE" pattern. Video analytics required either extracting frames as images with Python libraries and feeding them into AI_COMPLETE's image input, or building an end-to-end frame-extraction-and-inference pipeline with SPCS. With this multimodal extension, you can skip those preprocessing steps and hand the audio or video file itself to AI_COMPLETE for summarization, sentiment analysis, and structured extraction.

Key Highlights

SQL-native: Same calling convention as before — just pass a video or audio file
Joint audio + visual understanding: For video, the model considers both visual content and audio track
Multimodal composition: Combine with text prompts for conditional analysis or JSON-structured output
Wide format support: Most common video and audio formats are accepted
Secure processing: Processing stays inside Snowflake

Part of the Cortex AI Functions Family

The multimodal extension shines when you chain its output into downstream AI Functions. After extracting a summary from a video, common follow-up patterns include:

AI_CLASSIFY: Categorize the extracted summary into industries or risk levels
AI_SENTIMENT: Score sentiment along multiple dimensions
AI_AGG: Aggregate insights across many media files
AI_EMBED: Embed extracted text or images for cross-corpus search
AI_TRANSCRIBE: A purpose-built function for transcription, ideal when you need timestamps and speaker labels from audio or video
AI_MULTI_EMBED: Embeds the video itself, enabling semantic search like "find scenes similar to this one" (covered later)

Creating a Stage for Media Files

Cortex AI's media functions read files from a stage via TO_FILE. The stage has to meet a couple of requirements, so let's create one first.

CREATE OR REPLACE STAGE media_stage
  DIRECTORY = ( ENABLE = TRUE )
  ENCRYPTION = ( TYPE = 'SNOWFLAKE_SSE' );

Two things matter here:

Specify server-side encryption (SNOWFLAKE_SSE): internal stages default to client-side encryption, and media functions can't read from client-side encrypted stages
Add DIRECTORY = ( ENABLE = TRUE ): required when you want to process every file in the stage via DIRECTORY()

Note that user stages (@~) and table stages aren't supported. If you use an external stage on Amazon S3 or similar, enable encryption and a directory table the same way.

The examples below assume your media files live in this @media_stage.

Basic Usage

Passing a video or audio file directly to AI_COMPLETE follows the same simple syntax as image input.

AI_COMPLETE(
    <model>,
    <prompt>,
    <file>
)

Parameters

model: Name of an LLM that supports video/audio input. gemini-3.1-pro, gemini-3.1-flash-lite, and gemini-3.5-flash are listed as supported, and the lineup keeps growing.
prompt: Natural-language instruction
file: A reference to a staged file via TO_FILE

Example 1: Summarizing a Video File

The simplest use case is to hand a video to the model and ask for a summary that takes both visuals and audio into account.

This article uses Pexels: Pouring Fresh Coffee into Ceramic Mug (Pexels License) as the sample video.

SELECT AI_COMPLETE(
    'gemini-3.1-pro',
    'Summarize this video in about 70 words. Include what is shown, the mood, and the likely scene.',
    TO_FILE('@media_stage', 'pouring_coffee.mp4')
) AS summary;

The actual response looks like this:

A glass coffee server slowly pours freshly brewed coffee into a uniquely designed
small mug shaped like a blue character, sitting on a white table. The cute design
of the cup combined with the quiet motion of the cup gradually filling up evokes
a warm, relaxed atmosphere — exactly the kind of feeling that lets you take a
breather. It feels like a calm morning coffee at home or an afternoon break.

The same pattern works for audio. Hand an audio file of English narration to the model and ask for a summary, and you get an output that captures both the content and the speaker's tone:

SELECT AI_COMPLETE(
    'gemini-3.1-pro',
    'Summarize this audio in about 50 words. Take the speaker''s emotion and atmosphere into account.',
    TO_FILE('@media_stage', 'english_narration.m4a')
) AS summary;

For Sherlock Holmes, she (Irene Adler) is always "the woman" — a uniquely special
presence. The narrator, Watson, says he has rarely heard Holmes refer to her by
any other name. The calm, reminiscent delivery quietly conveys the deep respect
Holmes holds for her, and her overwhelming presence.

Japanese audio works the same way. The audio here was synthesized with the macOS say command for reproducibility — you can also generate equivalent audio with Mozilla Common Voice's Japanese dataset (CC0) or VOICEVOX.

SELECT AI_COMPLETE(
    'gemini-3.1-pro',
    'Summarize this audio, and state the speaker''s request and emotional tone in one or two sentences.',
    TO_FILE('@media_stage', 'business_call_jp.m4a')
) AS summary;

The speaker is reaching out to confirm the current status of a delayed delivery
of a recently purchased item. The emotional tone is highly polite and composed.

Example 2: Going Beyond Words — Tone, Pitch, and Pace

This is a significant difference from AI_TRANSCRIBE. With AI_COMPLETE, the model can evaluate the vocal delivery itself — pitch, pace, tone, volume, and pauses (the official docs explicitly demonstrate this in the call-center example). The phrase "Hello" can carry completely different meaning depending on whether it's said with a bright, upbeat tone or a heavy, somber one. That nuance is lost the moment you transcribe to text — and AI_COMPLETE can capture it.

To verify, I synthesized the exact same Japanese phrase ("Hello, thank you for joining us today.") in two different tones — bright/fast vs. dark/slow — and passed each to AI_COMPLETE.

SELECT AI_COMPLETE(
    'gemini-3.1-pro',
    'You are an acoustic analyzer. Listen to the attached audio and evaluate the vocal delivery (pitch, pace, tone, volume). Return a short description of the vocal delivery only (do not transcribe content).',
    TO_FILE('@media_stage', 'tone_bright.m4a')
) AS bright_analysis;

Output for the bright/fast version:

Spoken with a very high pitch and fast pace. The tone is bright and slightly
artificial (sounds sped-up or processed). Volume is moderate.

Output for the dark/slow version:

Pitch is moderate and steady, and the pace is calm and easy to follow. The tone
is polite and composed, with consistent moderate volume.

The actual words are identical, but the model returned clearly different evaluations based on how the voice was delivered. This is information that transcription alone doesn't surface. For use cases where the way something is said matters as much as what is said — call center quality scoring, interview evaluation, escalation detection — it's genuinely useful.

Example 3: Structured Analysis of a Video File

Use a JSON Schema to get structured output that downstream pipelines can consume directly.

Two extra arguments come into play here. The fourth argument holds model parameters such as temperature; pass {} when you don't need them. The fifth argument is the output schema, where you set 'type': 'json' along with your JSON Schema.

SELECT TO_JSON(AI_COMPLETE(
    'gemini-3.1-pro',
    'Analyze this video and return scene summary, visible objects, and the overall mood as JSON.',
    TO_FILE('@media_stage', 'pouring_coffee.mp4'),
    {},
    {
        'type': 'json',
        'schema': {
            'type': 'object',
            'properties': {
                'summary': {'type': 'string'},
                'objects': {'type': 'array', 'items': {'type': 'string'}},
                'mood': {'type': 'string'}
            },
            'required': ['summary', 'objects', 'mood']
        }
    }
)) AS analysis;

Actual output:

{
  "mood": "Calm, relaxed",
  "objects": ["Coffee pot", "Mug", "Coffee"],
  "summary": "Coffee being poured from a black coffee pot into a unique mug featuring a blue bird's face design."
}

The keys and types defined in the schema are honored, which makes it trivial to forward the output into the next stage of a data pipeline.

The same pattern applies to audio. Here it is against a recording of a meeting:

SELECT TO_JSON(AI_COMPLETE(
    'gemini-3.1-pro',
    'Analyze this audio and return a JSON object with a summary, the likely topic genre, and the overall tone.',
    TO_FILE('@media_stage', 'meeting_clip.mp3'),
    {},
    {
        'type': 'json',
        'schema': {
            'type': 'object',
            'properties': {
                'summary': {'type': 'string'},
                'genre': {'type': 'string'},
                'tone': {'type': 'string'}
            },
            'required': ['summary', 'genre', 'tone']
        }
    }
)) AS analysis;

{
  "genre": "Business/Marketing",
  "summary": "Monthly meeting for Nimbus Cloud highlighting a 32% improvement in paid search CPA, exceeding demo targets with 420 applications, and outlining future plans for LinkedIn targeting and CRM integration.",
  "tone": "Professional"
}

Example 4: Conditional Analysis with Text Prompts

When you want only a specific aspect extracted, that's a matter of prompt design. Including instructions like "if there are none, just return 'none'" helps keep the model from guessing when there's nothing to report.

This article uses Pexels: Person Having an Interview (Pexels License). The video doesn't contain any product names, so the expected output is "none".

SELECT AI_COMPLETE(
    'gemini-3.1-pro',
    'Extract only the moments where product names (brand names) appear in this video, and list each name with its timing as bullet points. If there are none, just return "none".',
    TO_FILE('@media_stage', 'interview.mp4')
) AS extracted;

The model returned exactly none, faithfully following the prompt.

Supported Models and Formats

Supported Models

According to the official documentation, the models listed as supporting direct video/audio input are gemini-3.1-pro, gemini-3.1-flash-lite, and gemini-3.5-flash. It started with gemini-3.1-pro only, and lighter options were added over time, so you can now pick your balance between analysis quality and speed. All three have a context window of roughly one million tokens, with the same supported formats and file-size limits. Snowflake partners with multiple model providers, so the lineup of multimodal-capable models keeps growing.

Model	Context window	When to use
`gemini-3.1-pro`	1,000,000 tokens	When you prioritize higher analysis quality
`gemini-3.1-flash-lite`	1,048,576 tokens	When you want a lighter model for higher volume
`gemini-3.5-flash`	1,000,000 tokens	When you want faster, lighter-weight processing

Another thing I appreciate about AI_COMPLETE is that the model you used stays visible in the query. The function takes the model name as its first argument by design, so you always know which model produced a result, and you can tune the cost-versus-quality balance deliberately.

Supported Formats

A broad set of mainstream formats is supported, so you can work with most video and audio files you'd find in the wild.

Type	Supported formats
Video	mp4, mpeg, mov, avi, flv, mpg, webm, wmv, 3gpp
Audio	wav, mp3, aiff, aac, ogg, flac, m4a, mp4, pcm, webm

Per-Request Limits

The per-request limits are as follows. They're comfortable for testing and proof-of-concept work, and are expected to be relaxed as the feature matures.

Item	Limit
Total size per request	100 MB
Video files per request	Up to 10
Audio files per request	Up to 10
Image files per request	Up to 20

File counts are tallied independently per type. For longer videos, splitting by scene or duration before sending lets you analyze plenty of content within current limits.

Passing Multiple Files in One Call

Every example so far passed a single file as the third argument. When you want several files in the same request so the model can compare them, use the PROMPT function and reference each file with {0}, {1}, and so on.

SELECT AI_COMPLETE(
    'gemini-3.1-pro',
    PROMPT('Do video {0} and image {1} look like they belong to the same campaign? Answer in 30 words or fewer.',
        TO_FILE('@media_stage', 'promo_spot.mp4'),
        TO_FILE('@media_stage', 'creative.png'))
) AS consistency_check;

Yes, they share the same visual identity, so they appear to belong to the same
campaign.

That makes it a single query to check whether a campaign video and its creative artwork look consistent.

The PROMPT function reference currently focuses on text plus images and documents. Before putting a combination that includes video into a production pipeline, it's worth confirming the behavior in your own environment.

Regional Availability

Check the Cortex LLM Regional availability page for the native regions of the video/audio-capable models. If your region isn't natively supported, you can enable cross-region inference with a single SQL statement and use the same functionality.

ALTER ACCOUNT SET CORTEX_ENABLED_CROSS_REGION = 'ANY_REGION';

There may be slightly higher latency when going via cross-region inference, but the functionality remains the same.

AI_TRANSCRIBE vs. AI_COMPLETE — Cost and Quality

"Should I use AI_TRANSCRIBE or AI_COMPLETE for audio and video?" is a question many people run into.

The fundamental thing to understand is that AI_TRANSCRIBE is a purpose-built, dedicated AI Function for converting media to text. The output is text by default, with optional word-level or speaker-level timestamps. That gives you less flexibility — but in return, it's simple to use when your goal is clear and costs are predictable per second of audio. AI_COMPLETE is a general-purpose LLM, so prompts can express anything you want, and the model can incorporate vocal delivery and visual information into its interpretation. The two aren't competitors — they're complementary: AI_TRANSCRIBE for clear, fixed goals; AI_COMPLETE for free-form interpretation.

AI_TRANSCRIBE Accepts Video Files Directly Too

When this article was first published, AI_TRANSCRIBE was audio-only. Today you can hand it a video file and have it transcribe the audio track, which removes the preprocessing step when you're building minutes from a meeting recording or a webinar archive.

SELECT AI_TRANSCRIBE(TO_FILE('@media_stage', 'meeting.mp4'));

The response has the same shape as it does for audio:

{
  "audio_duration": 15.04,
  "text": "Let's begin this month's regular review for Nimbus Cloud. This month, paid search CPA improved by 32%. Demo signups came in at 420, ahead of target."
}

Supported formats are as follows. A video file must contain at least one audio track, encoded with one of AAC, ALAC, FLAC, MP3, Opus, Vorbis, or PCM.

Type	Supported formats
Audio	aac, flac, m4a, mp3, mp4, ogg, wav, webm
Video	mkv, mov, mp4, ogv, webm

Note that these formats differ from AI_COMPLETE's. An .avi recording works with AI_COMPLETE, for example, but needs converting before AI_TRANSCRIBE will take it.

With timestamps enabled, the maximum duration is 60 minutes; without them it's 120 minutes, and the file size limit is 700 MB. That's larger than AI_COMPLETE's limit of 100 MB combined per request, so AI_TRANSCRIBE is often the easier route for long recordings you want to process whole. AI_TRANSCRIBE is also available in a limited set of regions, so check the official reference alongside the model availability page.

Timestamps and Speaker Labels Are Opt-In

The example above returned only audio_duration and text. To get timestamps or speaker labels, pass timestamp_granularity as the second argument — word splits per word, speaker splits at each change of speaker.

SELECT AI_TRANSCRIBE(
    TO_FILE('@media_stage', 'meeting.mp4'),
    {'timestamp_granularity': 'speaker'}
);

{
  "audio_duration": 15.04,
  "segments": [
    {
      "speaker_label": "SPEAKER_00",
      "start": 0.051,
      "end": 14.78,
      "text": "Let's begin this month's regular review for Nimbus Cloud. ..."
    }
  ],
  "text": "..."
}

Functional Differences

Aspect	AI_TRANSCRIBE	AI_COMPLETE (audio / video direct)
Primary purpose	Structured media-to-text conversion	Free-form analysis (summary, classification, extraction)
Output	Text, with optional timestamps and speaker labels	Whatever you ask for in the prompt (incl. JSON)
Speaker separation	Set `timestamp_granularity` to `speaker` for labels (SPEAKER_00, etc.)	Achieved by prompt instruction
Timestamps	Word- or speaker-level	Achievable via prompt + structured output
Visual content	Audio track only	Can interpret what's on screen
Vocal tone / emotion	Text only	Includes pitch, pace, tone, volume, pauses
Input size limit	Up to 700 MB	100 MB combined per request
Multilingual	Broad coverage	LLM-native flexibility

Cost Comparison

Function	Pricing characteristic
AI_TRANSCRIBE	1 sec of audio = 50 tokens (flat). 180,000 tokens per hour. 10-second minimum billing duration
AI_COMPLETE (audio / video direct)	Standard LLM token pricing — varies by input size and output length

AI_TRANSCRIBE bills linearly with audio duration, so it shines when you want "just the transcript" or stable, predictable costs in big batch jobs. Keep in mind that files shorter than 10 seconds are billed as 10 seconds, so if you have a large number of short clips, batching them into one file and slicing by timestamp avoids waste. AI_COMPLETE varies with prompt and output size, which can swing costs depending on the task. In return, you explicitly choose the model in the first argument, giving you direct control over the cost-vs-quality trade-off in your application.

Quality Comparison

Scenario	Recommendation
Meeting minutes drafting (need accurate transcript)	AI_TRANSCRIBE → AI_COMPLETE chain
Transcript only, straight from a meeting recording	AI_TRANSCRIBE (pass the video as-is)
Call center sentiment analysis (with vocal tone)	AI_COMPLETE direct
Large-scale, fast batch transcription	AI_TRANSCRIBE
Video (visual + audio) summarization & moderation	AI_COMPLETE direct
JSON-structured extraction from audio	AI_COMPLETE direct
Finding a specific scene across a large video library	AI_MULTI_EMBED (covered next)

Rule of thumb: "Need text to keep on file" → AI_TRANSCRIBE. "Need the model to interpret content" → AI_COMPLETE. The "AI_TRANSCRIBE → AI_COMPLETE" pipeline is also a well-balanced option for cost and quality in many use cases.

Semantic Video Search with AI_MULTI_EMBED

Everything so far has been about reading one piece of media deeply. In practice you also run into a different need: finding the right moment across a large library of videos. AI_MULTI_EMBED is built for that.

Where AI_EMBED returns a single vector, AI_MULTI_EMBED segments the video by scene and returns one vector per segment. It also embeds three separate modalities — visual, audio, and the transcription of speech — so you can search for "scenes that look similar" separately from "scenes where similar things were said."

A quick glossary: a vector turns meaning into a list of numbers, so measuring the distance between two vectors tells you how similar their meanings are. A segment is a slice of the video cut at a scene boundary, and a modality is the kind of signal — visual, audio, or speech.

The available model is Twelve Labs' twelvelabs-marengo-embed-3-0.

SELECT AI_MULTI_EMBED(
    'twelvelabs-marengo-embed-3-0',
    TO_FILE('@media_stage', 'promo_spot.mp4')
) AS embeddings;

What comes back is an array with one element per segment-and-modality combination. Because each element carries start_sec and end_sec, you can jump straight to the playback position of whatever matched.

{
  "error": null,
  "value": [
    {
      "embedding": [-0.0220, 0.0053, 0.0242, "..."],
      "embedding_option": "visual",
      "embedding_scope": "clip",
      "start_sec": 0,
      "end_sec": 4.5
    }
  ]
}

Flatten that into a table and you can search scenes with a natural-language query. The vectors are 512-dimensional, so cast them to VECTOR(FLOAT, 512) before handing them to a similarity function. If your stage also holds audio or images, filter by extension first.

-- Build a catalog of scenes
CREATE OR REPLACE TABLE video_embeddings AS
WITH embedding_index AS (
    SELECT
        TO_FILE('@media_stage', RELATIVE_PATH) AS video_file,
        AI_MULTI_EMBED('twelvelabs-marengo-embed-3-0',
            TO_FILE('@media_stage', RELATIVE_PATH)) AS embeddings
    FROM DIRECTORY(@media_stage)
    -- Common video extensions; check the docs for the full supported list.
    -- Snowflake's RLIKE rejects the (?i) inline flag, so lower-case the path instead.
    WHERE LOWER(RELATIVE_PATH) RLIKE '.*\\.(mp4|mov|avi|mkv|webm)'
)
SELECT
    video_file,
    f.value['embedding']::VECTOR(FLOAT, 512) AS embedding_vec,
    f.value['embedding_option']::STRING      AS embedding_option,
    f.value['start_sec']::FLOAT              AS start_sec,
    f.value['end_sec']::FLOAT                AS end_sec
FROM embedding_index,
LATERAL FLATTEN(input => embedding_index.embeddings['value']) f;

-- Search scenes with a natural-language query
WITH query AS (
    SELECT (AI_MULTI_EMBED(
        'twelvelabs-marengo-embed-3-0',
        'a scene where coffee is being poured'
    )):value[0]['embedding']::VECTOR(FLOAT, 512) AS query_embedding
)
SELECT
    v.video_file,
    v.start_sec,
    v.end_sec,
    VECTOR_COSINE_SIMILARITY(v.embedding_vec, q.query_embedding) AS similarity
FROM video_embeddings v
CROSS JOIN query q
WHERE v.embedding_option = 'visual'   -- swap for 'transcription' to search what was said
ORDER BY similarity DESC
LIMIT 10;

Filtering on embedding_option is what lets you choose between searching how a scene looks and searching what was said in it. Without the filter, all three modalities compete in the same ranking.

The size limits are generous too: up to 4 hours and 6 GB per video. Putting AI_MULTI_EMBED in front of AI_COMPLETE — narrowing down which scenes are worth looking at, then reading those in detail — is an efficient way to work through a large video library.

twelvelabs-marengo-embed-3-0 is natively available in a limited set of regions, but enabling cross-region inference (above) lets you use it the same way. AI_MULTI_EMBED also differs from the other multimodal functions in that it supports client-side encrypted (CSE) stages and stages protected by network policies.

Business Use Cases

Here are some of the business scenarios that Cortex AI's video and audio support opens up.

1. Call Center Quality Scoring

Hand call recordings directly to AI_COMPLETE and get a multi-dimensional quality score — agent professionalism, customer anger level, escalation signals — that takes vocal delivery into account.

Tone-aware sentiment analysis: Catches subtle nuances that transcription would miss
Structured output integration: Returns each metric as JSON for dashboarding
Agent training: Identify improvement areas by comparing against high-performer recordings

2. Structured Meeting Minutes from Video

Pass a long meeting recording and get summaries, decisions, and action items broken down by topic and participant.

Topic-aware structuring: Prompt-driven chapter segmentation
Action item extraction: Get owner and due date as JSON
Cross-modal context: Whiteboards and on-screen materials are also picked up
Verbatim record: When you also need a word-for-word transcript, pass the same recording to AI_TRANSCRIBE

3. Compliance Checks for Promotional Videos

Run pre-publication checks for marketing videos to catch potential regulatory issues or brand-guideline violations.

Custom condition detection: Define check criteria via prompt
Cross-modal consistency: Spot inconsistencies between on-screen captions and spoken content
Multi-language QA: Verify localized versions in batch via SQL

4. Auto-Chaptering and Scene Search for Educational Content

Analyze online learning content with AI_COMPLETE to generate chapter titles, summaries, and timestamped indexes for viewers.

Topic-shift detection: AI identifies content boundaries
Audience-specific summaries: Generate multiple versions per skill level
Scene search: Embed the video itself with AI_MULTI_EMBED so learners can jump straight to "the part that explains this operation"

5. Social / UGC Moderation

UGC (User Generated Content) refers to videos, audio, and images posted by general users on social media or video platforms. You can implement harmful or policy-violating content detection as part of your SQL workflow.

Batch moderation: Auto-process newly arriving videos via Streams + Tasks
Reviewer notification: Send results to moderators via Snowflake Notifications
Multi-axis scoring: Score for violence, discriminatory speech, copyright concerns in parallel
Near-duplicate detection: Use AI_MULTI_EMBED to measure similarity against videos previously flagged as violations

Sample App: Video Analysis with Streamlit in Snowflake

To give you an instant feel for AI_COMPLETE's video support, here's a simple Streamlit in Snowflake app that lets you upload a video and analyze it on the spot.

What the App Does

Video upload: Upload directly via browser; auto-saved to a stage
Video preview: Play the uploaded video in place
AI analysis: Run AI_COMPLETE with video input for summarization, extraction, classification
Model switching: Pick the model used for analysis from the sidebar
Editable prompt: Tweak the analysis prompt freely from the sidebar

Prerequisites

A Snowflake account where Streamlit in Snowflake is available
A video-capable model available natively, or cross-region inference enabled
Video files smaller than 100 MB
Streamlit version 1.52.2. Streamlit in Snowflake can default to an older Streamlit release, so pin the version explicitly to get current widget behavior
CREATE STAGE on the schema, plus the SNOWFLAKE.CORTEX_USER database role to call Cortex AI Functions

Specifying the Streamlit Version (Important)

Streamlit in Snowflake's default version may be older than expected, so I recommend pinning the version explicitly. Just place an environment.yml next to your app files in the stage:

# environment.yml
name: app_environment
channels:
  - snowflake
dependencies:
  - streamlit=1.52.2

If you create the SiS app from Snowsight, you can change the streamlit version from the "Packages" dropdown in the upper right of the editor — pick the newest version offered there.

How to Set It Up

Create a new SiS app from the Snowsight left pane → "Streamlit" → "+ Streamlit App"
Paste the sample code below; the stage is created automatically on first run
Click "Run" in the upper right, upload a video, and click "Analyze with AI"

Sample Code

import streamlit as st
import io
import os
import re
import uuid
from datetime import datetime
from snowflake.snowpark.context import get_active_session

session = get_active_session()
STAGE_NAME = "VIDEO_ANALYSIS_STAGE"

db = session.get_current_database().strip('"')
schema = session.get_current_schema().strip('"')
STAGE_FQN = f"{db}.{schema}.{STAGE_NAME}"

st.set_page_config(layout="wide")
st.title("🎬 Video Analyzer")
st.caption("Analyze videos on the spot with AI_COMPLETE's video input")

# The model name has to be a string literal in SQL, so offer an allow-list.
# Add to this list as more models gain support.
AVAILABLE_MODELS = [
    "gemini-3.1-pro",
    "gemini-3.1-flash-lite",
    "gemini-3.5-flash",
]

st.sidebar.title("⚙️ Settings")
model = st.sidebar.selectbox("🧠 Model for analysis", AVAILABLE_MODELS)

prompt_template = st.sidebar.text_area(
    "📝 Analysis prompt",
    value=(
        "Summarize this video in about 100 words. "
        "Include the people involved, key scenes, and the emotion conveyed by the audio."
    ),
    height=180
)

@st.cache_resource
def setup_stage():
    try:
        session.sql(f"DESC STAGE {STAGE_FQN}").collect()
    except Exception:
        try:
            session.sql(f"""
                CREATE STAGE IF NOT EXISTS {STAGE_FQN}
                ENCRYPTION = (TYPE = 'SNOWFLAKE_SSE')
                DIRECTORY = (ENABLE = TRUE)
            """).collect()
        except Exception as e:
            st.error(f"Couldn't create the stage. Check your privileges: {e}")
            st.stop()

setup_stage()


def clean_ai_response(text):
    """Strip wrapping double quotes and unescape newlines from AI response."""
    if not isinstance(text, str):
        return text
    text = text.strip()
    if len(text) >= 2 and text.startswith('"') and text.endswith('"'):
        text = text[1:-1]
    text = text.replace("\\n", "\n").replace('\\"', '"')
    return text


uploaded_file = st.file_uploader(
    "Upload a video file (under 100 MB)",
    type=["mp4", "mov", "webm", "avi", "mpeg", "mpg", "flv", "wmv", "3gpp"]
)

if uploaded_file is not None:
    # AI_COMPLETE accepts up to 100 MB combined per request, so reject early
    if uploaded_file.size > 100 * 1024 * 1024:
        st.error("Please use a video under 100 MB.")
        st.stop()

    st.subheader("▶️ Video Preview")
    st.video(uploaded_file)

    if st.button("🤖 Analyze with AI", use_container_width=True, type="primary"):
        try:
            ext = os.path.splitext(uploaded_file.name)[1].lower() or ".mp4"
            safe_ext = ext if re.fullmatch(r"\.[a-z0-9]{2,5}", ext) else ".mp4"
            video_filename = (
                f"video_{datetime.now().strftime('%Y%m%d_%H%M%S')}_"
                f"{uuid.uuid4().hex[:8]}{safe_ext}"
            )

            with st.spinner("Uploading video to stage..."):
                video_stream = io.BytesIO(uploaded_file.getvalue())
                session.file.put_stream(
                    video_stream,
                    f"@{STAGE_FQN}/{video_filename}",
                    auto_compress=False,
                    overwrite=True
                )

            with st.spinner("AI is analyzing the video..."):
                # The model name must be a literal, so inject only allow-listed
                # values; the prompt and filename go through bind variables
                if model not in AVAILABLE_MODELS:
                    st.error("Unsupported model selected.")
                    st.stop()
                query = f"""
                    SELECT AI_COMPLETE(
                        '{model}',
                        ?,
                        TO_FILE('@{STAGE_FQN}', ?)
                    ) AS analysis
                """
                result = session.sql(query, params=[prompt_template, video_filename]).collect()

            st.subheader("📊 Analysis Result")
            if result and len(result) > 0 and result[0]["ANALYSIS"]:
                st.markdown(clean_ai_response(result[0]["ANALYSIS"]))
            else:
                st.warning("Couldn't get an analysis result. Try a different prompt or video.")

        except Exception as e:
            st.error(f"Something went wrong: {str(e)}")
else:
    st.info("👆 Upload a video file to start analyzing.")

Implementation Notes

No extra packages: Works with default Streamlit in Snowflake packages
Auto-created stage: Created with server-side encryption and a directory table on first run
Model from an allow-list: AI_COMPLETE needs the model name as a string literal, so the app uses a selectbox with fixed choices rather than free text
Editable prompt: Update analysis prompt instantly from the sidebar
Video preview: Use st.video to play the uploaded file in-browser

The model name can't be a bind variable. AI_COMPLETE's first argument must be a string literal; passing ? produces a needs to be a string literal compilation error. If you let users choose a model, inject only values that came from an allow-list, as above, and never pass free-form input straight through.

Verified Behavior

The core of the app — sending the file to a stage with session.file.put_stream, then analyzing it with AI_COMPLETE — was verified on a live Snowpark Python session. Every model in the allow-list was also confirmed to accept video input. Paste the code into Streamlit in Snowflake and the same flow runs behind the UI.

App Screenshots

The demo video shown is Pixabay: Meadow, Grass, Spring Meadow, Wind (Pixabay Content License).

Right after uploading a video

Right after running the AI analysis

The sidebar settings panel

Cost

AI_COMPLETE billing follows token-based pricing, like other AI Functions. For direct video/audio input, factor in:

Input tokens: Vary with file length and content
Output tokens: Vary with the requested output length
Model rate: The credit rate of the model you selected applies

See the Snowflake Service Consumption Table for current pricing.

Cost optimization tip: When you only need transcription, use AI_TRANSCRIBE; when you need interpretation, use AI_COMPLETE. A two-stage pipeline that filters out clearly irrelevant videos with a simple prompt before deeper analysis works well too — as does narrowing candidates with AI_MULTI_EMBED before handing them to AI_COMPLETE.

Sample Materials Used in This Article

All free assets used here are commercially licensed so you can reproduce the examples yourself.

Video: Pexels: Pouring Fresh Coffee into Ceramic Mug (Pexels License)
Video: Pexels: Person Having an Interview (Pexels License)
Video: Pixabay: Meadow, Grass, Spring Meadow, Wind (Pixabay Content License)
Audio: LibriVox: The Adventures of Sherlock Holmes (Arthur Conan Doyle) (Public Domain)

The Japanese audio was synthesized with the macOS say command. Note also that meeting.mp4, promo_spot.mp4, creative.png, and meeting_clip.mp3 are placeholder filenames used to illustrate the syntax — substitute your own.

Conclusion

AI_COMPLETE's video and audio support is a meaningful step toward simpler multimodal analytics on Snowflake. With video joining images, documents, and audio, nearly every major unstructured data format can now be queried straight from SQL. Add AI_TRANSCRIBE's video support and AI_MULTI_EMBED's video search, and all three modes — reading media, turning it into text, and searching it — are available from SQL.

Key Benefits

Pass media as-is: Skip transcription — the model picks up vocal tone and visual context
Pick the function that fits the goal: AI_COMPLETE to interpret, AI_TRANSCRIBE to transcribe, AI_MULTI_EMBED to search scenes
Composes with other AI Functions: Chain with AI_CLASSIFY / AI_SENTIMENT / AI_AGG for flexible pipelines
Governance preserved: Your media data never leaves Snowflake
SQL-native: Drops cleanly into your existing data pipelines

Supported models and limits will keep expanding, opening up even more use cases over time. Whether it's call centers, meeting analysis, content moderation, education, or marketing, I hope you'll use Cortex AI's multimodal support to unlock new value from media that previously sat untouched!

Promotion

Snowflake Japan's Official YouTube Channel

The official Snowflake Japan YouTube channel has launched, and it already includes a walkthrough of Snowflake App Runtime. The video covers what App Runtime is and how to get an app deployed, with a live demo. It's in Japanese, but the demo sections should still be easy to follow.

Snowflake What's New Updates on X

I share Snowflake What's New updates on X. Follow for the latest insights:

English Version

Snowflake What's New Bot (English Version)

Japanese Version

Snowflake's What's New Bot (Japanese Version)

Change Log

(20260517) Initial post
(20260606) Updated the supported-models section: gemini-3.5-flash was added for video/audio input
(20260923) Major revision. Added gemini-3.1-flash-lite to the models that accept video and audio directly. Rewrote the comparison section to reflect that AI_TRANSCRIBE now accepts video files as-is, and documented how to request speaker-level timestamps. Added a new section on semantic video search with AI_MULTI_EMBED. Broke per-request limits down by media type, and added sections on passing multiple files via the PROMPT function and on creating a stage for media files. Noted AI_TRANSCRIBE's 10-second minimum billing duration and how its supported formats differ from AI_COMPLETE's. Made the sample app model-selectable and documented that the model name cannot be a bind variable

Original Japanese Article

Snowflake AI_COMPLETE 関数で動画と音声を直接分析

zenn.dev

Supercharge Cortex Code CLI - A Practical Guide to Skills, SubAgents, Hooks and MCP

Tsubasa Kanno — Tue, 31 Mar 2026 16:25:40 +0000

Introduction

I was originally a Cursor user for AI-assisted coding. But as someone who works with Snowflake data and features daily, I realized how powerful it is to have an AI agent that natively connects to Snowflake's data, functions, and catalog — living right in your terminal. That's when I made CoCo CLI my primary tool. (At Snowflake Summit 2026, Cortex Code was officially renamed CoCo. I'll use "CoCo CLI" throughout this article.)

As I used CoCo CLI more, I wanted an agent that could work more autonomously. CoCo CLI offers extensive customization capabilities, and I've gone deep — defining 7 custom skills, 5 custom subagents, quality-check hooks with Slack notifications, and MCP integrations with external tools. The result has been a dramatic improvement in my day-to-day productivity.

This article won't cover CoCo CLI basics or installation — for those, check out the official documentation. Instead, I'll dive into the 4 extensibility features (Skills, SubAgents, Hooks, MCP) and AGENTS.md, sharing tips from the official docs combined with practical insights from my own experience.

Note: This article contains many opinions based on my personal experience. This is not an official Snowflake statement, and customization methods or best practices may change with future updates.

Update (2026/6/6): Following Snowflake Summit 2026, this article reflects the latest naming and feature set. "Cortex Code" is now CoCo, and the lineup has grown to include Plugins (bundle and share skills, subagents, hooks, and MCP servers as a package) and CoCo Desktop (a GUI version, currently in Public Preview).

The Big Picture of CoCo CLI Extensibility

CoCo CLI customization breaks down into two categories:

AGENTS.md — A Markdown file placed at the project root that communicates project-specific rules and constraints to the agent (Official docs: Cortex Code)
4 Extensibility Features — Mechanisms documented on the official Extensibility page that extend the agent's capabilities

Here's a summary of each feature's role:

Feature	Role	Scope	Format
AGENTS.md	Communicate project-specific rules & constraints	Project	Markdown
Skills	Inject domain-specific expertise & workflows	Project / Global	YAML frontmatter + Markdown
SubAgents	Delegate tasks to independent specialized agents	Project / Global	YAML frontmatter + Markdown
Hooks	Intercept lifecycle events for custom control	Project / Global	JSON + Shell scripts
MCP	Add external tool & service integrations	Global	JSON

Let's explore each feature in detail.

AGENTS.md — Injecting Project Rules

Overview

AGENTS.md is a Markdown file placed at the project root that communicates project-specific rules and coding conventions to the CoCo CLI agent. (Official docs: Cortex Code)

AGENTS.md is separate from the 4 extensibility features (Skills, SubAgents, Hooks, MCP) on the Extensibility page. While extensibility features extend the agent's capabilities, AGENTS.md defines the agent's behavioral guidelines.

Attribute	Details
Location	Project root directory
Format	Free-form Markdown
Loading	Auto-loaded at session start
Effect	Improves agent response quality & consistency

Basic Usage

Simply create an AGENTS.md file in your project root:

# Project Rules

## Coding Standards
- Follow Black formatter for Python code style
- Always include type hints
- Use Google-style docstrings

## Snowflake-Specific Rules
- Write SQL in uppercase
- Use full paths for table names: `DB.SCHEMA.TABLE`
- Use `MY_WH` warehouse

## Testing
- Run tests with pytest: `pytest tests/ -v`
- Maintain 80%+ coverage

Tip: Adding AGENTS.md dramatically improves agent responses. For team development, documenting coding standards and project rules in AGENTS.md ensures consistent AI-assisted quality across all team members.

Effective AGENTS.md Structure

Here's the structure pattern I use in practice:

# Project Overview
(Brief description of purpose and architecture)

# Directory Structure
(Key directories and file roles)

# Tech Stack
(Languages, frameworks, tools)

# Coding Standards (Do)
(Style guide, naming conventions, comment policy)

# Don'ts
(Secrets handling, destructive SQL prohibition, direct production access ban)

# Snowflake-Specific Settings
(Connection info, default warehouse/role, naming conventions)

# Testing & Quality
(Test commands, lint commands, CI/CD notes)

# Custom Skills & SubAgents Guide
(Names and purposes of custom skills/subagents used in the project)

TIPS: Making AGENTS.md Work Effectively

AGENTS.md can also be placed at .cortex/AGENTS.md or in subdirectories, and you can use multiple files. However, keep these points in mind:

AGENTS.md is an Instruction at the start of task execution. Writing too many rules tends to dilute compliance. Focus on high-priority items and keep it concise.
Explicit Do / Don't sections are effective. Clearly separating "what to do" from "what not to do" improves the agent's decision accuracy.
Include directory structure. Documenting your project's folder structure helps the agent choose appropriate file locations.
Add a custom skills/subagents guide. Listing names, purposes, and invocation methods of your custom skills/subagents helps the agent use them at the right time.

Important: AGENTS.md is just an Instruction — there's no guarantee the agent will always follow it. For higher compliance rates, clear and concise writing is key. To enforce rules, consider using Hooks (e.g., PreToolUse to block dangerous operations).

Since CoCo CLI is natively integrated with Snowflake, leveraging Snowflake governance features like RBAC (roles), masking policies, and Row Access Policies for data access control is highly effective. Rather than writing "don't directly modify production tables" in AGENTS.md, simply restricting write permissions via roles is far more reliable. Soft guidelines in AGENTS.md, hard enforcement via Hooks and Snowflake governance — this separation is another strength of CoCo CLI.

Skills — Injecting Domain Knowledge

Official docs: Extensibility - Skills

Overview

Skills are Markdown files that define domain-specific expertise and workflows, injected into the agent's context when needed. For example, "demo environment setup procedures," "periodic report creation workflows," or "PoC documentation templates" — by defining frequently-used business workflows as skills, you eliminate the need to instruct from scratch every time.

There are 2 ways to invoke skills:

Explicit invocation — Use the $skill-name prefix to directly specify a skill
Automatic activation — The agent matches your question against skill description fields and auto-loads relevant skills

Many built-in skills have a [REQUIRED] tag, causing them to activate automatically when questions hit their domain. For instance, simply typing "I want to create a Dynamic Table pipeline" automatically loads the dynamic-tables skill with specialized guidance.

Skill Locations

Skills are loaded from multiple locations (highest to lowest priority). (Official docs: Extensibility)

Scope	Path	Description
Project	`.cortex/skills/` or `.claude/skills/`	Project-specific
User	`~/.snowflake/cortex/skills/` or `~/.claude/skills/`	User-specific
Global	`~/.snowflake/cortex/skills/`	Shared across all projects
Session	Added temporarily during session	Disappears when session ends
Remote	Cloned from Git repository	Cached
Bundled	Built into CoCo CLI	Official Snowflake skills

Custom skill creation directories are also documented as .cortex/commands/ or .claude/commands/.

Creating SKILL.md

Skills are Markdown files named SKILL.md with YAML frontmatter at the top:

---
name: my-custom-skill
description: "Description of this skill (shown in skill listings)"
tools:
  - snowflake_sql_execute
  - snowflake_object_search
  - web_search
---

# Purpose
(What this skill does)

# Prerequisites
(Required environment/data for execution)

# Workflow
1. Step 1: ...
2. Step 2: ...
3. Step 3: ...

# Output
(Expected deliverables)

Frontmatter	Required	Description
`name`	Yes	Unique identifier
`description`	Yes	Skill description (shown in `/skill list`)
`tools`	No	Tools to enable when skill is active

CLI Commands

cortex skill list
cortex skill add /path/to/.cortex/skills/my-skill
cortex skill add https://github.com/org/my-skills.git
cortex skill remove /path/to/.cortex/skills/my-skill

Invoking Skills in a Session

There are two main approaches — explicit invocation and automatic activation:

Method	Action	Description
Skill listing	Type `/skill` or `$` in session	Shows available skill candidates
Explicit invocation	`$skill-name instruction`	Loads the specified skill and executes the task
Auto-activation	Just ask your question normally	Agent auto-selects skills matching the `description`

$demo-builder Set up a demo environment
$code-review Review @src/app.py following $security-guidelines

For auto-activation, you don't need to specify skill names. Many built-in skills have [REQUIRED] tags and automatically load when relevant domain questions are asked.

> I want to create a Streamlit app
→ developing-with-streamlit skill auto-activates

> Build a web app that runs on Snowflake (App Runtime)
→ snowflake-apps skill auto-activates

> Analyze my costs
→ cost-intelligence skill auto-activates

Tip: Use cortex skill list from outside a session to check available skills. Before creating custom skills, explore what's already built-in.

Built-in Skills

CoCo CLI ships with dozens of built-in skills covering major Snowflake capabilities, and the count keeps growing with each release. From data engineering to governance, ML, and cost analysis — everything is ready out of the box, making it one of CoCo CLI's biggest strengths.

Category	Skills
Data Foundation	`dynamic-tables`, `iceberg`, `lineage`, `data-quality`
Development	`developing-with-streamlit`, `build-app`, `snowflake-apps`, `snowpark-python`, `snowpark-connect`, `snowflake-notebooks`, `dbt-projects-on-snowflake`
AI / ML	`cortex-agent`, `cortex-ai-functions`, `semantic-view`, `machine-learning`
Governance / Security	`data-governance`, `trust-center`, `network-security`, `key-and-secret-management`
Operations / Cost	`cost-intelligence`, `workload-performance-analysis`, `organization-management`
Data Sharing	`data-cleanrooms`, `declarative-sharing`, `internal-marketplace-org-listing`
Infrastructure	`deploy-to-spcs`, `integrations`, `openflow`, `snowflake-postgres`
Migration / Admin	`snowconvert-assessment`, `dcm`, `dashboard`, `skill-development`, `cortex-code-guide`

Built-in skills change with CoCo CLI version updates and new ones are added regularly. The table above is a snapshot — always check the latest with cortex skill list.

Practical Example: Demo Environment Builder Skill

Here's an example skill for building customer demo environments:

---
name: demo-builder
description: "Build and clean up Snowflake demo environments"
tools:
  - snowflake_sql_execute
  - snowflake_object_search
  - web_search
---

# Demo Builder Skill

## Goal
Build and manage Snowflake demo environments tailored to
customer use cases, in a reproducible manner.

## Workflow
### Phase 1: Requirements
Confirm demo theme, target features, and required datasets.

### Phase 2: Environment Setup
Create DB/schema/warehouse, load sample data,
deploy Streamlit apps as needed.

### Phase 3: Verification
Test all queries/apps and create demo scenarios.

### Phase 4: Cleanup
Generate scripts to safely tear down the environment post-demo.

With this skill defined, simply invoking $demo-builder Set up a Cortex AI demo kicks off the entire workflow automatically.

SubAgents — Specialized Agent Delegation

Official docs: Extensibility - Subagents

Overview

SubAgents are independent, specialized AI agents that operate separately from the main agent. Each can have its own model, tools, and prompts, with parallel execution support.

Feature	Description
Independence	Operates in separate context from main agent
Specialization	Specify optimal model and tools per task
Parallel execution	Up to 50 concurrent agents
Worktree Isolation	Isolate changes using Git worktrees

Built-in SubAgents

CoCo CLI includes these built-in subagent types: (Official docs: Extensibility)

Type	Purpose
`general-purpose`	Full tool access, general-purpose agent
`explore`	Codebase exploration specialist (`quick` / `medium` / `very thorough`)
`plan`	Implementation planning & design
`feedback`	Structured feedback collection

Creating Custom SubAgents

SubAgents are defined as .md files:

Scope	Path
Project	`.cortex/agents/<name>.md` or `.claude/agents/<name>.md`
Global	`~/.snowflake/cortex/agents/<name>.md`
User	`~/.claude/agents/<name>.md`

Agent Definition Example

---
name: critic-reviewer
description: "Performs critical review from code quality and best practices perspective"
tools:
  - Read
  - Grep
  - Glob
  - Bash
model: openai-gpt-5.2
---

# Critic Reviewer Agent

You are a senior software engineer performing code reviews.

## Review Criteria
1. Code readability & maintainability
2. Performance bottlenecks
3. Security concerns
4. Error handling adequacy

## Output Format
- 🔴 Critical: Must fix
- 🟡 Warning: Recommended fix
- 🟢 Info: Room for improvement

Model Selection — The Greatest Strength of SubAgents

Custom subagents let you specify a model per agent via the model field. This is SubAgents' greatest strength.

model: claude-opus-4-6     # For high-accuracy tasks
model: claude-sonnet-4-6   # For lightweight, fast tasks
model: openai-gpt-5.2      # Leverage different model perspectives
model: auto                # Cost-optimized auto-selection

TIPS: Cross-model diversity improves quality

When your main agent uses claude-opus-4-6, deliberately assigning openai-gpt-5.2 to your review subagent enables critical review from a different model's perspective. A different model family can catch blind spots and mistakes that the same model tends to miss.

Meanwhile, for simpler tasks like knowledge curation or log summarization, assigning a lightweight model like claude-sonnet-4-6 keeps costs down while boosting overall throughput.

Use Case	Model Selection Strategy
Main agent	High-accuracy model (`claude-opus-4-6`, etc.)
Critical review	Deliberately use a different model family (`openai-gpt-5.2`, etc.) for diverse perspectives
Knowledge curation / summarization	Lightweight model (`claude-sonnet-4-6`, etc.) for cost efficiency
Exploration / research	`auto` for cost optimization

Session-wide model can also be overridden via the CORTEX_AGENT_MODEL environment variable. (Official docs: Settings)

Invocation

# Auto-delegation (agent decides)
> Search all test files under src/

# Explicit specification
> Use the Explore agent to find all SQL files

# Parallel execution
> In parallel, search for test files and check config files

# Background execution
> Run a background agent to refactor the code

# Worktree Isolation (runs in an isolated git branch)
> Implement feature X with worktree isolation

# Agent management
/agents                    # Agent list (Ctrl-B also works)
> Get the output from agent abc1234
> kill agent abc1234
> Resume agent abc1234 and continue from where it left off

Practical Example: Specialized Agent Configuration

Here's my setup with purpose-specific agents:

Agent	Model	Purpose
critic-reviewer	`openai-gpt-5.2`	Critical review using a different model from main
research-analyst	`auto`	Web research & document analysis
code-implementer	`claude-opus-4-6`	Complex code implementation
qa-validator	`claude-opus-4-6`	Test design & execution
knowledge-curator	`claude-sonnet-4-6`	Knowledge organization & documentation

Hooks — Lifecycle Control

Official docs: Extensibility - Hooks

Overview

Hooks execute custom logic at key lifecycle points in CoCo CLI.

Personally, I consider Hooks the most important of the four extensibility features. As AI agents evolve, we'll increasingly delegate tasks asynchronously. But this creates common pain points:

Unaware — The agent finishes work, but the user doesn't notice and leaves it idle
Stuck — The agent is waiting for user input, but the user doesn't realize it's blocked
Settling — The agent produces low-quality output and completes without improvement

Hooks address these challenges. For example:

Send Slack notifications on Notification events so you never miss an input request or completion
Run quality checks on Stop events and force the agent to continue if results don't meet standards

Hooks have many configuration options and may require some trial-and-error to get the behavior you want. But they're incredibly powerful — I personally receive Slack notifications to issue next instructions and use quality-check hooks to force the agent to self-review and elevate output quality, achieving a truly "set it and forget it" workflow.

Configuration File Locations

Hooks are configured in the following locations (highest to lowest priority):

Scope	Path
Local (highest)	`.cortex/settings.local.json` or `.claude/settings.local.json`
Project	`.cortex/settings.json` or `.claude/settings.json`
User	`~/.claude/settings.json`
Global	`~/.snowflake/cortex/hooks.json`

Available Events

The 11 hook events defined in official docs:

Event	Timing	Can Block?
`PreToolUse`	Before tool execution	Yes
`PostToolUse`	After successful tool execution	No
`PermissionRequest`	When permission is needed	Yes
`UserPromptSubmit`	When user submits prompt	No
`SessionStart`	When session starts	No
`SessionEnd`	When session ends	No
`PreCompact`	Before context compaction	No
`Stop`	When agent response completes	No
`SubagentStop`	When subagent completes	No
`Notification`	On notification (e.g., waiting for user input)	No
`Setup`	During initialization	No

Hook Types

Two types of hooks are available: (Official docs: Extensibility)

Type	Description	Example
`command`	Execute shell commands	`bash /path/to/script.sh`
`prompt`	Evaluate natural language prompt via LLM	`Is this command safe? $ARGUMENTS`

Exit Code Semantics

Hook script exit codes control CoCo CLI behavior:

Exit Code	Meaning	Behavior
0	Success	Process stdout JSON and continue
2	Block	stderr / JSON `reason` sent to agent; operation blocked
Other	Error	Non-blocking. stderr shown only in verbose mode; execution continues

Configuration Format

Example hooks.json:

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "bash /path/to/hooks/quality_review.sh",
            "timeout": 60
          }
        ]
      }
    ],
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "bash /path/to/hooks/validate_bash.sh",
            "timeout": 30
          }
        ]
      }
    ]
  }
}

Matcher Patterns

The matcher field narrows which tools trigger hooks. Regex is supported.

Pattern	Target
`*`	All tools
`Bash`	Bash only
`Edit\|Write`	Edit or Write
`mcp__.*`	All MCP tools
`Notebook.*`	NotebookEdit, NotebookExecute, etc.

Hook Input (stdin)

Hook scripts receive JSON via stdin:

{
  "session_id": "abc123",
  "hook_event_name": "Stop",
  "cwd": "/Users/my-project",
  "transcript_path": "/path/to/transcript.jsonl",
  "tool_name": "Bash",
  "tool_input": {
    "command": "ls -la"
  }
}

Available Environment Variables

These environment variables are available within hook scripts:

Variable	Description
`CORTEX_PROJECT_DIR`	Project directory path
`CORTEX_CODE_REMOTE`	`"true"` in web context
`CORTEX_ENV_FILE`	Persistent environment file path

Example 1: Quality Review Hook (Stop Event)

A hook that performs LLM-based quality checks when the agent tries to complete a task, blocking and continuing work if quality is insufficient:

#!/bin/bash
# quality_review_on_stop.sh

INPUT=$(cat)

# Infinite loop prevention (critical!)
if [ "$(echo "$INPUT" | jq -r '.stop_hook_active')" = "true" ]; then
  exit 0
fi

TRANSCRIPT=$(echo "$INPUT" | jq -r '.transcript_path')

# Get recent interactions and run LLM quality check
REVIEW_RESULT=$(snow sql -q "
  SELECT SNOWFLAKE.CORTEX.COMPLETE(
    'claude-sonnet-4-6',
    'Rate the task completion from 1-10: ...'
  )
" --connection MY_CONN)

SCORE=$(echo "$REVIEW_RESULT" | jq -r '.score')

if [ "$SCORE" -lt 7 ]; then
  echo "Quality score below threshold ($SCORE/10). Please improve." >&2
  exit 2  # Block → agent continues working
fi

exit 0  # Allow → agent stops

Critical: Infinite loop prevention in Stop Hooks is mandatory. When a Stop Hook returns block (exit 2), the agent continues working and the Stop event fires again. Always pass through with exit 0 when the stop_hook_active flag is true.

Example 2: Slack Notification Hook (Notification Event)

A hook that sends Slack notifications when the agent is waiting for user input:

#!/bin/bash
# notify_slack_on_notification.sh

INPUT=$(cat)
MESSAGE=$(echo "$INPUT" | jq -r '.message // "Waiting for input"')

curl -s -X POST "$SLACK_WEBHOOK_URL" \
  -H 'Content-type: application/json' \
  -d "{\"text\": \"🔔 CoCo: $MESSAGE\"}"

exit 0

MCP — External Tool Integration

Official docs: Extensibility - MCP

Overview

MCP (Model Context Protocol) is an open standard protocol for connecting external tools and services to AI agents. The key point here is that CoCo CLI itself functions as an MCP client. This means you can add any publicly available MCP server to give your agent new capabilities.

For example, draw.io MCP for diagrams, GitHub MCP for PR operations, Context7 MCP for latest library documentation — the possibilities are vast. MCP servers are growing daily, so definitely explore MCP servers and mcp.so to find servers that fit your workflow.

Transport Types

Type	Use Case	Communication
`stdio`	Local tools, CLI wrappers	Subprocess (stdin/stdout)
`http`	Web services, APIs	HTTP requests
`sse`	Real-time services	Server-Sent Events

OAuth authentication is supported for HTTP servers. Tokens are stored in ~/.snowflake/cortex/mcp_oauth/ and auto-refreshed.

Configuration File

MCP server configuration goes in ~/.snowflake/cortex/mcp.json:

{
  "mcpServers": {
    "drawio": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@drawio/mcp"]
    },
    "github": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
      }
    }
  }
}

Environment Variable Expansion

Both ${VAR} and $VAR syntax are supported for environment variable expansion in configuration files. (Official docs: Extensibility)

{
  "headers": {
    "Authorization": "Bearer ${MY_API_TOKEN}"
  }
}

Never hardcode API keys in mcp.json. Set them as environment variables in ~/.bashrc or ~/.zshrc like export MY_API_TOKEN="your_token_here" — this is the officially recommended approach.

CLI Commands

cortex mcp add drawio npx -y @drawio/mcp
cortex mcp add my-api https://api.example.com --type http
cortex mcp add my-server npx my-mcp-server -e API_KEY=secret
cortex mcp add my-server https://api.example.com -H "Authorization: Bearer token"
cortex mcp list
cortex mcp get drawio
cortex mcp remove drawio
cortex mcp start drawio    # Connection test

Tool Naming Convention

MCP tools are namespaced for agent access:

mcp__{server-name}__{tool-name}

e.g.: mcp__drawio__open_drawio_xml
      mcp__github__create_pull_request

Session Management

/mcp    # Open MCP status viewer

Practical Example: draw.io MCP

Adding the draw.io MCP server lets you instruct the agent to "create an architecture diagram for this design" and it generates the diagram in the draw.io editor.

cortex mcp add drawio npx -y @drawio/mcp

Usage in session:

> Create an architecture diagram for this system in draw.io

Putting It All Together

The AGENTS.md and 4 extensibility features become even more powerful when combined. Here's a workflow pattern I use daily.

Pattern: AI-Assisted Development Workflow

By combining these features:

AGENTS.md always applies project-specific rules
Skills standardize repetitive workflows
SubAgents process specialized tasks in parallel
MCP connects to external tools
Hooks automate quality checks and notifications on task completion

This creates a truly integrated workflow.

Configuration File Overview

Here's a partial extract of my CoCo CLI configuration structure — the actual setup has many more files, but these are the key ones. (Official docs: Settings)

~/.snowflake/cortex/
├── settings.json           # Main settings (theme, env vars, hooks)
├── mcp.json                # MCP server config
├── hooks.json              # Global hooks
├── permissions.json        # Permission settings
├── hooks/                  # Hook scripts
│   ├── quality_review_on_stop.sh
│   ├── notify_slack_on_stop.sh
│   └── ...
├── agents/                 # Custom SubAgents
│   ├── critic-reviewer.md
│   ├── research-analyst.md
│   └── ...
├── skills/                 # Global Skills
│   ├── demo-builder/SKILL.md
│   ├── competitive-analysis/SKILL.md
│   └── ...
├── memory/                 # Persistent memory
└── ...

Conclusion

CoCo CLI is not just an AI coding assistant — by leveraging AGENTS.md for project rules and the 4 extensibility features (Skills, SubAgents, Hooks, MCP), you can build a powerful AI development environment tailored to your workflow.

Personally, shifting from Cursor to CoCo CLI has been transformative. Being able to use customized agents while natively connected to Snowflake data and functions has dramatically improved my daily productivity. Here's what I find most valuable:

Skills for workflow standardization: Defining repetitive workflows like demo setup and documentation as skills eliminates starting from scratch every time
SubAgents for parallel execution: Running research tasks in parallel dramatically reduces processing time for complex tasks
Hooks for quality gates & notifications: Auto-executing quality checks on task completion via Stop Hook and forcing continued work when quality is insufficient has been incredibly effective for raising output quality
MCP for external tool integration: Calling external tools like draw.io and GitHub directly from the agent dramatically reduces context-switching overhead

CoCo CLI's customization features will continue to evolve. I encourage you to dive into customization and build your own AI development environment!

Reference Links

Document	URL
CoCo CLI official	https://docs.snowflake.com/en/user-guide/cortex-code/cortex-code-cli
Extensibility (Skills, SubAgents, Hooks, MCP)	https://docs.snowflake.com/en/user-guide/cortex-code/extensibility
Settings (Configuration & Priority)	https://docs.snowflake.com/en/user-guide/cortex-code/settings
Security	https://docs.snowflake.com/en/user-guide/cortex-code/security

Promotion

Snowflake What's New Updates on X

I share Snowflake What's New updates on X. Follow for the latest insights:

English Version

Snowflake What's New Bot (English Version)

Japanese Version

Snowflake's What's New Bot (Japanese Version)

Change Log

(20260606) Reflected Snowflake Summit 2026 updates: renamed Cortex Code to CoCo, noted Plugins and CoCo Desktop (Public Preview), generalized the built-in skill count, updated build-react-app to build-app, and added the snowflake-apps skill
(20260401) Initial post

Original Japanese Article

Cortex Code CLI 実践カスタマイズガイド

zenn.dev

Snowflake Data UI Guide - Choose the Right Tool for Every Analytics Use Case

Tsubasa Kanno — Sun, 15 Feb 2026 05:54:49 +0000

Introduction

It's been about two years since I joined Snowflake, and the transformation I've witnessed in data analytics UI has been nothing short of remarkable. Back in early 2024, when it came to working with data in Snowflake, your options were essentially Snowsight worksheets and dashboards, plus third-party BI tools. Streamlit in Snowflake (hereafter referred to as SiS) and Snowpark Container Services (hereafter referred to as SPCS) had just launched but weren't yet mainstream.

Fast forward to today, and the landscape looks completely different. Snowflake CoWork, Snowflake Workspaces, Snowflake Notebooks, Snowflake Managed MCP Server, CoCo, Vercel v0 integration - the list of new options keeps growing. In my daily conversations with customers, one question has become increasingly common: "With all these tools available, which one should we use?"

That's exactly what this article aims to answer. I'll provide a comprehensive overview of every UI option for working with data in Snowflake, covering their strengths, limitations, target users, and ideal use cases. Whether you're a business user, data analyst, data scientist, or developer, I hope this guide helps you find the right tool for your needs!

Note (2026/2/5): Some features mentioned in this article are still in development or Public Preview. They may be significantly updated in the future.

Note: This article represents my personal views and not those of Snowflake. The tool evaluations and use case classifications are based on my personal experience and may vary depending on your organization and project requirements. Please treat this as one perspective.

Update (2026/6/6): This article has been updated following Snowflake Summit 2026. At Summit 2026, Cortex Code was renamed CoCo and Snowflake Intelligence was renamed Snowflake CoWork, so this article uses CoCo / Snowflake CoWork from here on. I also added Snowflake App Runtime and CoCo Desktop, and refreshed release statuses. (Where the original name is the correct historical reference — past event names, external article titles, etc. — I've kept it as-is.)

The Evolution of Snowflake's Data UI

As I mentioned, in early 2024, worksheets, dashboards, and BI tools were the primary ways to interact with Snowflake data. In just two years, this has diversified dramatically. Workspaces has evolved worksheets into a full IDE experience. CoWork enables business users to query data using natural language without writing SQL. Notebooks brings data science workflows entirely within Snowflake. And with SiS Container Runtime, you can now run lightweight dashboards at a fraction of the cost. On the AI front, Copilot has evolved into CoCo, and MCP Server enables AI Agent integration with Snowflake data.

Behind this evolution are two major trends: democratization of data access and AI-native analytics experiences. Data utilization, once dominated by data engineers and analysts, is now extending to business users - with AI serving as the bridge.

UI Options at a Glance

Here's a categorized overview of every UI option available for working with data in Snowflake.

Category	Tool	Primary Users
Snowflake Native UI (Analytics)	Snowflake Workspaces	Data Engineers, Data Analysts, Data Scientists
	Snowflake CoWork	Business Users, Data Analysts
	Snowflake Notebooks	Data Scientists, ML Engineers
Snowflake Native UI (Apps)	SiS	Data Analysts, Data Scientists → Business Users
	Snowflake App Runtime	Full-stack / Frontend Developers
	Native Apps	App Developers, ISVs
	SPCS	ML Engineers, App Developers
AI-Assisted Development	CoCo in Snowsight	Data Engineers, Data Analysts, Data Scientists
	CoCo CLI	Developers, Data Engineers
	CoCo Desktop	Developers, Data Engineers
	Vercel v0 Integration	Developers
AI Agent / MCP Integration	Snowflake Managed MCP Server	Developers, AI Agent Users
	OSS Snowflake MCP Server	Developers, AI Agent Users
Programmatic Access	Snowflake CLI	Developers, DevOps Engineers
	Snowpark Python SDK	Data Engineers, Data Scientists
	SQL API and Connectors	Developers
Third-Party Integration	BI Tools (Tableau, Power BI, etc.)	Data Analysts, Business Users
	Custom Applications	Developers → Business Users

Let's dive into each category in detail.

Snowflake Native UI (Analytics)

Tools available within Snowsight for analyzing and exploring data using SQL or natural language.

Snowflake Workspaces

Overview:
Snowflake Workspaces is an integrated development environment (IDE) available within Snowsight. GA since September 2025, it represents a significant evolution from the traditional worksheet experience. Originally focused on SQL editing, Workspaces now supports Notebooks running directly within the environment, unifying SQL and Python/Notebook development. Shared Workspaces became GA in January 2026 for team collaboration, and Notebooks in Workspaces went GA in February 2026.

Attribute	Details
Key Features	SQL execution, Notebooks, dbt projects, data preview, object management, Git integration, CoCo AI assistance
Primary Users	Data Engineers, Data Analysts, Data Scientists
Status	Workspaces: GA (2025/9), Shared Workspaces: GA (2026/1), Notebooks in Workspaces: GA (2026/2)

Pros:

Zero-setup: start working immediately
Unified environment for SQL, Python (Notebooks), and dbt
CoCo AI assistance for natural language code generation and editing
Git integration for version control
Shared Workspaces for team collaboration
Role-based access control (RBAC) for easy permission management
Parallel query execution from a single file
Share pre-built queries with your team so anyone can run them anytime and view the latest data in tabular format

Cons / Considerations:

Not suited for advanced visualizations

Best Use Cases:

Ad-hoc SQL / Python analysis
Data pipeline development and debugging
dbt project development and execution
ML model prototyping (via Notebooks)
Schema design and data modeling
Team collaboration
Sharing standardized queries for day-to-day data monitoring

Snowflake CoWork

Overview:
Snowflake CoWork (formerly Snowflake Intelligence) is an AI-native analytics platform that lets you ask questions about your data in natural language. Business users can perform data analysis directly without specialized SQL knowledge. Under the hood, Cortex Agents serve as the core AI orchestrator, combining the following tools to fulfill requests:

Cortex Analyst: Text2SQL analysis on structured data
Cortex Search: Hybrid search (vector search + keyword search + semantic reranking) on unstructured data (documents, etc.)
Custom Tools: User-defined Stored Procedures and UDFs (User Defined Functions)

Cortex Agents interpret user requests, select the appropriate tools, execute them, and generate responses - delivering an agentic analytics experience.

Attribute	Details
Key Features	Natural language Q&A, automatic chart generation, insight surfacing, custom tool execution
Primary Users	Business Users, Data Analysts
Status	GA (2025/11)
Highlight	Semantic Models / Semantic Views for high-accuracy answers

Pros:

No SQL required - analyze data with natural language
Fully contained within Snowflake for security
Easy to scale across the entire organization
Semantic Models unify business terminology and data lineage
Cross-analyze structured and unstructured data

Cons / Considerations:

Requires upfront preparation of Semantic Models / Semantic Views

Best Use Cases:

KPI reporting for executives
Self-service analytics for sales/marketing teams
Instant answers to recurring business questions
Analysis combining internal documents and data

Snowflake Notebooks

Overview:
Snowflake Notebooks is a Jupyter-style notebook environment available within Snowsight. It supports interactive analysis combining Python, SQL, and Markdown, and you can create Streamlit-powered visualizations directly within cells. GA since November 2024.

Two runtime options are available:

Runtime	Characteristics
Warehouse Runtime	Runs kernels on a warehouse. Fast startup, ideal for standard SQL analysis and Python processing
Container Runtime	Runs on Snowpark Container Services (SPCS). GPU support and flexible package management via `pip`

Attribute	Details
Key Features	Python/SQL execution, Streamlit visualizations, collaborative editing, Git integration
Primary Users	Data Scientists, ML Engineers
Status	GA (2024/11)

Pros:

Complete data science environment within Snowflake
Python libraries (pandas, matplotlib, scikit-learn, etc.) available
Create interactive Streamlit visualizations directly in cells
CoCo AI assistance for natural language code generation and editing
Easy documentation of analysis processes
Built for team collaboration
Snowpark ML integration for ML workflows
Container Runtime enables deep learning and large-scale ML with GPU (PyTorch, TensorFlow pre-installed)

Cons / Considerations:

Some feature differences compared to local Jupyter Notebooks
Container Runtime requires External Access Integration setup for external packages

Best Use Cases:

Exploratory Data Analysis (EDA)
ML model prototyping
Deep learning model training and inference with GPU (Container Runtime)
Creating and sharing analysis reports

Snowflake Native UI (Apps)

Tools for building and running business-user-facing applications, accessible from Snowsight. Typically, developers build the apps and business users consume them.

Streamlit in Snowflake (SiS)

Overview:
SiS is a service for developing and deploying web applications using Python. You can rapidly build data apps without any frontend knowledge. Apps are created, edited, and run directly from Snowsight, with full integration into Snowflake's authentication and authorization.

Attribute	Details
Key Features	Python web app development, Snowflake auth integration, Cortex AI integration
Primary Users	Data Analysts, Data Scientists → Business Users
Status	GA (AWS/Azure: 2024/1, GCP: 2024/5)
Highlight	Streamlit's simplicity + Snowflake's security

Pros:

End-to-end app development using only Python
Full integration with Snowflake authentication and authorization
Rapidly build custom analytics tools for business users
Easy to integrate AI capabilities (chat, summarization, classification, etc.) via Cortex AI
CoCo AI-assisted coding in the Snowsight editor

Cons / Considerations:

Limited flexibility for highly custom UI designs
For cost optimization or flexible package management, consider Container Runtime below

Best Use Cases:

Custom analytics dashboards and visualization apps for teams
Data entry and update applications
AI/ML model demo apps
Internal self-service analytics tools

SiS Container Runtime (GA)

Traditional SiS uses Warehouse Runtime, but a Container Runtime option is now also available (GA since March 2026). Container Runtime executes app code on SPCS while queries run on a separate warehouse.

The development experience is identical to standard SiS. You write and deploy code in the same Snowsight SiS editor, and CoCo AI-assisted coding is fully available. You can create, edit, and run apps without worrying about the underlying runtime differences.

Key Benefits of Container Runtime:

Feature	Description
Separated App and Query Execution	App code runs on a compute pool, queries on a warehouse. Optimize each resource independently
Lightweight Resource Options	Run on compute pools cheaper than warehouses (e.g., `CPU_X64_XS` at 0.06 credits/hour)
Shared Instance Efficiency	All users share a single instance. Second user onward connects instantly
Full Cache Support	`@st.cache_data` caches are shared across users, reducing query execution
Flexible Package Management	Install any package from PyPI, use the latest Streamlit version

This is especially impactful for always-on dashboards and lightweight visualization apps from a cost perspective. If you need a team dashboard that runs continuously within Snowflake, SiS Container Runtime is a compelling choice - low cost and built entirely in Python.

For a deep dive into SiS Container Runtime, check out my previous article: SiS Container Runtime - Run Streamlit Apps at a Fraction of the Cost

Snowflake App Runtime

Overview:
Snowflake App Runtime is a new platform that lets you deploy full-stack web apps like Next.js directly inside Snowflake (introduced at Snowflake Summit 2026 as Public Preview). While SiS is Python-centric, App Runtime lets you leverage the JavaScript / TypeScript (React / Next.js) ecosystem. Apps run as a dedicated APPLICATION SERVICE object on SPCS, inheriting Snowflake's SSO, RBAC, and governance. There's no Docker or infrastructure to set up, and authentication is automatic.

Combined with CoCo's snowflake-apps skill, you can go from prompt to scaffold, local preview, and deployment in one continuous flow.

Attribute	Details
Key Features	Build/deploy full-stack web apps, direct access to Snowflake data, automatic SSO
Primary Users	Full-stack / Frontend Developers, internal app developers
Status	Public Preview (Node.js / Next.js-centric; Python support planned)
Highlight	Full web expressiveness — custom UI, multi-step business flows

Pros:

Highly customizable UI with React / Next.js
Publish apps without moving data outside Snowflake (governance inherited)
An authenticated URL is issued automatically — no need to build your own login layer
End-to-end from a CoCo prompt to deployment

Cons / Considerations:

In Public Preview, so the spec may change (Trial accounts are not eligible)
The supported stack is currently Node.js / Next.js-centric

SiS vs. App Runtime:

Quickly visualize data in Python → SiS
Build a rich web app with custom UI or business flows → App Runtime

Best Use Cases:

Internal business web apps (input forms, approval workflows, etc.)
Custom-UI data visualization dashboards
Per-user reference tools with row-level security applied

I cover Snowflake App Runtime in depth in a dedicated article: Snowflake App Runtime - Deploy Full-Stack Web Apps Right Next to Your Data from a Single Prompt.

Snowflake Native Apps

Overview:
Snowflake Native Apps is a framework for developing and distributing packaged applications on Snowflake. Multiple distribution methods are available: public distribution via Snowflake Marketplace, direct distribution to specific accounts via Private Listing, and distribution to non-Snowflake customers via Reader Accounts. Apps can use SiS for the UI or build custom frontends with SPCS.

Attribute	Details
Key Features	App packaging, Marketplace / Private Listing / Reader Account distribution, version management
Primary Users	App Developers, ISVs
Status	GA (2024/1)
Highlight	Combine data sharing and apps for distribution

Pros:

Distribute apps and data as a package
Consumers use apps + data without copying data
Continuous update delivery
Monetization via Marketplace

Cons / Considerations:

Relatively steep learning curve
Primarily for ISVs and data providers

Best Use Cases:

Commercial application distribution
Data Product offerings
Cross-organization solution sharing

Snowpark Container Services (SPCS)

Overview:
SPCS is a fully managed service for running containerized applications on Snowflake. The core value proposition is "bringing compute to the data, rather than moving data to the compute." Deploy Docker images and run ML inference or custom applications with GPU/CPU resources - all within Snowflake. Available on AWS, Azure, and GCP.

Attribute	Details
Key Features	Container execution, GPU support, ML model serving, batch jobs
Primary Users	ML Engineers, App Developers
Status	GA (AWS: 2024/8, Azure: 2025/2, GCP: 2025/8)
Highlight	Any programming language or framework

Pros:

Data never leaves Snowflake: Meets security and compliance requirements
Any programming language or library (Docker-compatible)
GPU support for ML model inference and private LLM execution
No Kubernetes knowledge required for container operations
Inherits Snowflake's security, governance, and access controls
Can serve as the backend for Native Apps

Cons / Considerations:

Requires containerization knowledge
More setup effort compared to SiS
External internet access disabled by default (requires External Access Integration)

When to choose SiS vs. SPCS:

Simple dashboards and visualization apps → SiS
Custom apps, ML inference, batch processing, non-Python languages → SPCS

Best Use Cases:

ML model inference endpoints (including private LLM execution)
Batch data processing with sensitive data
Applications requiring custom runtimes
Migrating existing Docker apps to Snowflake
Native Apps backend

AI-Assisted Development

Tools that leverage AI to accelerate data and app development.

CoCo

Overview:
CoCo, released in February 2026 as the successor to Snowflake Copilot, is a Snowflake-native AI coding agent. It significantly expands and evolves Copilot's capabilities, so if you've been using Copilot, CoCo is your upgrade path.

It enables complex tasks in data engineering, analytics, machine learning, and agent development through natural language. What sets it apart is its deep understanding of Snowflake's data, compute, governance, and operations.

Available in multiple forms:

Form	Description	Status
CoCo in Snowsight	AI coding assistance within Snowsight	GA (2026/3)
CoCo CLI	Use from your local terminal, VS Code, Cursor, and other editors	GA
CoCo Desktop	Native IDE app for Mac / Windows, integrating editor, terminal, agent, browser, and notebooks	Public Preview

Pros:

Code generation with awareness of your Snowflake data context
Accelerates data pipeline, analytics, and AI app development
Enterprise-grade security and governance
Integrates into existing development workflows (local IDE)

Cons / Considerations:

This is a developer-oriented tool - generated code should be reviewed by technical users before use
CoCo CLI requires environment setup

Best Use Cases:

SQL query authoring and optimization
Data pipeline construction
Cortex Agents development and tuning
Day-to-day data development task acceleration

CoCo Desktop (Public Preview)

CoCo Desktop delivers CoCo's capabilities as a dedicated, IDE-like app (Mac / Windows, Public Preview). It includes a file editor, integrated terminal, agentic execution loop, agentic browser, and notebooks, assisting development with deep Snowflake awareness. A standout feature is that you can create Streamlit / Snowflake App Runtime apps from a prompt in the App Gallery, preview them locally, and deploy them directly - making it a natural entry point to the various app-development paths covered in this article.

Vercel v0 Integration

Note: The Vercel v0 integration is a partner integration announced in November 2025. For a Snowflake-native way to build and deploy React / Next.js apps, Snowflake App Runtime has since become available (see Snowflake App Runtime above) - consider App Runtime first when building full-stack web apps inside Snowflake. The integration is still rolling out; the information below is based on the announcement and specifications may change.

Overview:
The Vercel v0 integration, announced in November 2025, will enable generating and deploying Next.js applications powered by Snowflake data using natural language. v0 is Vercel's AI assistant for full-stack application development. Generated apps are deployed on SPCS. Unlike the Snowflake-native App Runtime, this is positioned as an option used in combination with the Vercel platform.

Attribute	Details
Key Features	Natural language data querying, app generation, deployment to Snowflake
Primary Users	Developers
Status	Under Development (Coming Soon)

SiS vs. Vercel v0 Integration:

Aspect	Streamlit in Snowflake (SiS)	Vercel v0 Integration
Language	Python	TypeScript / JavaScript (Next.js)
Target Users	Data Analysts, Data Scientists	Frontend / Full-stack Developers
App Nature	Dynamic web apps from data analysis (Python-first)	Production-grade native web apps from the start
UI Flexibility	Streamlit components	React-based, highly customizable
Deploy Target	Snowflake (Warehouse / Container Runtime)	SPCS

SiS is ideal for data analysts and scientists who want to quickly turn their analyses into interactive apps using Python. Vercel v0 integration is for frontend developers who want to build production-quality native web apps from the start.

Capabilities:

Ask questions about data: Query schemas, table structures, and data content in natural language
Generate applications: Create Next.js apps for data visualization, dashboards, internal tools, etc.
Deploy to Snowflake: Deploy generated apps on SPCS

Architecture:
Vercel's "Secure Vibe Coding Architecture" ensures application and auth layers are managed by Vercel while compute and data stay within Snowflake. Data never leaves Snowflake, and existing security policies and access controls apply.

Example Use Cases:

Sales pipeline dashboards
Inventory monitoring tools
Customer analytics applications
Financial reporting interfaces

Official blog: Build and deploy data applications on Snowflake with v0

AI Agent / MCP Integration

Interfaces for accessing Snowflake data and capabilities from AI Agents.

Who should consider MCP? If you're already using AI Agents like Claude Desktop, Cursor, or GitHub Copilot and want to add Snowflake to your AI ecosystem, this is for you. MCP (Model Context Protocol) - often called the "USB-C for AI" - provides unified access to Snowflake data from multiple AI tools with a single configuration.

Key Value of MCP Integration:

Value	Description
Reduced Integration Cost	No need for individual connectors per AI tool - unified access via MCP
Less Context Switching	Access Snowflake data directly within your AI assistant without interrupting workflow
Existing Governance	Leverage Snowflake's RBAC and security model as-is
Future Investment	MCP is becoming the de facto standard for agent communication

Snowflake Managed MCP Server

Overview:
Snowflake Managed MCP Server is an MCP server hosted and managed by Snowflake. Configure it from Snowsight and connect MCP Clients like Claude Desktop or Cursor to Snowflake capabilities. GA since November 2025.

Attribute	Details
Key Features	Cortex Search / Analyst / Agents connectivity, SQL execution
Primary Users	Developers, AI Agent Users
Status	GA (2025/11)

Pros:

Easy setup (configure from Snowsight, ~15-25 minutes)
Operates within Snowflake's security model
Seamless integration with Cortex features (Analyst / Search / Agents)
Officially supported, no infrastructure management required

Cons / Considerations:

Requires separate MCP Client setup

Best Use Cases:

Access Snowflake data from Claude Desktop / Cursor and other MCP Clients
Automated data analysis via AI Agents
RAG application backends

OSS Snowflake MCP Server

Overview:
An open-source MCP Server published by Snowflake Labs on GitHub. Runs locally and connects with MCP Clients.

Attribute	Details
Key Features	Cortex Search / Analyst / Agents, SQL execution, object management, Semantic View queries
Primary Users	Developers, AI Agent Users
Highlight	Fine-grained permission control, local execution, early access to new features

Pros:

Fine-grained SQL execution permissions (e.g., allow SELECT only)
Flexible customization in local environments
Early access to the latest features

Cons / Considerations:

Requires local setup and management
Community support (not officially supported)

Best Use Cases:

Snowflake data analysis in development environments
Ad-hoc analysis from IDEs like Cursor
AI Agent integration PoCs

For a deep dive into using the Snowflake MCP Server with Cursor, check out my previous article: Unlock Advanced Data Analytics in Cursor with Snowflake MCP Server

Programmatic Access

Tools for connecting to Snowflake via command line or code for development and operations.

Snowflake CLI

Overview:
Snowflake CLI is Snowflake's official open-source command-line interface. Positioned as the successor to SnowSQL, it includes SnowSQL's capabilities plus integrated development and deployment features for Snowpark apps, Streamlit apps, Native Apps, and more. Snowflake recommends migrating from SnowSQL to Snowflake CLI.

Attribute	Details
Key Features	SQL execution, Snowpark / Streamlit / Native Apps deployment, Git integration, automation scripts
Primary Users	Developers, DevOps Engineers
Highlight	Open source, modern development workflow support

Pros:

CI/CD pipeline integration
Deploy Snowpark, Streamlit, and Native Apps from the command line
Open source with community-driven extensions
Usable from SSH-connected servers

Cons / Considerations:

No GUI - not ideal for visual data exploration
Some command syntax differences when migrating from SnowSQL

If you're currently using SnowSQL, refer to the official migration guide to plan your transition to Snowflake CLI.

Snowpark Python SDK

Overview:
A Python SDK for natively interacting with Snowflake. Provides intuitive data manipulation through the DataFrame API.

Attribute	Details
Key Features	DataFrame API, UDF/UDTF/UDAF creation, ML integration
Primary Users	Data Engineers, Data Scientists
Highlight	Write in Python, execute server-side (pushdown)

Pros:

pandas-like interface
Performance gains through Snowflake-side pushdown execution
Snowpark ML integration for machine learning workflows

Cons / Considerations:

Some advanced SQL features require direct SQL

SQL API and Connectors

Overview:
Snowflake provides a REST API and drivers/connectors for various programming languages, enabling applications to connect to Snowflake for data operations.

SQL REST API

The Snowflake SQL REST API (/api/v2/statements) enables SQL execution via HTTP requests.

Endpoint	Purpose
`POST /api/v2/statements`	Execute SQL statements
`GET /api/v2/statements/<handle>`	Check execution status
`POST /api/v2/statements/<handle>/cancel`	Cancel execution

Authentication supports OAuth and JWT (key-pair authentication).

Drivers / Connectors

A comprehensive set of drivers and connectors for various programming languages:

Category	Drivers / Connectors
Database Drivers	JDBC, ODBC, Go, .NET, Node.js, PHP PDO
Python Ecosystem	Snowflake Connector for Python, Snowpark, Snowpark ML, SQLAlchemy
Data Integration	Snowflake Connector for Kafka, Snowflake Connector for Spark

Attribute	Details
Key Features	SQL execution, data operations, multi-language support, system integration
Primary Users	Developers
Highlight	Broad language support: Java, Python, Node.js, Go, .NET, ODBC, JDBC, and more

REST API vs. Connectors:

Aspect	SQL REST API	Drivers / Connectors
Access Method	HTTP requests	Library-based
Best For	Lightweight integrations, async processing, serverless environments	High-volume data processing, complex workflows
Session Management	Stateless	Auto-managed by connector

Pros:

Easy integration into existing applications
Fits microservice architectures well
Broad programming language support
REST API works in serverless environments (AWS Lambda, etc.)

Cons / Considerations:

REST API is best for lightweight operations; connectors recommended for high-volume data processing

Third-Party Integration

Methods for connecting to Snowflake from external tools and applications.

BI Tools

Overview:
Connect to Snowflake from existing BI tools like Tableau, Power BI, Looker, Sigma, ThoughtSpot, and others for visualization.

Attribute	Details
Representative Tools	Tableau, Power BI, Looker, Sigma, ThoughtSpot, Metabase, etc.
Primary Users	Data Analysts, Business Users
Highlight	Rich visualizations, leverage existing skills

Pros:

Extensive visualization capabilities
Leverage existing BI skills and expertise
Integrate with tools already in your organization
Enterprise-grade features (scheduling, permissions, distribution, etc.)

Cons / Considerations:

Additional BI tool licensing costs
Data freshness concerns with extract mode
Some tools may lag in supporting latest Snowflake features

Best Use Cases:

Executive dashboards
Scheduled report distribution
Complex visualizations
Large-scale BI deployments

Custom Applications

Overview:
Build custom applications using Snowflake Connectors or SQL API.

Attribute	Details
Tech Stack	React, Vue.js, Flask, Django, or any framework
Primary Users	Developers → Business Users
Highlight	Complete customization control

Pros:

Full control over UI/UX
Deep integration with existing systems
Custom business logic implementation

Cons / Considerations:

Security design is your responsibility
Authentication and authorization must be implemented

Use Case-Based Selection Guide

For those asking "So which one should I actually use?" - here's a practical selection guide.

Recommended Tools by User Type

User Type	Recommended Tool	Why
Business User	Snowflake CoWork	No SQL required - analyze with natural language. Cortex Agents combine tools to answer
Data Analyst	Workspaces	Flexible analysis with SQL / Python
Data Scientist	Snowflake Notebooks	Interactive analysis with Python + SQL + Streamlit. GPU via Container Runtime
Data Engineer	Workspaces + Snowflake CLI	SQL / Notebooks / dbt development, CI/CD integration
App Developer (Python)	SiS	Rapid app development in Python. Container Runtime for cost optimization
App Developer (Custom)	SPCS	Any language/framework, GPU, data stays in Snowflake
AI Agent User	Snowflake Managed MCP Server	Connect existing AI Agents (Claude Desktop, Cursor, etc.) to Snowflake
Full-Stack Developer	Snowflake App Runtime	Deploy React / Next.js full-stack web apps inside Snowflake. Can be created from a CoCo prompt
Full-Stack Developer (Vercel)	Vercel v0 Integration	Generate Next.js apps in combination with the Vercel platform

Recommended Tools by Use Case

Use Case	Recommended Tool	Notes
Ad-hoc SQL / Python analysis	Workspaces	Notebooks also available
Natural language analytics	CoWork	Cortex Agents + Analyst / Search / Custom Tools
Exploratory Data Analysis (EDA)	Notebooks (Warehouse Runtime)	Python + SQL + Streamlit visualizations
Deep learning / Large-scale ML	Notebooks (Container Runtime)	GPU available, PyTorch / TensorFlow pre-installed
Team dashboards / KPI monitoring	SiS (Container Runtime)	Low-cost always-on, shared caching, Python-only development
Custom app development	SiS (Warehouse Runtime)	Rapid development, Snowflake auth integration
Custom web app development (React / Next.js)	Snowflake App Runtime	Deploy web apps with custom UI / business flows inside Snowflake
ML model inference / LLM execution	SPCS	GPU support, data stays in Snowflake
App distribution / monetization	Native Apps	Marketplace / Private Listing / Reader Account distribution
AI Agent integration	Snowflake Managed MCP Server	Easy setup, officially supported
AI Agent integration (custom)	OSS Snowflake MCP Server	Fine-grained permissions, local execution
Advanced visualizations	BI Tools (Tableau, Power BI, etc.)	Proven enterprise features
dbt project development	Workspaces	dbt Projects on Snowflake integration
CI/CD / automation	Snowflake CLI	Automate Snowpark / SiS / Native Apps deployment

CoCo AI Assistance: Workspaces, Notebooks, and SiS all support CoCo for AI-assisted coding. Generate and edit code with natural language to dramatically boost development productivity. For local IDEs (VS Code, Cursor, etc.), CoCo CLI is also available.

Key Decision Factors

SQL / Python skills: Proficient → Workspaces / Notebooks. Not proficient → CoWork
Need dashboards / visualizations? Simple ones → SiS (Container Runtime) at low cost. Advanced → BI tools
Customization needs: High → SiS / SPCS / custom development
GPU required? → Notebooks (Container Runtime) or SPCS
Can data leave Snowflake? No → Snowflake native UI (SiS / SPCS / Notebooks)
Existing tools: Already have BI tools → connect them to Snowflake. Already using AI Agents → connect via MCP Server
Scale of deployment: Organization-wide → CoWork. Team-level → CoWork / SiS
AI strategy: Heavy AI Agent use → MCP Server. Development assistance → CoCo. App generation → App Runtime (or Vercel v0 in combination with Vercel)

Conclusion

Snowflake's data UI has diversified remarkably in just two years. While the abundance of options can feel overwhelming, it also means you can now choose the tool that's truly optimal for your organization and use case.

Personally, I find the most value in:

Snowflake CoWork for data democratization: Business users who can't write SQL can now query data directly
Snowflake Managed MCP Server for AI Agent integration: Analyze data without leaving your development tools
SiS simplicity with Container Runtime: Build custom dashboards and analytics tools in Python alone, with Container Runtime enabling low-cost always-on operation
CoCo / Vercel v0 integration potential: AI-assisted development dramatically accelerating data and app development

The analytics experience is evolving from static reports to interactive conversations with data, gaining insights alongside AI. I hope this guide helps you find the right tools to accelerate your data journey!

Promotion

Snowflake What's New Updates on X

I share Snowflake What's New updates on X. Follow for the latest insights:

English Version

Snowflake What's New Bot (English Version)

Japanese Version

Snowflake's What's New Bot (Japanese Version)

Change Log

(20260606) Major update following Snowflake Summit 2026: added Snowflake App Runtime and CoCo Desktop, reflected the Cortex Code → CoCo and Snowflake Intelligence → Snowflake CoWork renames, updated statuses (CoCo in Snowsight GA, SiS Container Runtime GA), and refreshed the Vercel v0 section
(20260205) Initial post

Original Japanese Article

Snowflake データ活用 UI ガイド - 最適なツール選択で分析体験を向上させる

zenn.dev

Revolutionize Your Search with Snowflake Cortex Search Multi-Index and Index-Specific Boosts

Tsubasa Kanno — Mon, 12 Jan 2026 03:52:54 +0000

Introduction

Snowflake's Cortex Search just received a major upgrade with Multi-Index and Index-Specific Boosts! These powerful features dramatically enhance search flexibility and precision, enabling scenarios like "exact match on product codes while semantic search on descriptions."

In this article, I'll walk you through these new features using hands-on examples with dummy data in Snowsight, demonstrating their value and practical implementation.

For a comprehensive overview of Cortex Search fundamentals, check out the official Snowflake documentation.

Note (2026/1/12): Cortex Search Multi-Index is currently in Public Preview. Features may be significantly updated in the future.

Note: A Custom Embedding (BYO Embed: Bring Your Own Embedding) feature was also released alongside these features, but is not covered in this article.

Note: This article represents my personal views and not those of Snowflake.

Cortex Search Quick Recap

Let me briefly explain what Cortex Search is. Cortex Search is a fully-managed enterprise search service provided by Snowflake.

Key Features

Hybrid Search: Combines vector search (semantic similarity) with keyword search (lexical similarity) for high-precision results
Automatic Embedding Generation: Automatically and regularly vectorizes text data to enable semantic search capabilities
Fully Managed: No infrastructure management or tuning required - ready to use immediately
Snowflake Native: Complete integration with Snowflake's data governance and security features

What is Multi-Index?

Multi-Index enables you to create separate indexes for multiple columns with different characteristics, and combine them during search.

Previously, Cortex Search was primarily designed for searching a single column. However, real-world business scenarios often require searching across multiple fields like "product code," "product name," and "product description." With Multi-Index, you can integrate these into a single search service and apply the most appropriate search method for each field's characteristics.

Multi-Index Use Cases

Use Case	Description
Cross-field Search	Search across product codes, names, and descriptions with different characteristics simultaneously
Field-specific Search Logic	Apply strict keyword matching to product codes while using semantic search for descriptions
Precise Result Control	Adjust the importance of each field to achieve optimal search results for your business requirements

What are Index-Specific Boosts?

Index-Specific Boosts enable you to adjust the weights of individual columns within the same index type in Multi-Index searches.

For example, if you have product_code and product_name as TEXT INDEXes, even when searching with the same keyword, the optimal results differ depending on whether you want to prioritize "matches in product code" or "matches in product name." Index-Specific Boosts let you flexibly control this balance per search query.

Parameter	Purpose	Description
weights	Search type weighting	Adjusts the overall balance between keyword search (texts), vector search (vectors), and reranker scores
text_boosts	TEXT INDEX weighting	Adjusts individual column weights within TEXT INDEXes
vector_boosts	VECTOR INDEX weighting	Adjusts individual column weights within VECTOR INDEXes

Official documentation: Customizing Cortex Search scoring - Index-specific boosts

Business Value and Benefits

Transforming Search Experience

Previous Limitation	Multi-Index & Index-Specific Boosts Solution
Limited to single-field search	Cross-field integrated search now possible
Same search logic applied to all fields	Apply optimal search methods (keyword/semantic) per field
Difficult to customize search results	Flexible ranking adjustments with Index-Specific Boosts
Hybrid search balance was automatic	Customize each field's contribution per search query

Expected Benefits

E-commerce Product Search — Prioritize exact matches on SKUs and product codes while supporting semantic search on product descriptions
Internal Knowledge Search — Balance strict matching on document titles with semantic search on document bodies
Customer Support — Apply different weights to FAQ titles and bodies to deliver results that better match user intent

Cortex Search Integration Scenarios

Cortex Search maximizes its value when combined with various Snowflake features beyond standalone use.

AI Agent Context

Snowflake Managed MCP Server — When AI Agents access data within Snowflake, they can search and retrieve enterprise-specific domain knowledge through Cortex Search. Multi-Index enables flexible searching across both structured and unstructured data.
Snowflake Intelligence — Cortex Search serves as the foundation for searching relevant documents and knowledge to generate more accurate responses to natural language queries.

Data App Context

Streamlit in Snowflake — Easily build user-friendly search interfaces by calling Cortex Search within Streamlit apps. With Index-Specific Boosts, you can dynamically control search weighting from the application layer.

The Biggest Value I See

Personally, I find tremendous value in "being able to flexibly control the balance between exact match and fuzzy search for multiple fields per search query." Previously, you could only search with a uniform balance across the entire search service, but by combining Multi-Index with Index-Specific Boosts, you can now dynamically change search behavior based on user intent and business requirements.

Furthermore, I believe enterprise search will serve as a core component for complementing enterprise-specific domain knowledge in RAG and AI Agent applications. In other words, improvements in search flexibility and precision directly translate to improvements in RAG response quality and AI Agent decision accuracy. In this sense, Multi-Index and Index-Specific Boosts represent a significant update that contributes to elevating enterprise AI adoption overall, not just a mere search feature improvement.

Important Considerations

Please keep the following points in mind when using Multi-Index:

Consideration	Details
Cost	Creating and maintaining multiple indexes may increase compute and storage costs
Performance	Search performance may be affected by the number and configuration of indexes, so proper design is important
Data Size	Query results under 1 million rows are recommended for optimal performance (contact Snowflake if exceeding 1 million rows)

Official documentation:

Hands-on Tutorial

Let's try out Multi-Index and Index-Specific Boosts! We'll use dummy product catalog data to create a Cortex Search service in Snowsight and verify the behavior with SQL queries.

Demo Scenario

For this demo, we'll simulate an e-commerce product search scenario:

product_code: Product code (exact match is critical, like SKUs)
product_name: Product name (balance between exact match and keyword matching)
description: Product description (semantic fuzzy search is effective)

We'll create a Multi-Index on these three fields and experience how search results change when we adjust each field's importance based on the search context.

Step 1: Prepare Demo Data

First, let's create a table and insert sample data in Snowsight's SQL Worksheets. Run the following query (feel free to use your own data if available):

-- Create demo database and schema
CREATE DATABASE IF NOT EXISTS cortex_search_demo;
CREATE SCHEMA IF NOT EXISTS cortex_search_demo.multi_index_demo;

USE DATABASE cortex_search_demo;
USE SCHEMA multi_index_demo;

-- Create warehouse (you can use your existing warehouse)
CREATE WAREHOUSE IF NOT EXISTS cortex_search_wh WITH
   WAREHOUSE_SIZE = 'X-SMALL';

-- Create product catalog table
CREATE OR REPLACE TABLE product_catalog (
    product_id NUMBER,
    product_code VARCHAR,
    product_name VARCHAR,
    description VARCHAR,
    category VARCHAR,
    price NUMBER(10,2)
);

-- Insert sample data (fictional products)
INSERT INTO product_catalog VALUES
    (1, 'CBP-16-X9-PRO', 'CloudBook Pro 16 X9', 'The latest 16-inch professional laptop featuring the X9 processor. Known for high-performance graphics processing and extended battery life. Ideal for video editing and CAD work.', 'Laptop', 3988.00),
    (2, 'CBP-14-X7', 'CloudBook Pro 14 X7', 'Compact 14-inch model with X7 processor. Lightweight 1.2kg design perfect for mobile workers.', 'Laptop', 2488.00),
    (3, 'CBA-15-X5', 'CloudBook Air 15 X5', 'Amazingly thin and light 15-inch large-screen laptop. Handles everything from daily use to creative work.', 'Laptop', 1988.00),
    (4, 'PPD-13-Z4', 'PixelPad Pro 13 Z4', 'Top-tier tablet with Z4 chip. Perfect for illustration and design work when paired with a stylus pen.', 'Tablet', 2188.00),
    (5, 'ODK-24-X9', 'OmniDesk 24 X9', 'Beautiful all-in-one desktop with 4.5K display. Ideal for home and office use. Quiet design for comfortable extended work sessions.', 'Desktop', 1988.00),
    (6, 'TNB-X1-G12', 'TechNova Business X1 Gen12', 'Lightweight business laptop. A proven model that balances durability and portability. Packed with security features.', 'Laptop', 2980.00),
    (7, 'FXP-11-HYBRID', 'FlexPad 11 Hybrid', 'The definitive 2-in-1 device. Flexible enough to use as both a tablet and laptop. Recommended for frequent travelers.', 'Tablet', 1768.80),
    (8, 'VNS-15-CREATOR', 'VisionStudio 15 Creator Edition', 'High-performance laptop for creators. 4K OLED display ideal for video production. Runs video editing software smoothly.', 'Laptop', 3298.00);

-- Verify data
SELECT * FROM product_catalog;

Verify that the table is created and data is inserted in Snowsight.

Step 2: Create Cortex Search Service with Multi-Index

Next, let's create a Cortex Search service with indexes on multiple columns.

Warning: As of January 2026, Snowsight's GUI does not support creating Multi-Index Cortex Search services. You must use SQL to create Multi-Index services.

Run the following query in Snowflake SQL Worksheets:

-- Create Cortex Search Service with Multi-Index
CREATE OR REPLACE CORTEX SEARCH SERVICE product_multi_search
    TEXT INDEXES product_code, product_name
    VECTOR INDEXES description (model='voyage-multilingual-2')
    ATTRIBUTES category, price
    WAREHOUSE = cortex_search_wh
    TARGET_LAG = '1 hour'
    AS (
        SELECT
            product_id,
            product_code,
            product_name,
            description,
            category,
            price
        FROM product_catalog
    );

Multi-Index uses TEXT INDEXES and VECTOR INDEXES to create indexes:

TEXT INDEXES: Indexes for keyword (lexical) search. Suitable for fields like product_code or product_name where exact match or keyword matching is important.
VECTOR INDEXES: Indexes for vector (semantic) search. Suitable for fields like description where semantic similarity search is important. We explicitly specify the voyage-multilingual-2 model for better multilingual performance.

Note: When creating a Multi-Index service, you must specify at least one column in VECTOR INDEXES. Omitting VECTOR INDEXES will result in an error.

SQL Reference: CREATE CORTEX SEARCH SERVICE

Verify that the service is created in AI Studio's Cortex Search list view or via SHOW CORTEX SEARCH SERVICES;.

Step 3: Testing Multi-Index Search and Index-Specific Boosts

This is where Multi-Index and Index-Specific Boosts really shine!

Warning: As of January 2026, the Playground does not support Index-Specific Boosts, so we'll execute searches via SQL queries.

When querying a Multi-Index service, you can use the multi_index_query parameter to explicitly specify which index receives which query. Additionally, the scoring_config weights parameter lets you adjust the weight balance between keyword search (texts) and vector search (vectors).

Official documentation: Query a Cortex Search Service - Multi-index queries

Demo Scenario Explanation

The key point of Multi-Index is that you can send different appropriate queries to each index. Similar to the official documentation examples, you send keyword-matching strings to TEXT INDEX and semantic queries to VECTOR INDEX.

For this demo, we'll verify the following scenario:

TEXT INDEX (product_name) receives the keyword "CloudBook" → Products with "CloudBook" in the name get keyword matches
VECTOR INDEX (description) receives the semantic query "a PC that's safe to use while traveling" → Products with semantically related descriptions get matches

Product Name	TEXT Match	VECTOR Match
CloudBook Air 15 X5	✓ (contains "CloudBook" in name)	△ (no mention of security)
CloudBook Pro 14 X7	✓ (contains "CloudBook" in name)	△ (no mention of security)
TechNova Business X1 Gen12	✗	✓ ("Packed with security features" → semantically related to "safe")

By changing weights, you can control which type of match is prioritized.

Case 1: Prioritize Keyword Search (texts)

By increasing the texts weight, products with "CloudBook" in their names appear at the top.

-- Prioritize keyword search: set texts weight high
SELECT
    value['product_name']::VARCHAR AS product_name,
    value['description']::VARCHAR AS description
FROM TABLE(FLATTEN(PARSE_JSON(
    SNOWFLAKE.CORTEX.SEARCH_PREVIEW(
        'cortex_search_demo.multi_index_demo.product_multi_search',
        '{
            "multi_index_query": {
                "product_name": [{"text": "CloudBook"}],
                "description": [{"text": "a PC that is safe to use while traveling"}]
            },
            "scoring_config": {
                "weights": {
                    "texts": 5,
                    "vectors": 1,
                    "reranker": 1
                }
            },
            "columns": ["product_name", "description"],
            "limit": 5
        }'
    )
)['results']));

Verify that CloudBook series products appear at the top. This is because the product names contain the keyword "CloudBook." Of course, vector search results are also factored in, albeit with lower weight.

Case 2: Prioritize Vector Search (vectors)

By increasing the vectors weight, products with descriptions semantically related to "a PC that's safe to use while traveling" appear at the top.

-- Prioritize vector search: set vectors weight high
SELECT
    value['product_name']::VARCHAR AS product_name,
    value['description']::VARCHAR AS description
FROM TABLE(FLATTEN(PARSE_JSON(
    SNOWFLAKE.CORTEX.SEARCH_PREVIEW(
        'cortex_search_demo.multi_index_demo.product_multi_search',
        '{
            "multi_index_query": {
                "product_name": [{"text": "CloudBook"}],
                "description": [{"text": "a PC that is safe to use while traveling"}]
            },
            "scoring_config": {
                "weights": {
                    "texts": 1,
                    "vectors": 5,
                    "reranker": 1
                }
            },
            "columns": ["product_name", "description"],
            "limit": 5
        }'
    )
)['results']));

Verify that "TechNova Business X1 Gen12" appears at the top. Its description mentions "Packed with security features," which semantically matches the query "safe to use while traveling."

Case 3: Query Only VECTOR INDEX

With multi_index_query, you can also target only specific indexes. When searching only the VECTOR INDEX without TEXT INDEX, you get results based purely on semantic relevance.

-- Query only VECTOR INDEX (description)
SELECT
    value['product_name']::VARCHAR AS product_name,
    value['description']::VARCHAR AS description
FROM TABLE(FLATTEN(PARSE_JSON(
    SNOWFLAKE.CORTEX.SEARCH_PREVIEW(
        'cortex_search_demo.multi_index_demo.product_multi_search',
        '{
            "multi_index_query": {
                "description": [{"text": "high-spec PC ideal for creative video production"}]
            },
            "columns": ["product_name", "description"],
            "limit": 3
        }'
    )
)['results']));

Verify that products with descriptions mentioning "video editing," "video production," or "creator" (like VisionStudio 15 Creator Edition) appear at the top.

Case 4: Using Index-Specific Boosts (text_boosts)

With text_boosts, you can adjust the weight of each column within TEXT INDEXes individually. In this demo, we have product_code and product_name defined as TEXT INDEXes, so even when searching with the same keyword "Pro," you can control whether to prioritize matches in product code or product name.

Note: multi_index_query requires at least one VECTOR INDEX to be specified. TEXT INDEX-only queries will result in an error.

-- text_boosts: prioritize product_name matches over product_code
SELECT
    value['product_code']::VARCHAR AS product_code,
    value['product_name']::VARCHAR AS product_name,
    value['description']::VARCHAR AS description
FROM TABLE(FLATTEN(PARSE_JSON(
    SNOWFLAKE.CORTEX.SEARCH_PREVIEW(
        'cortex_search_demo.multi_index_demo.product_multi_search',
        '{
            "multi_index_query": {
                "product_code": [{"text": "Pro"}],
                "product_name": [{"text": "Pro"}],
                "description": [{"text": "high-performance laptop"}]
            },
            "scoring_config": {
                "weights": {
                    "texts": 5,
                    "vectors": 1,
                    "reranker": 1
                },
                "functions": {
                    "text_boosts": [
                        {"column": "product_code", "weight": 1},
                        {"column": "product_name", "weight": 3}
                    ]
                }
            },
            "columns": ["product_code", "product_name", "description"],
            "limit": 5
        }'
    )
)['results']));

The keyword "Pro" appears in both product codes (CBP-16-X9-PRO) and product names (CloudBook Pro 16 X9, PixelPad Pro 13 Z4, etc.), but since we've weighted product_name higher, products with "Pro" in their names are prioritized.

Note: When using text_boosts, you must specify weights for all columns defined as TEXT INDEXes. Specifying only some columns will result in an error. The same applies to vector_boosts.

Search Results Comparison Summary

Case	Configuration	Expected Top Products	Reason
Case 1	Prioritize texts	CloudBook series	"CloudBook" keyword matches in product name
Case 2	Prioritize vectors	TechNova Business X1 Gen12	"security features" semantically matches "safe to use while traveling"
Case 3	description only	VisionStudio 15 Creator Edition	"video production" related descriptions semantically match
Case 4	text_boosts with product_name priority	Products with "Pro" in name	text_boosts sets product_name weight higher

As you can see, by sending different queries to TEXT INDEX and VECTOR INDEX, adjusting the weight balance with weights, fine-tuning individual column weights with text_boosts/vector_boosts, and targeting specific indexes, you can flexibly control search results.

Conclusion

How was it? Cortex Search's Multi-Index and Index-Specific Boosts enable flexible cross-field search and fine-grained weight adjustments based on search context.

I see significant value in the following points:

Enhanced Search Flexibility: Integrate and search across fields with different characteristics like product codes, names, and descriptions
Dynamic Search Control: Change boost values per search to switch between exact-match focus ↔ fuzzy-search focus
Business Requirement Alignment: Deliver optimal search experiences across various scenarios including e-commerce, internal knowledge bases, and customer support
AI Agent Accuracy Improvement: Enhanced search flexibility and precision directly improves RAG response quality and AI Agent decision accuracy

In an era where AI Agents are increasingly adopted within enterprises, enterprise search becomes a core component for complementing domain knowledge. Multi-Index and Index-Specific Boosts represent a significant update that contributes to elevating enterprise AI adoption overall, not just a mere search feature improvement.

If you're considering RAG application development or enterprise search system implementation, I highly encourage you to leverage this Multi-Index feature. Snowflake's AI capabilities continue to evolve as the "AI platform for enterprise data"!

Promotion

Snowflake What's New Updates on X

I share Snowflake What's New updates on X. Follow for the latest insights:

English Version

Snowflake What's New Bot (English Version)

Japanese Version

Snowflake's What's New Bot (Japanese Version)

Change Log

(20260112) Initial post

Original Japanese Article

https://zenn.dev/snowflakejp/articles/334e112057725c

SiS Container Runtime - Run Streamlit Apps at a Fraction of the Cost

Tsubasa Kanno — Tue, 23 Dec 2025 12:09:04 +0000

Introduction

Hey everyone! Quick off-topic confession: I've recently gotten into collecting Topps trading cards - MLB and NBA mostly. There's something incredibly satisfying about pulling a rare rookie card after opening a bunch of packs. It's become my new stress-relief hobby and honestly, my happiness levels are through the roof! 🏀⚾ Anyway, back to the tech stuff...

It's finally here! Container Runtime for Streamlit in Snowflake (SiS) launched in Public Preview! (It subsequently reached GA in March 2026.)

Previously, SiS used warehouses as the runtime environment. While warehouses are optimized for query execution and work great for data-heavy analytical apps, they were often overkill for many applications. Running a simple visualization app shouldn't require spinning up a full warehouse - and I know many of you felt the same way about the cost implications.

Container Runtime changes everything. It allows you to allocate smaller, more appropriate resources and separates app execution from query execution. This is a game-changer for cost optimization.

In this article, I'll walk you through SiS Container Runtime - from its core concepts and differences from Warehouse Runtime, to costs, considerations, package management, and a hands-on tutorial building a simple data visualization app.

Note (2025/12/23): SiS Container Runtime is currently in Public Preview. Features may be significantly updated in the future. (It subsequently reached GA in March 2026.)

Update (2026/6/6): Following Snowflake Summit 2026, I added a pointer to the related Snowflake App Runtime. Note that SiS Container Runtime reached GA in March 2026, and along with it, secret references via st.secrets, sharing via the app-viewer URL (no Snowsight UI required), and logging/tracing also became generally available. (Any "Preview" wording in the body reflects the state at the time of writing.)

Note: This article represents my personal views and not those of Snowflake.

What is SiS Container Runtime?

SiS Container Runtime is a new runtime environment for running Streamlit apps on Snowflake. Unlike the traditional Warehouse Runtime, it takes a container-based approach, executing app code on a compute pool.

Key Features

Feature	Description
Long-running Service	Apps run as persistent services where all users accessing the same app share a single instance
Fast Startup	Users connect to an already-running app, resulting in faster access
PyPI Package Support	Install packages from PyPI using `pyproject.toml` or `requirements.txt`
Latest Streamlit	Use Streamlit 1.49+ (including `streamlit-nightly`)
Full Cache Support	Leverage Streamlit's caching features across user sessions

Runtime environments for Streamlit apps (Snowflake Documentation)

Warehouse Runtime vs Container Runtime

Here's a comprehensive comparison of the two runtime environments:

Feature	Warehouse Runtime	Container Runtime
Compute	App code and internal queries run on warehouse	App code runs on compute pool node, internal queries run on warehouse
Base Image	Linux in Python stored procedure	Linux in Snowpark container
Python Version	3.9, 3.10, 3.11	3.11
Streamlit Version	1.22+ (select from Snowflake-provided versions)	1.49+ (any PyPI version, including `streamlit-nightly`)
Dependency Management	`environment.yml` from Snowflake Conda channel	`pyproject.toml` or `requirements.txt` from PyPI
Version Pinning	`=` operator, `*` wildcard	`==` operator, `<, <=, >=, >` with comma-separated lists
Entry Point Location	Root of source directory	Root or subdirectory
Streamlit Server	Temporary individual instance per user session	Persistent shared instance for all user sessions
Caching	No cross-session caching	Full Streamlit caching support
Startup Time	Slower (on-demand app creation per user)	Faster per user (but slower initial deployment)

The Value of Container Runtime

The true value of Container Runtime lies in resource optimization.

1. Separation of App and Query Execution

With Warehouse Runtime, both app code and queries ran on the same warehouse. This meant warehouse resources were consumed even for simple UI rendering.

Container Runtime separates these concerns: app code runs on a compute pool while queries run on a warehouse. You can now allocate minimal compute pool resources for app execution and appropriately-sized warehouses for query execution.

2. Lightweight Resource Options

Compute pools offer more affordable options than warehouses. For example:

Gen1 XS Warehouse: 1 credit/hour
Compute Pool CPU_X64_XS: 0.06 credits/hour

That's approximately 1/16th the cost! For lightweight visualization apps, this difference is significant.

3. Shared Instance Efficiency

With Warehouse Runtime, each user got their own app instance. Container Runtime shares a single instance across all users. The second user onward connects instantly to an already-running app, improving perceived performance.

4. Cross-Session Caching

With Warehouse Runtime, Streamlit's @st.cache_data and @st.cache_resource decorators only cached within individual sessions. If User A cached a query result, User B would still execute the query again.

With Container Runtime, caches are shared across users. When User A caches a query result, User B can reuse that cache, reducing query execution and improving both performance and cost efficiency.

Cost Considerations

Container Runtime involves two types of resources:

1. Compute Pool

Compute pools are billed per node. Costs vary by node size (Instance Family), but options cheaper than the smallest warehouse (XS) are available.

Tip: Streamlit runs as a single process, so multiple CPUs don't provide much benefit. Choose the smallest node size that meets your memory requirements to optimize costs.

Recommended compute pool settings:

Parameter	Recommendation	Reason
`INSTANCE_FAMILY`	Small sizes like `CPU_X64_XS`	Streamlit is single-process, start small
`MIN_NODES`	Number of different apps to run simultaneously	Each app uses one node
`MAX_NODES`	Higher than `MIN_NODES`	Prevent node shortages when adding new apps

2. Query Warehouse

The warehouse for internal queries uses traditional credit-based billing. Choose an appropriate size based on query complexity and data volume.

Working with compute pools (Snowflake Documentation)

Important Considerations

Here are some things to keep in mind when using Container Runtime.

1. Python Version Compatibility

Container Runtime currently supports Python 3.11 only. Ensure your app and all dependencies are compatible with Python 3.11.

2. `_snowflake` Module Not Supported

The _snowflake module available in Warehouse Runtime is not available in Container Runtime. Use native Python libraries like Snowflake Python Connector instead.

For example, to get the active session (commonly used in SiS), change your import:

# NG: Not available in Container Runtime
from _snowflake import get_active_session

# OK: Use this instead
from snowflake.snowpark.context import get_active_session

3. Shared Resources

All users share disk, compute, and memory resources in Container Runtime. Design your app with efficient resource usage in mind.

4. Deployment Time

Container Runtime requires container startup during initial deployment, which may take longer than Warehouse Runtime.

5. External Access Integration

Installing packages from external package indexes like PyPI requires External Access Integration configuration.

External access integrations (Snowflake Documentation)

6. Sleep Timer and Compute Pool Auto-Stop

Warehouse Runtime includes a sleep timer feature that automatically stops apps after a period of inactivity. Container Runtime doesn't have an equivalent sleep timer, but an app (service) is automatically suspended after 3 days with no viewer access (as of GA). That said, note that the compute pool itself does not stop immediately when an app session ends.

To minimize costs, consider setting up a Task to stop compute pools during off-hours:

-- Example: Stop compute pool daily at 10 PM
CREATE OR REPLACE TASK STOP_STREAMLIT_POOL_TASK
    WAREHOUSE = SIS_QUERY_WH
    SCHEDULE = 'USING CRON 0 22 * * * America/New_York'
AS
    ALTER COMPUTE POOL STREAMLIT_POOL STOP ALL;

That said, compute pools are very affordable, so running them continuously has limited cost impact. Choose the approach that fits your operational style.

Managing Dependencies

Container Runtime uses pyproject.toml or requirements.txt instead of environment.yml.

requirements.txt Example

streamlit==1.41.0
pandas>=2.0.0
plotly>=5.18.0

pyproject.toml Example

[project]
name = "my-streamlit-app"
version = "1.0.0"

[project.dependencies]
streamlit = "==1.41.0"
pandas = ">=2.0.0"
plotly = ">=5.18.0"

Note: Warehouse Runtime uses = for version pinning, while Container Runtime uses ==.

Item	Warehouse Runtime	Container Runtime
Config File	`environment.yml`	`pyproject.toml` or `requirements.txt`
Package Source	Snowflake Conda channel	PyPI or other external indexes
Version Pinning	`=`	`==`
Range Specification	`*` wildcard	`<, <=, >=, >, !=` with comma-separated lists

Dependency management for Streamlit apps (Snowflake Documentation)

Hands-on: Building a Sales Dashboard

Let's build a simple data visualization app using SiS Container Runtime!

Prerequisites

Snowflake account (AWS, Azure, or GCP commercial region)
Role with the following privileges:

Privilege	Object	Notes
USAGE	Database	Database where you create the app
CREATE STREAMLIT, USAGE	Schema	Schema where you create the app
USAGE	Warehouse	Warehouse for query execution
USAGE	Compute pool	Compute pool for app execution
CREATE COMPUTE POOL	Account	If creating a new compute pool
CREATE INTEGRATION	Account	If creating a new External Access Integration

Privileges required to create and use a Streamlit app (Snowflake Documentation)

Step 1: Set Up the Environment

Let's run the following SQL in Snowsight SQL Worksheets to set up our demo environment!

First, create the database, schema, and stage for source code:

-- Create database and schema
CREATE DATABASE IF NOT EXISTS SIS_CONTAINER_DB;
CREATE SCHEMA IF NOT EXISTS SIS_CONTAINER_DB.APP_SCHEMA;

-- Create stage for source code
CREATE OR REPLACE STAGE SIS_CONTAINER_DB.APP_SCHEMA.APP_STAGE
  ENCRYPTION = (TYPE = 'SNOWFLAKE_SSE')
  DIRECTORY = (ENABLE = TRUE);

-- Create sample data table
CREATE OR REPLACE TABLE SIS_CONTAINER_DB.APP_SCHEMA.SALES_DATA (
    SALE_DATE DATE,
    PRODUCT VARCHAR(100),
    REGION VARCHAR(50),
    SALES_AMOUNT NUMBER(10, 2)
);

-- Insert sample data
INSERT INTO SIS_CONTAINER_DB.APP_SCHEMA.SALES_DATA VALUES
    ('2024-01-01', 'Product A', 'East', 1000.00),
    ('2024-01-01', 'Product B', 'East', 1500.00),
    ('2024-01-01', 'Product A', 'West', 800.00),
    ('2024-01-02', 'Product B', 'West', 1200.00),
    ('2024-01-02', 'Product A', 'East', 1100.00),
    ('2024-01-03', 'Product B', 'East', 1800.00),
    ('2024-01-03', 'Product A', 'West', 950.00),
    ('2024-01-04', 'Product B', 'West', 1400.00),
    ('2024-01-04', 'Product A', 'East', 1050.00),
    ('2024-01-05', 'Product B', 'East', 1600.00);

Step 2: Create Compute Pool

Create a compute pool to run app code:

-- Create compute pool
CREATE COMPUTE POOL IF NOT EXISTS STREAMLIT_POOL
    MIN_NODES = 1
    MAX_NODES = 3
    INSTANCE_FAMILY = CPU_X64_XS;

-- Check compute pool status
SHOW COMPUTE POOLS;
DESCRIBE COMPUTE POOL STREAMLIT_POOL;

Note: Compute pool startup may take a few minutes. Wait until SHOW COMPUTE POOLS shows state as ACTIVE or IDLE.

Step 3: Create External Access Integration

Create an External Access Integration to allow package installation from PyPI.

Snowflake provides a default network rule snowflake.external_access.pypi_rule for PyPI access, so you don't need to create your own:

-- Create External Access Integration (using Snowflake-managed PyPI network rule)
CREATE OR REPLACE EXTERNAL ACCESS INTEGRATION PYPI_ACCESS_INTEGRATION
    ALLOWED_NETWORK_RULES = (snowflake.external_access.pypi_rule)
    ENABLED = TRUE;

External network access examples (Snowflake Documentation)

Step 4: Prepare Application Files

Create these two files and upload them to the stage.

streamlit_app.py

import streamlit as st
import pandas as pd
from snowflake.snowpark.context import get_active_session

# Page configuration
st.set_page_config(layout="wide")

# Get Snowflake session
session = get_active_session()

# Title
st.title("📊 Sales Dashboard")
st.markdown("A simple sales visualization app running on Container Runtime.")

# Load data
@st.cache_data(ttl=60)
def load_data():
    df = session.sql("SELECT * FROM SALES_DATA").to_pandas()
    return df

df = load_data()

# Sidebar filters
st.sidebar.header("Filter Settings")
selected_products = st.sidebar.multiselect(
    "Select Products",
    options=df['PRODUCT'].unique(),
    default=df['PRODUCT'].unique()
)
selected_regions = st.sidebar.multiselect(
    "Select Regions",
    options=df['REGION'].unique(),
    default=df['REGION'].unique()
)

# Filter data
filtered_df = df[
    (df['PRODUCT'].isin(selected_products)) &
    (df['REGION'].isin(selected_regions))
]

# Display metrics
col1, col2, col3 = st.columns(3)
with col1:
    st.metric("Total Sales", f"${filtered_df['SALES_AMOUNT'].sum():,.2f}")
with col2:
    st.metric("Transaction Count", f"{len(filtered_df):,}")
with col3:
    st.metric("Average Sale", f"${filtered_df['SALES_AMOUNT'].mean():,.2f}")

# Charts
st.subheader("Daily Sales Trend")
daily_sales = filtered_df.groupby('SALE_DATE')['SALES_AMOUNT'].sum().reset_index()
st.line_chart(daily_sales, x='SALE_DATE', y='SALES_AMOUNT')

st.subheader("Sales by Product")
product_sales = filtered_df.groupby('PRODUCT')['SALES_AMOUNT'].sum().reset_index()
st.bar_chart(product_sales, x='PRODUCT', y='SALES_AMOUNT')

# Data table
st.subheader("Detailed Data")
st.dataframe(filtered_df, use_container_width=True)

# Footer
st.markdown("---")
st.markdown("🚀 Powered by Streamlit in Snowflake Container Runtime")

requirements.txt

streamlit>=1.41.0
pandas>=2.0.0

Step 5: Upload Files to Stage

Upload the files via Snowsight UI or use PUT commands:

-- Upload via SnowSQL or local environment
PUT file:///path/to/streamlit_app.py @SIS_CONTAINER_DB.APP_SCHEMA.APP_STAGE AUTO_COMPRESS=FALSE OVERWRITE=TRUE;
PUT file:///path/to/requirements.txt @SIS_CONTAINER_DB.APP_SCHEMA.APP_STAGE AUTO_COMPRESS=FALSE OVERWRITE=TRUE;

-- Verify stage contents
LIST @SIS_CONTAINER_DB.APP_SCHEMA.APP_STAGE;

Step 6: Create Streamlit App

Create the Streamlit app with Container Runtime:

-- Create query warehouse (skip if using existing warehouse)
CREATE WAREHOUSE IF NOT EXISTS SIS_QUERY_WH
    WAREHOUSE_SIZE = 'XSMALL'
    AUTO_SUSPEND = 60
    AUTO_RESUME = TRUE;

-- Create Streamlit app
CREATE OR REPLACE STREAMLIT SIS_CONTAINER_DB.APP_SCHEMA.SALES_DASHBOARD_APP
    FROM '@SIS_CONTAINER_DB.APP_SCHEMA.APP_STAGE'
    MAIN_FILE = 'streamlit_app.py'
    QUERY_WAREHOUSE = SIS_QUERY_WH
    RUNTIME_NAME = 'SYSTEM$ST_CONTAINER_RUNTIME_PY3_11'
    COMPUTE_POOL = STREAMLIT_POOL
    EXTERNAL_ACCESS_INTEGRATIONS = (PYPI_ACCESS_INTEGRATION);

Key CREATE STREAMLIT Parameters

Parameter	Description
`FROM`	Stage path containing source code
`MAIN_FILE`	Entry point Python file
`QUERY_WAREHOUSE`	Warehouse for query execution
`RUNTIME_NAME`	Specify `SYSTEM$ST_CONTAINER_RUNTIME_PY3_11`
`COMPUTE_POOL`	Compute pool for app code execution
`EXTERNAL_ACCESS_INTEGRATIONS`	External access integration (for PyPI access)

Step 7: Run the App

In Snowsight, click 'Streamlit' in the left pane and select your SALES_DASHBOARD_APP.

Your app is running! 🎉 You've successfully deployed a Streamlit app on Container Runtime!

Note: Initial startup may take a few minutes for container initialization and package installation. Subsequent startups will be faster due to caching.

Migration Checklist

When migrating existing Warehouse Runtime apps to Container Runtime, use this checklist:

Item	Action
Python 3.11 Compatibility	Verify app and all dependencies work with Python 3.11
`_snowflake` Module Usage	Replace with `snowflake.snowpark.context` etc.
`environment.yml` Conversion	Convert to `requirements.txt` or `pyproject.toml`
Version Specification Syntax	Change `=` to `==`, `*` to `>=` etc.
Compute Pool Creation	Create appropriately-sized compute pool
External Access Integration	Create if PyPI access is needed

Migrate to a container runtime (Snowflake Documentation)

Conclusion

SiS Container Runtime is a long-awaited feature that separates app execution from query execution and enables lightweight resource allocation for apps.

The days of spinning up a warehouse just to run a simple visualization app are over! Container Runtime shines in use cases like:

Always-on Dashboards: Dashboards with frequent multi-user access
Lightweight Visualization Apps: Simple apps without heavy analytical processing
Cache-Leveraging Apps: Apps that cache and reuse query results

It launched in Public Preview and reached GA in March 2026. I encourage you to try this feature and make your Snowflake app development more efficient!

If you want to deploy a full-stack web app like React / Next.js (rather than Python) inside Snowflake, Snowflake App Runtime — introduced at Snowflake Summit 2026 — is another option. See "Snowflake App Runtime - Deploy Full-Stack Web Apps Right Next to Your Data from a Single Prompt" for details.

I'm excited to explore more ideas using SiS Container Runtime and will share useful apps I create in future blog posts. Stay tuned!

Promotion

Snowflake What's New Updates on X

I share Snowflake What's New updates on X. Follow for the latest insights:

English Version

Snowflake What's New Bot (English Version)

Japanese Version

Snowflake's What's New Bot (Japanese Version)

Change Log

(20260606) Updated following Snowflake Summit 2026: added a pointer to Snowflake App Runtime and noted the GA of SiS Container Runtime
(20251223) Initial post

Original Japanese Article

https://zenn.dev/snowflakejp/articles/abe3379e6e44cd

Auto-Generate Snowflake Semantic Views with AI - A Developer's Fast-Track to Cortex Analyst

Tsubasa Kanno — Thu, 09 Oct 2025 12:53:00 +0000

Introduction

Cortex Analyst is one of Snowflake's most exciting features, enabling revolutionary natural language data analysis. Business users who don't usually write queries can simply ask "What are the top 10 products by sales last month?" and get instant insights without SQL - true data democratization in action!

However, for Cortex Analyst to reach its full potential, you need a well-structured semantic layer as the foundation. Snowflake offers Semantic Models or Semantic Views to accomplish this, but creating semantic layers requires time and effort: understanding table structures, defining business logic, setting appropriate descriptions and synonyms, and more.

If you're thinking "I want to use Cortex Analyst, but setting up the semantic layer is taking forever..." - you're in the right place! Today I'm introducing a stored procedure that auto-generates semantic views using AI. This tool lets you quickly create a baseline semantic view from existing tables, giving you a fast start toward delivering analytics environments to business users.

Note: This stored procedure is designed to assist with initial semantic view creation. We recommend customizing the generated views according to your business requirements.

Note: At the June 2025 Snowflake Summit, an official semantic layer auto-generation feature was announced. This stored procedure serves as a stopgap solution until the official feature is released. When the official feature launches, I'll write about it as well!

Note: This article represents my personal views and not those of Snowflake.

What is a Semantic View?

A semantic view is a Snowflake schema-level object that adds business context to physical database tables. It maps technical column names (e.g., amt_ttl_pre_dsc) to business-friendly concepts (e.g., "Total Sales", "Sales Amount") with detailed descriptions (e.g., "Total sales value for stores in the metropolitan area"), bridging the gap between data and business.

Even more importantly, semantic views help AI correctly understand database structure and business logic. Cortex Analyst can generate high-precision SQL queries from natural language questions precisely because of the semantic layer. Through synonyms and detailed descriptions, AI learns to understand that "last month's sales", "total sales", and "sales amount" all refer to the same concept, enabling it to select the right tables and columns for accurate query generation.

Components of a Semantic View

Semantic views consist of these elements:

Element	Description	Examples
Facts	Primarily numeric fact data (row-level attributes)	Sales quantity, unit price, amount, etc.
Dimensions	Category and attribute data (analysis axes)	Product name, customer ID, date, region, etc.
Metrics	Aggregated indicators (business KPIs)	Total sales, average unit price, sales growth rate, etc.

Each element can be defined with:

Synonyms: Business aliases and natural phrasings (e.g., "sales" → "revenue", "sales amount")
Comment: Business explanations including units, ranges, and other details

Why Semantic Views Matter

Semantic views provide these key values:

Improved Cortex Analyst Accuracy: Serves as the foundation for AI to understand natural language and generate accurate SQL
Consistent Business Definitions: Unified business metrics across the entire organization
Data Democratization: Enables non-technical users to access data

For more details, see the official Snowflake documentation - Semantic View Overview.

Note: For information about Semantic Models (YAML format), see the Cortex Analyst Semantic Model Documentation. This article focuses on the newer Semantic Views feature.

Challenges in Creating Semantic Layers

Creating semantic layers manually involves these tasks:

Understanding table structure (table definitions, column names, data types, sample data review)
Classifying Facts, Dimensions, and Metrics
Identifying business-relevant synonyms actually used in the field
Considering appropriate descriptions (Comments) for each element
Defining the structure in SQL syntax

For large tables or multiple tables, this process takes considerable time. However, spending too much time on preparation delays the delivery of analytics environments to business users - having a quality baseline to start with is extremely valuable!

AI-Powered Auto-Generation Stored Procedure

Overview

The GENERATE_SEMANTIC_VIEW stored procedure I'm introducing auto-generates semantic views through these steps:

Retrieve Table Information: Get column info, data types, and comments using DESCRIBE TABLE
Analyze Sample Data: Infer actual usage and data characteristics from the first 5 rows
AI-Generated SQL: LLM via AI_COMPLETE function (like claude-sonnet-4-5) generates semantic view DDL
Create Semantic View: Execute the generated SQL

Key Features

Feature	Description
Fully Automated	Automatically classifies Facts, Dimensions, and Metrics by just specifying table name
Rich Synonyms	Infers actual usage from sample data to generate natural business-relevant synonyms
Detailed Descriptions	Auto-generates Comments with business meaning for each element
Customizable	Specify which LLM model to use (default: claude-sonnet-4-5)

Stored Procedure Code

The complete code for the GENERATE_SEMANTIC_VIEW stored procedure is provided below.

CREATE OR REPLACE PROCEDURE GENERATE_SEMANTIC_VIEW(
    SOURCE_DATABASE VARCHAR,      -- Source database name
    SOURCE_SCHEMA VARCHAR,        -- Source schema name
    SOURCE_TABLE VARCHAR,         -- Source table name
    TARGET_DATABASE VARCHAR,      -- Target database name
    TARGET_SCHEMA VARCHAR,        -- Target schema name
    TARGET_VIEW_NAME VARCHAR,     -- Semantic view name to create
    LLM_MODEL VARCHAR DEFAULT 'claude-sonnet-4-5' -- LLM model to use
)
RETURNS VARCHAR
LANGUAGE SQL
EXECUTE AS CALLER
AS
$$
DECLARE
    -- Table information
    column_info VARCHAR;
    sample_data_json VARCHAR;
    table_comment VARCHAR;

    -- AI generation results
    ai_response VARCHAR;

    -- Final SQL
    create_view_sql VARCHAR;

BEGIN
    -- ================================================================================
    -- STEP 1: Retrieve table information
    -- ================================================================================

    -- Get column information (using DESCRIBE TABLE)
    DECLARE
        describe_sql VARCHAR;
        rs RESULTSET;
    BEGIN
        describe_sql := 'DESCRIBE TABLE ' || :SOURCE_DATABASE || '.' || :SOURCE_SCHEMA || '.' || :SOURCE_TABLE;
        rs := (EXECUTE IMMEDIATE :describe_sql);

        -- Get information from results
        -- $1: Column name, $2: Data type, $10: Comment
        SELECT LISTAGG(
            $1 || ':' || $2 || CASE WHEN $10 IS NOT NULL AND $10 != '' THEN '(' || $10 || ')' ELSE '' END,
            ', '
        ) INTO column_info
        FROM TABLE(RESULT_SCAN(LAST_QUERY_ID()));

    EXCEPTION
        WHEN OTHER THEN
            RETURN 'Error: Could not retrieve table information - ' || :SOURCE_DATABASE || '.' || :SOURCE_SCHEMA || '.' || :SOURCE_TABLE || '. Error: ' || SQLERRM;
    END;

    -- Error check
    IF (column_info IS NULL OR LENGTH(:column_info) = 0) THEN
        RETURN 'Error: Column information is empty - ' || :SOURCE_DATABASE || '.' || :SOURCE_SCHEMA || '.' || :SOURCE_TABLE;
    END IF;

    -- Get table comment
    SELECT COMMENT INTO table_comment
    FROM INFORMATION_SCHEMA.TABLES
    WHERE TABLE_CATALOG = :SOURCE_DATABASE
      AND TABLE_SCHEMA = :SOURCE_SCHEMA
      AND TABLE_NAME = :SOURCE_TABLE;

    -- Get sample data (first 5 rows)
    DECLARE
        sample_sql VARCHAR;
        sample_rs RESULTSET;
    BEGIN
        sample_sql := 'SELECT * FROM ' || :SOURCE_DATABASE || '.' || :SOURCE_SCHEMA || '.' || :SOURCE_TABLE || ' LIMIT 5';
        sample_rs := (EXECUTE IMMEDIATE :sample_sql);

        -- Get sample data in JSON format
        SELECT TO_VARCHAR(ARRAY_AGG(OBJECT_CONSTRUCT(*))) INTO sample_data_json
        FROM TABLE(RESULT_SCAN(LAST_QUERY_ID()));

    EXCEPTION
        WHEN OTHER THEN
            sample_data_json := 'Sample data unavailable';
    END;

    -- ================================================================================
    -- STEP 2: Generate complete Semantic View definition with AI
    -- ================================================================================

    SELECT SNOWFLAKE.CORTEX.COMPLETE(
        :LLM_MODEL,
        CONCAT(
            '[IMPORTANT] Generate a Snowflake semantic view using the information below.',
            '\n\n★ DO NOT use any column names that do not exist ★',
            '\n\n[TABLE INFORMATION]',
            '\nTable: ', :SOURCE_DATABASE, '.', :SOURCE_SCHEMA, '.', :SOURCE_TABLE,
            '\nAlias: ', :SOURCE_TABLE,
            '\nTable Comment: ', COALESCE(:table_comment, 'None'),
            '\n\n[EXISTING COLUMNS (Use ONLY these)]',
            '\n', :column_info,
            '\n\n[SAMPLE DATA (For understanding data usage)]',
            '\n', SUBSTRING(:sample_data_json, 1, 1000),
            '\n\n[SQL TO GENERATE]',
            '\nCREATE OR REPLACE SEMANTIC VIEW ', :TARGET_DATABASE, '.', :TARGET_SCHEMA, '.', :TARGET_VIEW_NAME,
            '\n  TABLES (',
            '\n    ', :SOURCE_TABLE, ' AS ', :SOURCE_DATABASE, '.', :SOURCE_SCHEMA, '.', :SOURCE_TABLE,
            '\n      WITH SYNONYMS (''alias1'', ''alias2'', ''alias3'', ''alias4'')',
            '\n      COMMENT = ''Detailed table description''',
            '\n  )',
            '\n  FACTS (',
            '\n    ', :SOURCE_TABLE, '.fact_name AS existing_column_name',
            '\n      WITH SYNONYMS (''alias1'', ''alias2'')',
            '\n      COMMENT = ''Detailed column description''',
            '\n  )',
            '\n  DIMENSIONS (',
            '\n    ', :SOURCE_TABLE, '.dim_name AS existing_column_name',
            '\n      WITH SYNONYMS (''alias1'', ''alias2'')',
            '\n      COMMENT = ''Detailed column description''',
            '\n  )',
            '\n  METRICS (',
            '\n    ', :SOURCE_TABLE, '.metric_name AS SUM(existing_column_name)',
            '\n      WITH SYNONYMS (''alias1'', ''alias2'')',
            '\n      COMMENT = ''Detailed column description''',
            '\n  )',
            '\n  COMMENT = ''Detailed semantic view description'';',
            '\n\n[ABSOLUTE RULES]',
            '\n★★★ MOST IMPORTANT ★★★ Use ONLY column names from the above list',
            '\n\n0. Omit Primary Key:',
            '\n   - Do not write PRIMARY KEY clause',
            '\n   - Primary key constraints do not function in Snowflake and are optional',
            '\n\n1. Column Name Usage:',
            '\n   - Column names used on the right side of AS must also exist in the list',
            '\n   - Example OK: YEAR(TRANSACTION_DATE) ← only if TRANSACTION_DATE exists',
            '\n   - Example NG: YEAR(ORDER_DATE) ← if ORDER_DATE does not exist',
            '\n\n2. FACTS (Numeric Data):',
            '\n   - Quantity, amount, price, score, rate - numeric type columns',
            '\n   - Include both simple column references and calculated formulas',
            '\n   - Example (simple): QUANTITY, PRICE, AMOUNT',
            '\n   - Example (calculated): revenue AS QUANTITY * UNIT_PRICE, discount_amount AS TOTAL_PRICE * 0.1',
            '\n\n3. DIMENSIONS (Attribute Data):',
            '\n   - IDs, names, dates, categories, statuses',
            '\n   - Do not overlap with FACTS',
            '\n\n4. No Duplicate Names: All table.name combinations on the left must be unique',
            '\n\n5. Date Derivative Naming: original_column_name_year, original_column_name_month',
            '\n\n6. Rich Synonyms (Critical for Cortex Analyst to understand user requests):',
            '\n   - Tables: 4-5 business-relevant aliases',
            '\n   - Each DIMENSION, FACT, METRIC: 2-3 natural aliases',
            '\n   - Infer appropriate synonyms from sample data actual usage',
            '\n   - Example: sales amount → "total sales", "sales total", "revenue"',
            '\n   - Example: product ID → "product code", "item number", "SKU"',
            '\n\n7. Rich COMMENTS:',
            '\n   - Generate specific descriptions from sample data',
            '\n   - Include business meaning',
            '\n   - Specify units and ranges',
            '\n\n8. Utilize Sample Data:',
            '\n   - Understand actual usage from sample data content',
            '\n   - Generate more concrete, practical synonyms',
            '\n   - Reflect data characteristics (range, units, etc.) in COMMENTS',
            '\n\n9. Generate Abundant FACTS and DIMENSIONS:',
            '\n   - FACTS: Around 5-10 (simple columns + calculated formulas)',
            '\n   - DIMENSIONS: Around 5-15 (original columns + date derivatives)',
            '\n   - METRICS: Around 4-8 (various aggregation patterns)',
            '\n\n10. Output: SQL syntax only (no ```, no explanatory text)',
            '\n\nOutput only the CREATE SEMANTIC VIEW statement:'
        )
    ) INTO ai_response;

    -- Debug: Verify AI response length
    IF (:ai_response IS NULL OR LENGTH(:ai_response) = 0) THEN
        RETURN 'Error: AI_COMPLETE returned an empty response. Column info: ' || SUBSTRING(:column_info, 1, 500);
    END IF;

    -- Remove unnecessary characters
    create_view_sql := :ai_response;
    create_view_sql := REPLACE(:create_view_sql, '```sql', '');
    create_view_sql := REPLACE(:create_view_sql, '```', '');
    create_view_sql := REPLACE(:create_view_sql, '"', '''');
    create_view_sql := REPLACE(:create_view_sql, 'Revised:', '');
    create_view_sql := REPLACE(:create_view_sql, 'Modifications:', '');
    create_view_sql := REPLACE(:create_view_sql, '**', '');
    create_view_sql := TRIM(:create_view_sql);

    -- Final verification: Check SQL statement is not empty
    IF (:create_view_sql IS NULL OR LENGTH(:create_view_sql) < 50) THEN
        RETURN 'Error: Generated SQL is empty or too short. AI response: ' || SUBSTRING(:ai_response, 1, 1000);
    END IF;

    -- ================================================================================
    -- STEP 4: Create semantic view
    -- ================================================================================

    BEGIN
        EXECUTE IMMEDIATE :create_view_sql;
        RETURN 'Semantic view ' || :TARGET_DATABASE || '.' || :TARGET_SCHEMA || '.' || :TARGET_VIEW_NAME || ' created successfully. SQL: ' || :create_view_sql;
    EXCEPTION
        WHEN OTHER THEN
            RETURN 'Error: ' || SQLERRM || ' -- Generated SQL: ' || SUBSTRING(:create_view_sql, 1, 2000);
    END;

END;
$$;

-- ================================================================================
-- Usage Example
-- ================================================================================

/*
-- Basic usage
CALL GENERATE_SEMANTIC_VIEW(
    '<source_database>',
    '<source_schema>',
    '<source_table>',
    '<target_database>',
    '<target_schema>',
    '<semantic_view_name>',
    '<LLM_model_name>'
);

-- Verify created semantic view
DESCRIBE SEMANTIC VIEW <target_database>.<target_schema>.<semantic_view_name>;
*/

Note: You can copy and paste this stored procedure directly into your Snowflake environment for immediate use.

How to Use

Prerequisites

To use this stored procedure, you'll need:

A Snowflake account
An environment where Cortex LLM is available (cross-region inference makes this available in most regions)
Permissions to create semantic views

Basic Usage Example

Here's how to generate a semantic view from the SALES_DATABASE.PUBLIC.ORDERS table:

-- Call the stored procedure
CALL GENERATE_SEMANTIC_VIEW(
    'SALES_DATABASE',           -- Source database
    'PUBLIC',                   -- Source schema
    'ORDERS',                   -- Source table
    'ANALYTICS_DATABASE',       -- Target database
    'SEMANTIC',                 -- Target schema
    'ORDERS_SEMANTIC_VIEW',     -- Semantic view name
    'claude-sonnet-4-5'         -- LLM model (optional)
);

-- Verify the created semantic view
DESCRIBE SEMANTIC VIEW ANALYTICS_DATABASE.SEMANTIC.ORDERS_SEMANTIC_VIEW;

Example Generated Semantic View

For example, given this table structure:

-- Sample table
CREATE TABLE ORDERS (
    ORDER_ID NUMBER,
    CUSTOMER_ID NUMBER,
    ORDER_DATE DATE,
    PRODUCT_NAME VARCHAR,
    QUANTITY NUMBER,
    UNIT_PRICE NUMBER,
    TOTAL_AMOUNT NUMBER
);

The stored procedure auto-generates a semantic view like this:

CREATE OR REPLACE SEMANTIC VIEW ANALYTICS_DATABASE.SEMANTIC.ORDERS_SEMANTIC_VIEW
  TABLES (
    ORDERS AS SALES_DATABASE.PUBLIC.ORDERS
      WITH SYNONYMS ('Order Table', 'Sales Data', 'Purchase History', 'Transactions')
      COMMENT = 'Table managing customer order information'
  )
  FACTS (
    ORDERS.quantity AS QUANTITY
      WITH SYNONYMS ('Qty', 'Amount Ordered', 'Number of Items')
      COMMENT = 'Quantity of products ordered',
    ORDERS.unit_price AS UNIT_PRICE
      WITH SYNONYMS ('Price', 'Item Price', 'Product Price')
      COMMENT = 'Price per product unit',
    ORDERS.total_amount AS TOTAL_AMOUNT
      WITH SYNONYMS ('Total', 'Order Amount', 'Purchase Total')
      COMMENT = 'Total order amount'
  )
  DIMENSIONS (
    ORDERS.order_id AS ORDER_ID
      WITH SYNONYMS ('Order Number', 'Transaction ID', 'Order Ref')
      COMMENT = 'Unique identifier for the order',
    ORDERS.customer_id AS CUSTOMER_ID
      WITH SYNONYMS ('Client ID', 'Customer Number', 'Account ID')
      COMMENT = 'Customer identifier',
    ORDERS.order_date AS ORDER_DATE
      WITH SYNONYMS ('Purchase Date', 'Transaction Date', 'Date Ordered')
      COMMENT = 'Date the order was placed',
    ORDERS.product_name AS PRODUCT_NAME
      WITH SYNONYMS ('Product', 'Item Name', 'Item')
      COMMENT = 'Name of the ordered product'
  )
  METRICS (
    ORDERS.total_sales AS SUM(TOTAL_AMOUNT)
      WITH SYNONYMS ('Total Revenue', 'Sales Total', 'Revenue')
      COMMENT = 'Total sales amount for all orders',
    ORDERS.avg_order_amount AS AVG(TOTAL_AMOUNT)
      WITH SYNONYMS ('Average Order Value', 'AOV', 'Avg Purchase')
      COMMENT = 'Average amount per order',
    ORDERS.total_orders AS COUNT(*)
      WITH SYNONYMS ('Order Count', 'Number of Orders', 'Total Transactions')
      COMMENT = 'Total number of orders'
  )
  COMMENT = 'Semantic view for order data analysis';

Real-World Use Cases

Use Case 1: Fast Start

When introducing Cortex Analyst to a new project, use this stored procedure to quickly generate semantic views for key tables. Then customize only the necessary parts according to business requirements and add relationships between tables - several times faster than building from scratch, helping you set up your semantic layer efficiently.

Use Case 2: Data Catalog

Generated semantic views contain rich synonyms and comments, making them excellent table documentation. They serve as reference material for new team members learning the table structure or can be loaded into AI Agents as an AI-oriented data catalog.

Use Case 3: POC (Proof of Concept)

For POCs validating Cortex Analyst's effectiveness, you often don't want to spend much time creating semantic layers. This stored procedure lets you build a demo environment in minutes and immediately experience Cortex Analyst's value.

Customization Tips

While auto-generated semantic views may work as-is, customizing these points will achieve even more accurate query generation:

Note: You can customize semantic views not just through SQL commands (ALTER SEMANTIC VIEW), but also via GUI in Snowsight's AI/ML Studio. AI/ML Studio lets you visually confirm the semantic view structure while intuitively adding synonyms, editing comments, and adding new Metrics.

1. Adding/Modifying Synonyms

Add industry-specific terms and internal company terminology to help Cortex Analyst better understand users' natural language:

-- Example: Add industry terms
ALTER SEMANTIC VIEW ORDERS_SEMANTIC_VIEW 
MODIFY DIMENSION ORDERS.product_name 
  ADD SYNONYMS ('SKU', 'Item Code', 'Barcode');

2. Adding Complex Calculated Metrics

Add advanced calculation formulas according to business logic:

-- Example: Add profit margin
ALTER SEMANTIC VIEW ORDERS_SEMANTIC_VIEW 
ADD METRIC ORDERS.profit_margin AS (SUM(TOTAL_AMOUNT) - SUM(COST)) / SUM(TOTAL_AMOUNT)
  WITH SYNONYMS ('Margin', 'Profit Rate', 'Return Rate')
  COMMENT = 'Profit ratio relative to sales';

3. Integrating Multiple Tables into a Semantic View

To analyze across multiple tables, integrate individually generated semantic views and define relationships between tables:

-- Example: Create semantic view containing both ORDERS and CUSTOMERS tables
-- First, generate semantic views for each table individually,
-- Then integrate into a new semantic view

CREATE OR REPLACE SEMANTIC VIEW SALES_ANALYSIS_VIEW
  TABLES (
    ORDERS AS SALES_DATABASE.PUBLIC.ORDERS
      WITH SYNONYMS ('Orders', 'Sales Data'),
    CUSTOMERS AS SALES_DATABASE.PUBLIC.CUSTOMERS
      WITH SYNONYMS ('Customers', 'Client Info')
  )
  RELATIONSHIPS (
    ORDERS.CUSTOMER_ID = CUSTOMERS.CUSTOMER_ID
  )
  -- Facts, Dimensions, Metrics omitted
  ;

For detailed customization options, see the official Snowflake documentation - Using SQL commands to create and manage semantic views.

Integration with Cortex Analyst

Generated semantic views are immediately usable with Cortex Analyst.

Verifying in Snowsight

After creating your semantic view, verify it works right away in Snowsight's AI/ML Studio Cortex Analyst playground. For implementation, Snowflake offers various options including calling from Snowflake Intelligence, calling from Cortex Agents, or configuring as a tool in Snowflake MCP Server.

Important Notes

Tool Limitations

This stored procedure has the following constraint:

Single Table Only: This tool generates semantic views from a single table only. To create semantic views combining multiple tables, first generate views for each table individually, then manually add relationships between tables.

Generated Semantic View Quality

As this uses AI auto-generation, please note:

Not Perfect: Always review and customize generated semantic views according to business requirements
Sample Data Dependency: Generated synonyms and descriptions vary based on sample data content
Complex Logic: Advanced business logic requires manual additions and modifications

Conclusion

This AI auto-generation stored procedure is a tool that dramatically accelerates the initial stages of semantic view creation. While semantic layer preparation is essential for Cortex Analyst to deliver "natural language data analysis" - that ideal world - it would be a shame if this necessary work becomes a barrier that delays your start!

Using this stored procedure, you can generate baseline semantic views in seconds, then customize necessary parts from there. As a result, you can deliver analytics environments to business departments in a much shorter timeframe.

Take the first step toward realizing data democratization and empowering business users to extract insights from data themselves - I hope this tool helps you get there!

Promotion

Snowflake What's New Updates on X

I share Snowflake What's New updates on X. Follow for the latest insights:

English Version

Snowflake What's New Bot (English Version)

Japanese Version

Snowflake's What's New Bot (Japanese Version)

Change Log

(20251009) Initial post

Original Japanese Article

https://zenn.dev/tsubasa_tech/articles/ce732d628a9bee

Unlock Advanced Data Analytics in Cursor with Snowflake MCP Server

Tsubasa Kanno — Mon, 01 Sep 2025 11:00:03 +0000

⚠️ Major revision notice (July 2026)

The community MCP Server (Snowflake-Labs/mcp) originally covered in this article has been deprecated and is expected to be removed soon. This article has therefore been fully revised to use the official, fully-managed Snowflake Managed MCP Server. Key changes:

Replaced the community (OSS) setup steps with the Snowflake Managed MCP Server workflow

Changed the Cursor connection to use the Managed MCP Server endpoint URL + PAT (Bearer token)

Reflected the rename of "Snowflake Intelligence" to "Snowflake CoWork"

Updated configuration and feature descriptions to the latest specification

If you previously set up the community version, please consider migrating to the Snowflake Managed MCP Server.

Introduction

The AI agent movement in development keeps gaining momentum. The Model Context Protocol (MCP), a standardized protocol from Anthropic, enables seamless connections between LLMs and various tools and APIs. And Snowflake now offers an official, fully-managed Snowflake Managed MCP Server!

While Cortex Search and Cortex Analyst were previously available as individual features, now that SQL execution and Cortex Agents can also be bundled as tools, you can access Snowflake's analytics environment directly from MCP clients (like Cursor or Claude Desktop). Simply give natural language instructions to your AI agent and complete your data analysis - a welcome update for developers!

In this article, I'll walk you through setting up and using the Snowflake Managed MCP Server with Cursor, explore the analytics possibilities it unlocks, and discuss when to use it versus Snowflake CoWork (formerly Snowflake Intelligence). If you're an engineer looking to analyze Snowflake data more efficiently, this guide is for you!

Note: The community version (Snowflake-Labs/mcp) has been deprecated and is expected to be removed soon. Going forward, the officially supported Snowflake Managed MCP Server is recommended, and this article is based on it.

Note: This article represents my personal views and not those of Snowflake.

What is Snowflake Managed MCP Server?

Snowflake Managed MCP Server is an official, fully-managed server that integrates various Snowflake features into the MCP ecosystem. By connecting with MCP clients (Cursor, Claude Desktop, etc.), you can operate Snowflake's data analytics capabilities through AI agents.

Its key characteristic is that the server is hosted inside your Snowflake account. There's no need to stand up a separate local server - you simply run a CREATE MCP SERVER SQL statement, and Snowflake provisions a managed endpoint. Authentication and access control ride on Snowflake's RBAC / OAuth, making governance easier to enforce.

Key Features

Snowflake Managed MCP Server lets you combine the following tools and expose them as a single server:

Tool Type	Description
Cortex Search (`CORTEX_SEARCH_SERVICE_QUERY`)	Search unstructured data (e.g., for RAG applications)
Cortex Analyst (`CORTEX_ANALYST_MESSAGE`)	Analyze structured data using Semantic Views (Text2SQL)
Cortex Agents (`CORTEX_AGENT_RUN`)	Agentic orchestrator spanning structured and unstructured data
SQL Execution (`SYSTEM_EXECUTE_SQL`)	Execute SQL generated by the AI agent
Custom Tools (`GENERIC`)	Invoke user-defined functions (UDFs) or stored procedures as tools

Note: The Cortex Analyst tool in Snowflake Managed MCP Server works with Semantic Views. Note that YAML-based semantic models are not supported.

Technical Characteristics

Snowflake-hosted: No separate infrastructure required; provided as a remote HTTP endpoint
RBAC-based permissions: Grant privileges separately to the MCP server itself and to each tool (the server-connection privilege and the tool-execution privilege are managed independently)
Flexible authentication: Supports OAuth 2.0 and PAT (Programmatic Access Token)
Fine-grained SQL control: The SQL execution tool can be restricted to read-only via the read_only option

Calling Other Tools and Agents from Cortex Agents via MCP

So far we've looked at the "server that exposes Snowflake features to MCP clients (like Cursor)" side. Conversely, Cortex Agents themselves can act as MCP clients. Through MCP Connectors, a Cortex Agent can connect to external MCP servers and invoke their tools during orchestration.

What's interesting is that a Managed MCP Server can expose a Cortex Agent itself as a tool (CORTEX_AGENT_RUN). Combining these, you can build a setup where one agent calls another agent through MCP (agent-to-agent, or A2A). For example, you could have specialized agents handle different domains and delegate work to one another as needed.

Note: When an agent calls another agent, be careful to avoid loops. Snowflake enforces a maximum recursion depth (10 invocations), but you should still design your configuration to avoid circular invocation paths. MCP Connectors coverage continues to expand, so check the official documentation for the latest.

Choosing Between Snowflake CoWork and Managed MCP Server

If you're familiar with Snowflake, you might wonder: "We already have Snowflake CoWork (formerly Snowflake Intelligence) - how should I choose between them?" Here's my perspective:

When Snowflake CoWork is Better

Aspect	Details
Target Users	Business users, analysts
Environment	Web browser-based GUI
Main Use Cases	Enterprise data analysis app deployment, report creation
Advantages	Easy setup, intuitive GUI operation. All environments managed by Snowflake for enhanced security
Deployment	Easy organization-wide rollout

When Snowflake Managed MCP Server is Better

Aspect	Details
Target Users	Engineers, developers
Environment	Development tools like Cursor, Claude Desktop
Main Use Cases	Checking data during development, ad-hoc analysis, integration from external applications
Advantages	Integrates with development workflow, analyze data alongside code
Deployment	Individual or team-level usage

In essence: Choose CoWork for easy enterprise-wide natural language analysis app deployment, and Managed MCP Server for integrating Snowflake analytics into engineering MCP clients. When in doubt, start with the easier-to-adopt Snowflake CoWork to clarify business expectations, then consider Snowflake Managed MCP Server as needed.

Setting Up with Cursor

Let's create a Snowflake Managed MCP Server and connect to it from Cursor. There are three main steps: (1) create the MCP server on the Snowflake side, (2) issue a PAT and set up access, and (3) configure the connection on the Cursor side. We'll use a PAT (Programmatic Access Token) for authentication.

1. Create the MCP Server on Snowflake

Prepare the Tools to Expose

An MCP server exposes Cortex Search / Cortex Analyst / Cortex Agents and more as "tools." Depending on which tools you want, prepare the following in advance:

To use Cortex Search: Create a Cortex Search Service (for searching unstructured data)
To use Cortex Analyst: Create a Semantic View (for Text2SQL over structured data)
To use Cortex Agents: Create a Cortex Agent
If you only need SQL execution: No preparation required

Create the MCP Server

Once ready, create the MCP server with CREATE MCP SERVER. List the tools you want to expose in YAML under FROM SPECIFICATION. The following example exposes three tools: Cortex Analyst, Cortex Search, and SQL execution.

CREATE OR REPLACE MCP SERVER MY_DB.MY_SCHEMA.MY_MCP_SERVER
  FROM SPECIFICATION $$
tools:
  # Cortex Analyst (Text2SQL using a Semantic View)
  - name: "sales-analyst"
    type: "CORTEX_ANALYST_MESSAGE"
    identifier: "MY_DB.MY_SCHEMA.SALES_SEMANTIC_VIEW"
    description: "Semantic view for analyzing sales data"
    title: "Sales Analysis"

  # Cortex Search (search unstructured data)
  - name: "manual-search"
    type: "CORTEX_SEARCH_SERVICE_QUERY"
    identifier: "MY_DB.MY_SCHEMA.MANUAL_SEARCH_SERVICE"
    description: "Search documents such as operations manuals"
    title: "Document Search"

  # SQL execution (restricted to read-only via read_only)
  - name: "sql_exec_tool"
    type: "SYSTEM_EXECUTE_SQL"
    description: "Execute read-only SQL against Snowflake"
    title: "SQL Execution"
    config:
      read_only: true
      query_timeout: 600
$$;

Each tool's description helps the AI agent decide which tool to use, so write it as specifically as possible. After creation, you can list your servers:

SHOW MCP SERVERS IN SCHEMA MY_DB.MY_SCHEMA;

Note: The identifier for a Cortex Analyst tool must point to a Semantic View (YAML-based semantic models are not supported). Also, a single MCP server can hold up to 50 tools; too many tools can reduce tool-selection accuracy, so consider splitting servers by purpose.

2. Generate a PAT and Set Up Access

Grant Privileges to the Connecting Role

Connections to the MCP server use role-based access control (RBAC). Note that the privilege to connect to the MCP server and the privileges on the objects each tool references must be granted separately. Prepare a least-privilege role and grant the required privileges.

First, grant the USAGE needed to connect to (list and call tools on) the MCP server:

GRANT USAGE ON MCP SERVER MY_DB.MY_SCHEMA.MY_MCP_SERVER TO ROLE MY_MCP_ROLE;

In addition, grant the role the following privileges on the objects each exposed tool references:

Tool	Required Privilege
Cortex Search	`USAGE` on the target Cortex Search Service
Cortex Analyst	`SELECT` on the target Semantic View
Cortex Agents	`USAGE` on the target Cortex Agent
Custom Tools	`USAGE` on the target UDF / stored procedure

Note: Even if a role can access the MCP server, it can't run a tool without privileges on the objects that tool references. Following the least-privilege principle, grant privileges only on the objects for the tools you need.

Generate the PAT

Next, log into Snowsight and generate a PAT:

Click your profile icon in the bottom left and select Settings
Navigate to the Authentication section
Click the Generate New Token button
Set the token name and expiration
For the role, select the connecting role you prepared earlier
Copy the generated token

Important: By default, using a PAT requires the user to be subject to a network policy. Without a network policy, PAT authentication may fail. For detailed PAT requirements, please refer to the official Snowflake documentation.

3. Configure Cursor MCP

Open the MCP settings in Cursor and add a new MCP server, or edit the configuration file (~/.cursor/mcp.json) directly. Because the Managed MCP Server is accessed as a remote HTTP endpoint, you specify the endpoint URL and an authentication header (PAT).

{
  "mcpServers": {
    "snowflake": {
      "url": "https://<orgname>-<account_name>.snowflakecomputing.com/api/v2/databases/<database>/schemas/<schema>/mcp-servers/<mcp_server_name>",
      "headers": {
        "Authorization": "Bearer <the PAT you generated earlier>"
      }
    }
  }
}

The endpoint URL follows the format https://<account_url>/api/v2/databases/{database}/schemas/{schema}/mcp-servers/{mcp_server_name}.

Note: In the hostname part of the URL, if your account identifier contains underscores (_), replace them with hyphens (-) (e.g., ORGNAME-AAA_BBB → ORGNAME-AAA-BBB). Leaving underscores can cause connection failures.

Note: This article uses PAT authentication for simplicity, but OAuth 2.0 is recommended for production. However, the library that Cursor and Claude Desktop use internally does not support Dynamic Client Registration (DCR), so OAuth may require extra considerations. For that reason, PAT (Bearer token) is the practical connection method for Cursor. For OAuth steps, see the official documentation.

4. Verifying Connection

After configuration, confirm the server is enabled in Cursor's MCP settings. When successfully connected, a green indicator lights up on the MCP Server icon, and Snowflake features become available in Cursor's chat interface.

Practical Examples

Let's explore data analysis using Snowflake Managed MCP Server from Cursor!

Example 1: Natural Language Data Exploration

Type this in Cursor's chat:

List all Snowflake databases.

MCP Server automatically generates and executes appropriate SQL, returning results:

SNOWFLAKE Database List

1. SALES
Database managing customer sales data

2. CUSTOMER
Database managing customer information
...

The AI Agent generates and executes appropriate SQL within your Snowflake role's permissions and the range allowed by the SQL execution tool's configuration (such as read_only).

Example 2: Searching Unstructured Data with Cortex Search

When searching for specific information from internal documents:

Summarize the operations manual.

The configured Cortex Search Service is automatically called, returning relevant information:

📚 RetailCorp Operations Manual Summary
🏢 Company Philosophy
Mission: "Delivering exceptional customer experiences through innovation and quality"
Core Values:
Customer-first approach
Operational excellence
Sustainable growth
Employee empowerment
...

Example 3: Complex Analysis Queries

Analyze monthly sales trends for H2 2024 and identify variation factors.

Cortex Analyst interprets the Semantic View, generates an appropriate SQL query, and Cursor's AI Agent returns the result as a report:

📊 H2 2024 Sales Analysis Report

📈 Monthly Sales Trends
Month       Sales ($)   MoM Change  Features
July        152,435     -       H2 Start
August      248,291     +62.8%      Peak month
September   201,762     -18.8%      High level maintained
October     149,698     -25.8%      Sales decline
November    145,386     -2.9%       Lowest month
December    292,847     +101.3%     Holiday surge
Total       1,190,419   -       H2 Total

🔍 Key Variation Factors
1. Seasonal Factors
August: Back-to-school season peak
High-volume sales of electronics and premium products
Product lineup generating $75K per SKU

December: Holiday shopping season
Sales more than doubled from previous month
December 16 ($107,145) and 24 ($106,221) were exceptional days
Black Friday and Cyber Monday impact
...

Best Practices

Permission Configuration Guidelines

With Snowflake Managed MCP Server, you can operate securely by combining RBAC with per-tool settings.

Restrict to read-only: Set the SQL execution tool to read_only: true to limit it to reference queries
Use least-privilege roles: Bind the PAT to a role that only has privileges on the objects for the tools you need
Split servers by purpose: Use separate MCP servers for development and production, varying the exposed tools and privileges

Conclusion

Snowflake Managed MCP Server is a tool that meaningfully improves the developer experience. It delivers particular value through:

Development Flow Integration: Analyze data without leaving Cursor
Natural Language Operations: Execute complex analysis tasks with natural language instructions to AI Agents without writing SQL
Secure Execution Environment: Safe usage through granular permission controls

Having tried it myself, I find it incredibly convenient to complete everything within Cursor without switching tools when wondering "What was that table structure?" or "I need to check sales trends for this period."

While Snowflake CoWork is a powerful tool for promoting organization-wide data utilization, the Managed MCP Server integrated with daily development tools offers different value for engineers and data scientists. By choosing the right tool for each use case, we can achieve more efficient data utilization.

Give Snowflake Managed MCP Server a try today!

Promotion

Snowflake What's New Updates on X

I share Snowflake What's New updates on X. Follow for the latest insights:

English Version

Snowflake What's New Bot (English Version)

Japanese Version

Snowflake's What's New Bot (Japanese Version)

Change Log

(20250901) Initial post
(20260702) Major revision: replaced the deprecated community MCP Server (Snowflake-Labs/mcp) with the Snowflake Managed MCP Server, reflected the Snowflake Intelligence -> Snowflake CoWork rename, and added coverage of the Cortex Agents MCP client capability (A2A).

Original Japanese Article

https://zenn.dev/tsubasa_tech/articles/70ab5fb2b5ed99

Snowflake AI_TRANSCRIBE - Transform Audio to Insights with SQL in Seconds

Tsubasa Kanno — Sun, 10 Aug 2025 10:37:14 +0000

Introduction

Snowflake's unstructured data analytics has taken another leap forward! After expanding Cortex AI capabilities for images and documents throughout 2025, we can now work with audio data directly from SQL!

The new AI_TRANSCRIBE function, released in Public Preview as part of Snowflake Cortex AISQL, transforms how we handle audio data. Customer support calls, meeting recordings, interviews - all these previously hard-to-leverage audio assets can now be transcribed with a single SQL query and combined with other AISQL functions for advanced analytics.

With support for images, documents, and now audio - the three major unstructured data formats - Snowflake has dramatically expanded the possibilities for business data analytics. Let's explore how AI_TRANSCRIBE works, its practical applications, and I'll even share a voice-enabled AI chatbot built with Streamlit in Snowflake!

Note: AI_TRANSCRIBE is currently in Public Preview, so features may undergo significant updates in the future.

Note: This article represents my personal views and not those of Snowflake.

What is AI_TRANSCRIBE?

AI_TRANSCRIBE is Snowflake Cortex AISQL's audio-to-text transcription function. Previously, leveraging audio data required external services or third-party packages, but AI_TRANSCRIBE enables direct audio transcription within SQL queries.

Key Features

SQL Native: Call directly from SQL like other AISQL functions for simple integration
Multi-language Support: Supports numerous languages including English, Spanish, French, German, Chinese, and many more
Speaker Identification: Distinguishes and labels multiple speakers
Timestamp Generation: Provides timestamps at word or speaker level
Secure Processing: All data processing occurs within Snowflake's secure environment

Part of the Cortex AISQL Family

AI_TRANSCRIBE becomes even more powerful when combined with existing Cortex AISQL functions:

AI_SENTIMENT: Analyze sentiment in transcribed audio
AI_CLASSIFY: Automatically categorize audio content
AI_COMPLETE: Summarize or answer questions about audio content
AI_AGG: Extract insights from grouped audio data
AI_EMBED: Vectorize audio transcripts for similarity search

Basic Usage

The basic syntax for AI_TRANSCRIBE is straightforward:

AI_TRANSCRIBE( <audio_file> [ , <options> ] )

Parameters

audio_file: FILE type object representing the audio file. Use TO_FILE function to create a reference to staged files
options: Optional OBJECT type with the following fields:
- timestamp_granularity: Specifies timestamp granularity
- "word": Timestamps for each word
- "speaker": Timestamps and labels for each speaker

Example 1: Simple Text Transcription

The simplest use case is converting audio to text:

-- Convert audio file to text
SELECT AI_TRANSCRIBE(
    TO_FILE('@audio_stage', 'customer_call_001.wav')
);

{
  "audio_duration": 19.08,
  "text": "Hi, I'd like to inquire about the product I purchased last week. The packaging was damaged when it arrived, and I'd like to request an exchange if possible. Could you help me with this? Thank you."
}

Processing time for this 19-second audio file was approximately 2 seconds - impressively fast for analytics scenarios!

Example 2: Word-Level Timestamps

For detailed analysis, add word-level timestamps:

-- Transcribe with word-level timestamps
SELECT AI_TRANSCRIBE(
    TO_FILE('@audio_stage', 'meeting_recording.wav'),
    {'timestamp_granularity': 'word'}
);

{
  "audio_duration": 19.08,
  "segments": [
    {
      "end": 1.254,
      "start": 0.993,
      "text": "Hi"
    },
    {
      "end": 1.434,
      "start": 1.254,
      "text": "I'd"
    },
    {
      "end": 1.514,
      "start": 1.434,
      "text": "like"
    }
    // ... more segments
  ],
  "text": "Hi I'd like to inquire about the product..."
}

Example 3: Speaker Identification

For meetings or interviews with multiple speakers, use speaker identification:

-- Transcribe with speaker identification
SELECT AI_TRANSCRIBE(
    TO_FILE('@audio_stage', 'interview_2025.mp3'),
    {'timestamp_granularity': 'speaker'}
);

{
  "audio_duration": 16.2,
  "segments": [
    {
      "end": 8.461,
      "speaker_label": "SPEAKER_00",
      "start": 0.511,
      "text": "Good morning, thank you for joining us today. My name is Sarah."
    },
    {
      "end": 15.153,
      "speaker_label": "SPEAKER_01",
      "start": 9.048,
      "text": "Thank you for having me. I'm John, pleased to be here."
    }
  ],
  "text": "Good morning, thank you for joining us today. My name is Sarah. Thank you for having me. I'm John, pleased to be here."
}

Supported Languages and Formats

Supported Languages

AI_TRANSCRIBE supports an extensive list of languages:

English, Spanish, French, German
Mandarin Chinese, Cantonese
Japanese, Korean
Arabic, Bulgarian, Catalan
Czech, Dutch, Greek
Hungarian, Indonesian, Italian
Latvian, Polish, Portuguese
Romanian, Russian, Serbian
Slovenian, Swedish, Thai
Turkish, Ukrainian

Supported Audio Formats

Major audio formats are supported:

MP3: Most common audio format
WAV: Uncompressed high-quality audio
FLAC: Lossless compressed audio
Ogg: Open-source format
WebM: Web standard format

Limitations and Considerations

Technical Limitations

Limitation	Details
Maximum File Size	700MB
Maximum Duration (without timestamps)	120 minutes
Maximum Duration (with timestamps)	60 minutes
Concurrent Processing	Depends on account compute resources

Usage Considerations

Audio Quality Impact: Background noise or poor audio quality may reduce transcription accuracy
Technical Terminology: Industry-specific terms or proper nouns may not be accurately transcribed
Language-Specific Behavior: Some languages may have unique behaviors with word-level timestamps
Real-time Processing: Currently supports batch processing only, not real-time streaming

Regional Availability

AI_TRANSCRIBE is natively available in:

AWS US West 2 (Oregon)
AWS US East 1 (N. Virginia)
AWS EU Central 1 (Frankfurt)
Azure East US 2 (Virginia)

For other regions: Use cross-region inference to access AI_TRANSCRIBE functionality with potentially slight latency.

Business Use Cases

AI_TRANSCRIBE excels in various business scenarios:

1. Customer Service Quality Enhancement

Transform call center recordings into actionable insights:

Sentiment Analysis: Use AI_SENTIMENT to analyze professionalism, problem resolution, and wait time perspectives
Call Classification: Automatically categorize calls as complaints, inquiries, or praise with AI_CLASSIFY
Speaker Separation: Analyze operator and customer speech separately for detailed insights
Real-time Dashboards: Visualize analysis results for immediate service quality improvements

2. Meeting Automation and Action Item Extraction

Transform meeting recordings into productivity tools:

Automatic Meeting Minutes: Instantly obtain full text from lengthy meetings
Summary Generation: Use AI_COMPLETE to create concise meeting summaries
Action Item Extraction: Automatically identify decisions and to-dos for efficient follow-up
Participant Analysis: Track who said what using speaker identification

3. Legal and Compliance Automation

Strengthen risk management with transcribed legal conversations:

Complete Documentation: Preserve all contract negotiations and legal discussions as text
Compliance Risk Detection: Classify conversation content by risk level using AI_CLASSIFY
Evidence Preservation: Accurately record who said what and when with speaker identification and timestamps
Automated Audit Reports: Extract key points and generate audit-ready documentation

4. Education and Training Enhancement

Maximize learning effectiveness with transcribed educational content:

Lecture Archives: Save course content as searchable text
Subtitle Creation: Add captions to video materials using word-level timestamps
Training Feedback Analysis: Identify improvement areas in training methodologies
Multilingual Support: Transcribe foreign language courses for easier review

5. Healthcare Documentation (with proper privacy controls)

Streamline medical documentation workflows:

Automated Clinical Notes: Generate structured medical records from doctor-patient conversations
EHR Integration: Extract relevant information for electronic health records
Multilingual Patient Care: Support international patients with transcription and translation
Quality Assurance: Analyze consultation content for healthcare improvement

Building a Voice-Enabled AI Chatbot with Streamlit in Snowflake

Let's build a simple voice-enabled AI chatbot using AI_TRANSCRIBE in Streamlit in Snowflake. Users can ask questions via voice, which gets transcribed and answered by AI (including the newly added OpenAI GPT-5!).

Application Overview

This application provides:

Voice Recording: Record audio directly from browser and save to stage
Audio Transcription: Convert to text using AI_TRANSCRIBE
AI Response Generation: Generate answers using AI_COMPLETE

Prerequisites

Environment Requirements

Python Version: 3.11 or higher
Additional Packages: None required (works with standard packages only)
Streamlit in Snowflake: Environment to create and run applications

Regional Verification

Ensure your region supports AI_TRANSCRIBE and AI_COMPLETE functions, or enable cross-region inference.

Implementation Steps

1. Create a New Streamlit in Snowflake App

Navigate to 'Streamlit' in Snowsight's left pane and click '+ Streamlit' to create a new app.

2. Paste the Sample Code

Copy and paste the sample code below directly into the app editor. No modifications needed - stage names are automatically configured.

3. Run the Application

Click the "Run" button to launch the app. The stage will be created automatically on first run.

4. Use the Application

Voice Input: Click the microphone button to speak
Model Selection: Choose your preferred AI model from the sidebar
Text Input: Regular chat input is also available

Sample Code

import streamlit as st
import io
import uuid
import json
from datetime import datetime
from snowflake.snowpark.context import get_active_session
from snowflake.snowpark.functions import ai_complete, to_file

# Get Snowflake session
session = get_active_session()

# Constants
STAGE_NAME = "AUDIO_TRANSCRIBE_STAGE"

# Page configuration
st.set_page_config(layout="wide")
st.title("AI Voice Chatbot")

# Sidebar: Model selection
st.sidebar.title("⚙️ Settings")

# Model options
model_options = [
    "━━━ 🟢 OpenAI ━━━",
    "openai-gpt-oss-120b",
    "openai-gpt-oss-20b",
    "openai-gpt-5",
    "openai-gpt-5-mini",
    "openai-gpt-5-nano",
    "openai-gpt-5-chat",
    "openai-gpt-4.1",
    "openai-o4-mini",
    "━━━ 🔵 Claude ━━━",
    "claude-4-opus",
    "claude-4-sonnet",
    "claude-3-7-sonnet",
    "claude-3-5-sonnet",
    "━━━ 🦙 Llama ━━━",
    "llama4-maverick",
    "llama4-scout",
    "llama3.3-70b",
    "llama3.2-3b",
    "llama3.2-1b",
    "llama3.1-405b",
    "llama3.1-70b",
    "llama3.1-8b",
    "llama3-70b",
    "llama3-8b",
    "━━━ 🟣 Mistral ━━━",
    "mistral-large2",
    "mistral-large",
    "mixtral-8x7b",
    "mistral-7b",
    "━━━ ❄️ Snowflake ━━━",
    "snowflake-arctic",
    "snowflake-llama-3.3-70b",
    "snowflake-llama-3.1-405b",
    "━━━ 🔴 Others ━━━",
    "deepseek-r1",
    "reka-core",
    "reka-flash",
    "jamba-1.5-large",
    "jamba-1.5-mini",
    "jamba-instruct",
    "gemma-7b"
]

# Default model setting
default_model = "llama4-maverick"
default_index = model_options.index(default_model) if default_model in model_options else 1

llm_model = st.sidebar.radio(
    "Select AI Model",
    options=model_options,
    index=default_index,
    format_func=lambda x: x if "━━━" in x else f"  • {x}"
)

# Use next model if separator is selected
if "━━━" in llm_model:
    llm_model = "llama4-maverick"

# Stage setup
@st.cache_resource
def setup_stage():
    """Setup stage for audio file storage"""
    try:
        session.sql(f"DESC STAGE {STAGE_NAME}").collect()
    except:
        session.sql(f"""
            CREATE STAGE IF NOT EXISTS {STAGE_NAME}
            ENCRYPTION = (TYPE = 'SNOWFLAKE_SSE')
            DIRECTORY = (ENABLE = TRUE)
        """).collect()

setup_stage()

# Initialize session state
if 'messages' not in st.session_state:
    st.session_state.messages = []
    st.session_state.chat_history = ""

def extract_text_from_transcript(transcript_result):
    """Extract text from AI_TRANSCRIBE result"""
    if isinstance(transcript_result, str) and transcript_result.startswith('{'):
        try:
            return json.loads(transcript_result).get('text', '')
        except:
            return transcript_result
    return transcript_result

def clean_ai_response(response):
    """Clean up AI response"""
    if isinstance(response, str):
        response = response.strip('"')
        response = response.replace('\\n', '\n')
    return response

def generate_ai_response(prompt, model):
    """Generate AI response"""
    df = session.range(1).select(
        ai_complete(model=model, prompt=prompt).alias("response")
    )
    return clean_ai_response(df.collect()[0]['RESPONSE'])

# Display chat history
for message in st.session_state.messages:
    with st.chat_message(message["role"]):
        st.markdown(message["content"])

# Voice input section
st.subheader("Voice Input")
audio_value = st.audio_input("Click the microphone button to speak")

if st.button("📤 Send Voice", disabled=(audio_value is None), use_container_width=True):
    if audio_value:
        try:
            # Upload audio file
            with st.spinner("🎤 Uploading audio..."):
                audio_filename = f"audio_{datetime.now().strftime('%Y%m%d_%H%M%S')}_{uuid.uuid4().hex[:8]}.wav"
                audio_stream = io.BytesIO(audio_value.getvalue())
                session.file.put_stream(
                    audio_stream,
                    f"@{STAGE_NAME}/{audio_filename}",
                    auto_compress=False,
                    overwrite=True
                )

            # Transcribe
            with st.spinner("📝 Transcribing audio..."):
                query = f"""
                    SELECT AI_TRANSCRIBE(
                        TO_FILE('@{STAGE_NAME}/{audio_filename}')
                    ) as transcript
                """
                result = session.sql(query).collect()

            if result and len(result) > 0:
                transcribed_text = extract_text_from_transcript(result[0]['TRANSCRIPT'])

                if transcribed_text:
                    # Add user message
                    st.session_state.messages.append({"role": "user", "content": transcribed_text})
                    st.session_state.chat_history += f"User: {transcribed_text}\n"

                    # Generate AI response
                    with st.spinner("🤖 AI is generating response..."):
                        full_prompt = st.session_state.chat_history + "AI: "
                        response = generate_ai_response(full_prompt, llm_model)

                    st.session_state.messages.append({"role": "assistant", "content": response})
                    st.session_state.chat_history += f"AI: {response}\n"

                    st.rerun()
                else:
                    st.warning("Transcription failed. Please try again.")
        except Exception as e:
            st.error(f"Error occurred: {str(e)}")

# Text input
if prompt := st.chat_input("Enter your message..."):
    # Add and display user message
    st.session_state.messages.append({"role": "user", "content": prompt})
    st.session_state.chat_history += f"User: {prompt}\n"
    with st.chat_message("user"):
        st.markdown(prompt)

    # Generate and display AI response
    try:
        with st.spinner("🤖 AI is generating response..."):
            full_prompt = st.session_state.chat_history + "AI: "
            response = generate_ai_response(full_prompt, llm_model)

        st.session_state.messages.append({"role": "assistant", "content": response})
        st.session_state.chat_history += f"AI: {response}\n"
        with st.chat_message("assistant"):
            st.markdown(response)
    except Exception as e:
        st.error(f"Error occurred: {str(e)}")

# Clear chat history
if st.button("🗑️ Clear Chat History"):
    st.session_state.messages = []
    st.session_state.chat_history = ""
    st.rerun()

Application Screenshots

Implementation Highlights

Simple Implementation: No additional packages required, works with standard libraries only
Audio Management: Store audio data in stages and process with AI_TRANSCRIBE
Multimodal Support: Supports both voice and text input
Rich Model Selection: Choose from latest models including OpenAI GPT-5

Cost Considerations

AI_TRANSCRIBE pricing follows the same token-based model as other AISQL functions:

Token Consumption and Pricing

50 tokens per second of audio: Consistent across languages and timestamp granularities
1 hour of audio = 180,000 tokens
Estimated cost: At 1.3 credits per million tokens and assuming $3 per credit, 1 hour of audio processing costs approximately $0.117

For example, a 60-second audio file:

60 seconds × 50 tokens = 3,000 tokens

Note: Audio files under 1 minute are billed as 1 minute (3,000 tokens) minimum. For processing many short audio files, consider batching them together for cost optimization.

For latest pricing information, refer to the Snowflake Service Consumption Table.

Summary

AI_TRANSCRIBE represents a breakthrough function that opens the door to audio data analytics. Combined with Snowflake's enhanced support for images and documents in 2025, the addition of audio - the third major unstructured data format - truly positions Snowflake as a comprehensive multimodal data platform.

Key Benefits

Unified Data Processing: Process all data types including audio within Snowflake
AISQL Function Integration: Combine with sentiment analysis, classification, summarization, and vectorization
Secure Environment: No external data movement required, maintaining governance
Development Efficiency: Build audio analytics pipelines with just SQL, no third-party packages needed

From customer service and meeting transcription to healthcare documentation and legal compliance, AI_TRANSCRIBE unlocks valuable insights from previously untapped audio data. Start exploring how this function can transform your business analytics today!

Have you tried audio analytics in your data workflows? What use cases are you most excited about? Share your experiences in the comments below!

Promotion

Snowflake What's New Updates on X

I share Snowflake What's New updates on X. Follow for the latest insights:

English Version

Snowflake What's New Bot (English Version)

Japanese Version

Snowflake's What's New Bot (Japanese Version)

Change Log

(20250810) Initial post

Original Japanese Article

https://zenn.dev/tsubasa_tech/articles/65e96e2bd257ec

Snowflake AI_SENTIMENT - Industry-Leading Sentiment Analysis with 0.92 Accuracy and Multi-Aspect Support

Tsubasa Kanno — Sun, 03 Aug 2025 09:48:49 +0000

Introduction

Snowflake has released the new AI_SENTIMENT function as part of Cortex AISQL, becoming GA on July 25, 2025! This represents a significant accuracy improvement over the previous ENTITY_SENTIMENT function, enabling state-of-the-art sentiment analysis directly from SQL within Snowflake.

AI_SENTIMENT goes beyond simple "positive/negative" classifications to support aspect-based sentiment analysis. For instance, with restaurant reviews, you can analyze sentiment for specific aspects like "food quality," "pricing," and "service" separately, providing much deeper insights into customer feedback.

In this article, I'll walk through the practical value and implementation approaches for the AI_SENTIMENT function, including real-world testing results that demonstrate its capabilities across different scenarios.

Note: This article represents my personal views and not those of Snowflake.

What is AI_SENTIMENT?

The AI_SENTIMENT function is Snowflake Cortex AISQL's latest sentiment analysis function. Compared to the previous ENTITY_SENTIMENT function, it delivers significantly improved accuracy along with advanced features like mixed sentiment detection and nuanced expression understanding.

Key Features

Industry-leading accuracy: Achieves 0.92 accuracy in aspect-based sentiment analysis
Rich sentiment classification: Five-level detailed analysis including positive, negative, neutral, mixed, and unknown
Multilingual support: Native support for 6 languages including English, French, German, Hindi, Italian, and Portuguese
Aspect-based analysis: Simultaneous analysis of up to 10 different aspects
Advanced context understanding: Accurately interprets implicit expressions and figurative language

Benchmark Performance

AI_SENTIMENT demonstrates superior performance compared to major LLMs:

Model	Aspect-based sentiment accuracy (ABSA-mix)	Aspect-based sentiment accuracy (ABSA-multilingual)	Overall sentiment accuracy	Overall sentiment accuracy (multilingual)
AI_SENTIMENT	0.92	0.81	0.83	0.83
claude-4-sonnet	0.84	0.79	0.75	0.82
mistral-large2	0.83	0.80	0.77	0.78
openai-gpt-4.1	0.83	0.73	0.80	0.78
llama4-scout	0.82	0.79	0.71	0.76
llama3.3-70b	0.82	0.79	0.71	0.76
AWS DetectSentiment	-	-	0.62	0.64

This high accuracy makes AI_SENTIMENT reliable for business-critical sentiment analysis tasks.

Basic Usage

AI_SENTIMENT supports two primary usage patterns:

1. Overall Sentiment Analysis

The simplest approach analyzes overall text sentiment:

SELECT AI_SENTIMENT('Text content');

2. Aspect-Based Sentiment Analysis

Analyze sentiment for specific aspects individually:

SELECT AI_SENTIMENT('Text content', ['Aspect1', 'Aspect2', ...]);

You can specify up to 10 aspects, with each aspect limited to 30 characters.

Testing with Unsupported Languages

While Japanese isn't officially supported, I tested AI_SENTIMENT's behavior with non-supported languages to understand its capabilities.

Test: English Aspect Labels

SELECT AI_SENTIMENT(
    'This restaurant''s omelet rice is quite delicious. The eggs were freshly collected this morning. However, it''s quite expensive compared to nearby stores.',
    ['Price', 'Taste', 'Freshness']
);

Result:

{
  "categories": [
    {
      "name": "overall",
      "sentiment": "mixed"
    },
    {
      "name": "Freshness",
      "sentiment": "positive"
    },
    {
      "name": "Price",
      "sentiment": "negative"
    },
    {
      "name": "Taste",
      "sentiment": "positive"
    }
  ]
}

The results show accurate understanding of the content with proper sentiment classification:

overall: mixed (complex emotions)
Freshness: positive (freshness praised)
Price: negative (price criticism)
Taste: positive (taste praised)

Key Insights

This testing revealed that for unsupported languages:

Content understanding: Text content can be understood with reasonable accuracy
Aspect constraints: Aspects should be specified in supported languages (English, etc.)
Practical workaround: Use English aspect labels even for content in unsupported languages

Supported Languages

AI_SENTIMENT natively supports:

English
French
German
Hindi
Italian
Portuguese

While other languages aren't officially supported, the testing above shows that content understanding may work for additional languages when using supported-language aspect labels.

Business Use Cases

AI_SENTIMENT excels in various business scenarios:

1. Social Media Monitoring

Monitor brand and product mentions across social platforms, tracking sentiment changes in real-time:

-- Social media analysis
SELECT 
    post_date,
    AI_SENTIMENT(content, ['Brand', 'Product', 'Service']) as sentiment_analysis
FROM social_media_posts 
WHERE brand_mention = true
ORDER BY post_date DESC;

2. Product Review Analysis

Analyze e-commerce reviews across multiple dimensions to identify improvement areas:

-- Product review analysis
SELECT 
    product_id,
    AI_SENTIMENT(review_text, ['Quality', 'Price', 'Delivery', 'Customer_Service']) as review_sentiment
FROM product_reviews
WHERE review_date >= '2025-01-01';

3. Customer Support Analysis

Measure customer satisfaction from support tickets and chat logs:

-- Customer support sentiment analysis
SELECT 
    ticket_id,
    support_category,
    AI_SENTIMENT(customer_message, ['Response_Time', 'Solution_Quality', 'Agent_Helpfulness']) as support_sentiment
FROM support_tickets
WHERE status = 'closed';

4. Employee Engagement Analysis

Assess organizational health through employee surveys and feedback:

-- Employee satisfaction analysis
SELECT 
    department,
    AI_SENTIMENT(feedback_text, ['Work_Environment', 'Management', 'Career_Growth', 'Compensation']) as employee_sentiment
FROM employee_feedback
WHERE survey_date >= '2025-01-01';

Sentiment Classification Details

AI_SENTIMENT returns these sentiment classifications:

Classification	Description	Example
positive	Clearly positive sentiment	"Excellent quality product"
negative	Clearly negative sentiment	"Completely disappointing experience"
neutral	Neutral sentiment	"Standard product as expected"
mixed	Both positive and negative elements	"Good quality but overpriced"
unknown	Cannot determine sentiment	When specified aspect doesn't exist

The mixed classification is particularly valuable as it accurately captures complex emotions that contain both positive and negative elements.

Limitations and Considerations

Technical Limitations

Limitation	Details
Context Window	2,048 tokens (approximately 1,600 words)
Maximum Aspects	Up to 10 aspects
Aspect Length	30 characters maximum per aspect
Supported Languages	6 languages (others not officially supported)

Usage Guidelines

Long text handling: Split content exceeding 2,048 tokens
Aspect selection: Choose business-relevant aspects carefully, preferably in supported languages
Result validation: Use AI results as reference; verify critical decisions manually

Cost Information

AI_SENTIMENT has a credit consumption rate of 1.6 credits per 1 million tokens, making it quite cost-effective for sentiment analysis workloads. For detailed credit consumption information, refer to the Snowflake Credit Consumption Table.

Cost Benefits

No data movement: All processing occurs within Snowflake's secure environment
No infrastructure required: No dedicated AI infrastructure setup needed
Automated operations: Easy automation through SQL
Pay-per-use: Only pay for actual usage, avoiding waste

Summary

AI_SENTIMENT represents a breakthrough function that combines sentiment analysis accuracy with business applicability. It delivers exceptional value through:

Key Advantages

Industry-leading accuracy: 0.92 accuracy in aspect-based sentiment analysis
Complex emotion understanding: Accurate analysis of mixed sentiments and implicit expressions
SQL integration: Easy integration into existing data pipelines
Cost efficiency: Significant cost savings compared to external services

Recommendations for Global Usage

Based on testing results, even for unsupported languages, practical usage is possible with these approaches:

Use English aspect labels (Price, Quality, Service, etc.)
Content understanding works across languages (though not officially supported)

I encourage you to explore AI_SENTIMENT for customer voice analysis, brand monitoring, employee satisfaction surveys, and other business scenarios to enable secure and fast data-driven decision making!

Have you tried implementing sentiment analysis in your data workflows? Share your experiences in the comments below!

Promotion

Snowflake What's New Updates on X

I share Snowflake What's New updates on X. Follow for the latest insights:

English Version

Snowflake What's New Bot (English Version)

Japanese Version

Snowflake's What's New Bot (Japanese Version)

Change Log

(20250803) Initial post

Original Japanese Article

https://zenn.dev/tsubasa_tech/articles/972c86d2ac2702

DEV Community: Tsubasa Kanno

I Asked Snowflake to Analyze Data by Voice from My Even G2 Smart Glasses

Introduction

What is Even G2?

How It Works

What is Coding Agent?

Setup

1. Create a Read-Only Role for the G2

2. Create a Role-Restricted PAT

3. Create the Lambda Function

4. Configure the Even App

Talking to It

It Can Search the Web, Too

Going Further: Combining Semantic Views and Cortex Search

Things to Watch Out For

Pair always_allow with a Least-Privilege Role

Add Business Context with Semantic Views

Latency, Token Usage, and Models

You Can Also Connect to Cortex AI Gateway

Taking It into the Business

Conclusion

Promotion

App Runtime Explained on the Official Snowflake Japan YouTube Channel

Snowflake What's New Updates on X

English Version

Japanese Version

Change Log

Original Japanese Article

スマートグラス Even G2 から声で Snowflake にデータ分析を頼んでみた

Give Your Snowflake App Runtime App a Real Backend with Snowflake Postgres

Introduction

A Quick Recap of Snowflake App Runtime

Snowflake App Runtime - Deploy Full-Stack Web Apps Right Next to Your Data from a Single Prompt

What is Snowflake Postgres?

Why App Runtime × Snowflake Postgres?

Use Cases

The Sample App We'll Build

Integration Architecture

Verification: Can App Runtime Really Reach Snowflake Postgres?

Verification 1: Without an EAI, even name resolution fails

Verification 2: With an EAI, the behavior changes

Verification 3: Which IPs to allow — Snowflake's egress IP ranges

Integration Steps

The Fastest Route: Let CoCo Handle It All

Doing It Step by Step

Step 1: Create the Snowflake Postgres Instance

Step 2: Check the Connection Info (Host Name)

Step 3: Store the Credentials in a Snowflake Secret

Step 4: Create the egress Network Rule and EAI

Step 5: Implement the App and app.yml

Step 6: Deploy

Step 7: Allow the Snowflake Postgres Ingress

Step 8: Verify It Works — Confirm Writes Land in Snowflake Postgres

Things to Watch Out For

1. Write the running app's EAI in app.yml

2. Settings added with ALTER APPLICATION SERVICE are reverted on deploy

3. Connecting needs both egress and ingress permissions

4. The source IP is not fixed

5. SSL is required

6. An app deployed to a personal database can't be shared

7. Mind the instance family if mirroring is on your roadmap

Conclusion

Promotion

App Runtime Explained on the Official Snowflake Japan YouTube Channel

Snowflake What's New Updates on X

English Version

Japanese Version

Change Log

Original Japanese Article

Snowflake App Runtime のバックエンドを Snowflake Postgres にして本格的な業務アプリを作る

Snowflake App Runtime - Deploy Full-Stack Web Apps Right Next to Your Data from a Single Prompt

Introduction

What is Snowflake App Runtime?

Architecture at a Glance

Three Ways to Build Apps — How to Choose

A Closer Look at the snowflake-apps Skill (CoCo)

Prerequisite: Setting Up CoCo Desktop

What the snowflake-apps Skill Takes Care Of

Accessing Data with querySnowflake()

The snow app CLI Command Surface

Step 5: Implement the App and `app.yml`

1. Write the running app's EAI in `app.yml`

2. Settings added with `ALTER APPLICATION SERVICE` are reverted on deploy

The `snow app` CLI Command Surface

2. `app.yml` is declarative, so anything you forget to write disappears

3. `snow app setup` needs a warehouse, and watch the deploy target

8. A deployed app doesn't show up in `SHOW SERVICES`