Snowflake Cortex: AI SQL Functions, Cortex Search and Cortex Analyst

1.Cortex AI SQL functions: LLMs as ordinary SQL calls

Snowflake Cortex makes large language models available inside Snowflake. The most direct way to use them is through the Cortex AI Functions. These are managed functions you call from SQL, and they are also available in Python. They take text or images (and, for some functions, documents, audio or video) as input. The models come from providers including OpenAI, Anthropic, Meta, Mistral AI, DeepSeek and xAI.

Governance is often what an exam question turns on. Every LLM Snowflake offers through its AI features is deployed inside the Snowflake service perimeter, so you can run sentiment or classification on customer text without sending it to an outside API. To call the functions, a role needs the USE AI FUNCTIONS account-level privilege and either the CORTEX_USER or the AI_FUNCTIONS_USER database role.

Most of the functions are task-specific, so the work is picking the right one for the job:

Helper functions support the others. TO_FILE references a staged file, AI_COUNT_TOKENS checks an input against model limits, and PROMPT builds prompt objects. AI_AGG and AI_SUMMARIZE_AGG are not limited by the model's context window, so they can cover a whole column.

AI Functions are built for throughput, which makes them a good fit for batch work over large tables. For interactive use where latency matters, Snowflake points you to the REST APIs instead: Complete, Embed and Agents.

Sources1

2.Cortex Search: managed retrieval over text

AI functions work on the input you pass them. Often, though, an LLM first needs to find the right passage among thousands of documents. Cortex Search handles that step. It is a hybrid search engine over your text data, combining vector and keyword search. Snowflake takes care of the embeddings, the infrastructure, quality tuning and keeping the index refreshed.

The main uses are retrieval augmented generation (RAG), where Search supplies an LLM with grounded context from your own data, and enterprise search, where it backs a search bar in an application. It can also act as the retrieval layer for Cortex Agents.

You create a search service as an object, either with one SQL statement or from AI & ML » Cortex Search in Snowsight:

CREATE OR REPLACE CORTEX SEARCH SERVICE transcript_search_service
  ON transcript_text
  ATTRIBUTES region
  WAREHOUSE = cortex_search_wh
  TARGET_LAG = '1 day'
  EMBEDDING_MODEL = 'snowflake-arctic-embed-l-v2.0'
  AS (
    SELECT
        transcript_text,
        region,
        agent_id
    FROM support_transcripts
);

What each clause does:

- ON names the column that gets searched. - ATTRIBUTES makes region available as a filter. - WAREHOUSE materialises the source query, both when the service is created and whenever the base table changes. Snowflake recommends a dedicated warehouse no larger than MEDIUM. - TARGET_LAG sets how far the service may lag behind the base table.

The index is built during CREATE, so the statement can take a long time on large datasets. After that, you grant USAGE on the database, schema and service to other roles, check results with SNOWFLAKE.CORTEX.SEARCH_PREVIEW in SQL, and then query the service from applications through the Python API.

CREATE OR REPLACE CORTEX SEARCH SERVICE transcript_search_service
  ON transcript_text
  ATTRIBUTES region
  WAREHOUSE = cortex_search_wh
   ?  = '1 day'
  EMBEDDING_MODEL = 'snowflake-arctic-embed-l-v2.0'
  AS (
    SELECT
        transcript_text,
        region,
        agent_id
    FROM support_transcripts
);

Sources2

3.Cortex Analyst: natural-language questions over structured data

Cortex Search works with unstructured text. Cortex Analyst works with structured data. It is a fully managed, LLM-powered service that lets business users ask questions in natural language and get answers without writing SQL. Behind the scenes it is an agentic text-to-SQL system. It is available as a REST API, not a SQL function, so you integrate it into Streamlit apps, Slack, Teams or a custom chat interface.

A database schema alone lacks business definitions, which is why Analyst relies on a semantic layer. The recommended form is Semantic Views: schema-level objects that define logical tables, dimensions, facts, metrics and relationships. Semantic Views come with RBAC, can be shared, and support custom instructions. Older semantic model YAML files stored on stages still work, but only for backward compatibility.

On governance, Cortex Analyst does not train on Customer Data, and the queries it generates follow your RBAC policies. To call it, a role needs SNOWFLAKE.CORTEX_USER, which covers all Covered AI features, or SNOWFLAKE.CORTEX_ANALYST_USER, which covers Analyst only. It also needs SELECT on the tables the semantic model uses. CORTEX_USER is granted to PUBLIC by default, so restricting access means revoking it and granting CORTEX_ANALYST_USER through a custom role.

Sources3

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.Cortex Analyst is another AI SQL function you call inside a SELECT, like AI_COMPLETE.Why is that wrong?

   Cortex Analyst is a managed service exposed as a REST API that generates SQL from natural language. AI SQL functions are the SQL-callable feature.

   Covered in Cortex Analyst: natural-language questions over structured data

2. 2.To use Cortex Search you must first generate embeddings yourself and manage a vector index.Why is that wrong?

   Cortex Search provides a hybrid vector and keyword engine and handles embedding, infrastructure, tuning and index refreshes for you.

   Covered in Cortex Search: managed retrieval over text

3. 3.Cortex AI SQL functions are the best choice for low-latency, interactive chat responses.Why is that wrong?

   AI Functions are optimised for throughput and batch processing. For latency-sensitive interactive work, Snowflake recommends the REST APIs.

   Covered in Cortex AI SQL functions: LLMs as ordinary SQL calls

Practise it for real

Create a Cortex Search Service over a small support-transcript table and confirm it returns filtered results

1. 1.Create the support_transcripts table with transcript_text, region and agent_id columns, and insert the four sample rows from the docs

   Why: A search service needs a source query over text data

   You should see: A table with four transcripts across three regions

2. 2.Run CREATE OR REPLACE CORTEX SEARCH SERVICE transcript_search_service ON transcript_text ATTRIBUTES region with an X-SMALL warehouse and TARGET_LAG = '1 day'

   Why: This builds the index and sets which column is searched and which can be filtered

   You should see: The statement completes after the index is built. On large tables this can take much longer

3. 3.GRANT USAGE on the database, the schema and the Cortex Search service to the role that will query it

   Why: Other roles cannot use the service without USAGE on all three objects

   You should see: The grants succeed

4. 4.Run SNOWFLAKE.CORTEX.SEARCH_PREVIEW with the query "internet issues", filter {"@eq": {"region": "North America"}} and limit 1

   Why: Previewing confirms the service is populated before an application relies on it

   You should see: One result: the North America transcript about the internet being down