Estimated reading time: ~11 minutes. No prior experience required.
The awkward round trip
The first time I bolted AI onto a data warehouse, the plan looked reasonable on a
whiteboard: pull the data out of the warehouse, send it to an AI service
somewhere else, get the answer, bring it back. In practice it was clumsy. Data
had to leave its secure home, travel across the network, get processed elsewhere,
and return, slower, more expensive, and now I had sensitive data copied into a
second place I had to worry about.
The obvious question: why move the data to the AI at all, why not bring the AI
to the data? That's exactly the idea behind Snowflake Cortex: AI features
built right into the Snowflake warehouse, so the model runs next to your data
instead of far away.
By the end of this post you'll understand what Cortex is, its main capabilities,
how you use it, the traps, and how it fits the modern data stack.
Quick note: Snowflake and Cortex are commercial products, not open source. We
include this post because "AI inside the warehouse" is a pattern you'll meet
everywhere now, and the ideas here apply to similar features in other
platforms too.
What is Snowflake Cortex, really?
One sentence: Snowflake Cortex is a set of AI capabilities built directly into
the Snowflake data warehouse, letting you run AI tasks, like summarizing text,
translating, or asking questions in plain English, using simple SQL, without your
data ever leaving Snowflake.
If you've read the Snowflake post, this is "Snowflake, now with a brain attached."
The in-house expert analogy
Imagine your company data is a huge, secure library, and you need documents
analyzed. You could mail each document to an outside consultant, wait, and get it
back, slow, and now your documents are sitting on someone else's desk.
Or you could hire an in-house expert who works inside the library. Documents
never leave the building. You just walk over and ask. Faster, safer, simpler.
Cortex is that in-house expert. The AI lives where the data lives, so you ask
questions right where everything already is, through the SQL you already use.
The core capabilities
Cortex bundles several AI abilities. Here are the ones you'll actually reach for.
1. LLM functions (AI in a single SQL call)
The simplest and most striking: you call an AI model like it's a normal SQL
function. Want to summarize a column of customer reviews? It's one function call
applied across your rows. Sentiment, translation, summarization, all as SQL you
run right in the warehouse.
-- Summarize each review, right inside a query (conceptual)
SELECT
review_id,
SNOWFLAKE.CORTEX.SUMMARIZE(review_text) AS summary,
SNOWFLAKE.CORTEX.SENTIMENT(review_text) AS mood
FROM customer_reviews;
No data export, no separate service, the AI runs where the rows already are.
2. Cortex Analyst: ask your data questions in English
This is the "talk to your data" capability: a business user types a question in
plain English, "what were our top five products by revenue last quarter?", and
Cortex translates it into SQL, runs it, and returns the answer. It turns the
warehouse into something a non-SQL user can interrogate directly.
The key to making this reliable is a semantic model, a description of what
your tables and columns mean in business terms, so the AI maps "revenue" to the
right column instead of guessing.
3. Cortex Search: find relevant text fast
For question-answering over documents, Cortex Search finds the most relevant
passages from your text data (the retrieval piece of the RAG pattern from the
LangChain post), built in, so you don't assemble a separate search system.
4. Cortex Agents: multi-step reasoning
The newest layer: agents that can combine the above, search for relevant data,
generate SQL, call the LLM functions, to answer more complex, multi-step
questions, all within the platform's security boundary.
flowchart LR
U[User asks in English] --> A[Cortex Analyst / Agent]
A --> SEM[Semantic model:<br/>what columns mean]
A --> SQL[Generates SQL]
SQL --> DATA[(Your Snowflake data)]
DATA --> ANS[Answer, grounded in your data]
ANS --> U
Why "AI next to the data" matters
Three real advantages over the awkward round trip:
- Security & governance: data never leaves Snowflake, so it stays inside the same access controls and audit trail (recall the Unity Catalog post's theme, governance matters). No sensitive copies scattered around.
- Simplicity: it's SQL. Your existing analysts can use AI without learning a new stack or standing up model-serving infrastructure.
- Speed & cost: no shuttling large datasets across the network to an external service and back.
A tiny end-to-end taste
The whole appeal is how little you need to do:
-- 1. Classic AI-as-SQL: translate and summarize in one query
SELECT
ticket_id,
SNOWFLAKE.CORTEX.TRANSLATE(body, 'es', 'en') AS english_body,
SNOWFLAKE.CORTEX.SUMMARIZE(body) AS summary
FROM support_tickets
WHERE created_at >= '2026-07-01';
-- 2. Ask a question in English via Cortex Analyst (conceptual),
-- backed by a semantic model that defines "revenue", "region", etc.
-- "What was total revenue by region last month?"
-- -> Cortex generates and runs the SQL, returns the table.
The AI came to the data. The data stayed home.
Common mistakes and gotchas
1. Skipping the semantic model
Cortex Analyst is only as good as the business definitions you give it. Without a
semantic model, it guesses which column means "revenue", and may guess wrong.
Investing in clear semantic definitions is what turns "impressive demo" into
"trustworthy answers."
2. Trusting AI-generated SQL blindly
Just like any text-to-SQL, Cortex can produce a query that looks right but
double-counts or misses a filter. Sanity-check generated numbers against a known
total before you rely on them, especially for anything that drives a decision.
3. Forgetting it still costs money
Running AI functions across millions of rows consumes compute (and Snowflake bills
for compute). Applying SUMMARIZE to your entire history "just to see" can get
expensive fast. Test on a small slice, then scale deliberately.
4. Treating it as a general chatbot
Cortex shines at questions grounded in your data. It's not meant to be a
free-roaming general assistant. Point it at well-modeled data and clear questions;
don't expect it to answer things your data doesn't contain.
5. Ignoring governance on AI outputs
AI-generated summaries or answers can surface sensitive details. The same access
controls that protect your tables should apply to who can run these functions and
see their results. Don't let convenience quietly widen access.
Using AI and agents with Cortex
Since Cortex is AI, the "AI angle" here is about building and refining it well:
- "Draft a semantic model for these tables", an assistant proposes business definitions for columns, a huge head start for making Cortex Analyst reliable.
- "Why did Cortex generate this SQL, and is it right?", have an assistant review the generated query against your intent before trusting the answer.
- "Where should I use a built-in Cortex function vs. an external model?", AI can help you reason about the trade-offs for your specific case.
A word of caution: an AI that can query your warehouse in plain English is
powerful and easy to misuse, a vague question can return a confidently wrong
number. Keep humans in the loop for decisions, validate the semantic model, and
respect the same data-access rules you'd apply to any analyst.
Wrapping up
Snowflake Cortex brings AI to your data instead of shipping your data to the
AI, running models inside the warehouse, through plain SQL, without data ever
leaving its secure home. You learned:
- What it is: AI capabilities built into Snowflake, usable via SQL.
- The capabilities: LLM functions (AI-as-SQL), Cortex Analyst (ask in English), Cortex Search (find text), and Cortex Agents (multi-step).
- Why it matters: governance, simplicity, and speed from keeping the data home.
- The traps: skipping the semantic model, trusting generated SQL blindly, runaway cost, expecting a general chatbot, and neglecting governance.
- The AI angle: drafting semantic models and reviewing generated SQL, with humans validating decisions.
Where to go next
- If you use Snowflake, try one LLM function (like
SENTIMENT) on a small text column. Seeing AI run as SQL is the moment the idea clicks. - Before using natural-language querying seriously, write a small semantic model for a few key tables. Reliability lives there.
- Remember the bigger pattern beyond Snowflake: "bring the AI to the data" is showing up across every major platform, the ideas here transfer.
Hire the in-house expert, and the awkward round trip retires for good.
