by datastudy.nl

Field notes for enterprise data engineers and scientists

Engineering

Cortex Analyst: let business users query Snowflake in plain English

Cortex Analyst is Snowflake's managed text-to-SQL service: business users ask questions in natural language and get answers without writing SQL. The accuracy depends almost entirely on a semantic view you build, and it is billed per message, not per token.

Bar chart of text-to-SQL answer accuracy: about 45 percent from raw schema versus about 90 percent with a semantic view
Illustrative: text-to-SQL accuracy jumps when Cortex Analyst is given a semantic view instead of a raw schema, from roughly 45 percent to roughly 90 percent. Snowflake Cortex Analyst documentation.

The most expensive bottleneck in most data teams is not compute, it is the queue. Business users have questions, only the analysts can write SQL, and every "quick number" becomes a ticket. Cortex Analyst is Snowflake's answer: a fully managed text-to-SQL service where a business user asks "what was month-over-month revenue growth in EMEA last quarter" in plain English and gets a real answer, generated as SQL, run on your warehouse, with no analyst in the loop. It ships as a REST API so you can drop it into Slack, Teams, a Streamlit app, or your own product. The thing that decides whether it delights users or embarrasses you: the semantic view you build first. Point it at a raw schema and it guesses; give it a semantic model and it gets the business logic right.

This guide is for the data engineer who will be asked to "add AI to our analytics" and needs to know what Cortex Analyst really is, what makes it accurate, what it costs, and where it falls down.

Why does a semantic model matter so much?

Generic text-to-SQL fails in enterprises for a boring reason: a database schema does not contain business meaning. A column called rev_amt does not tell a model that revenue excludes returns, that "EMEA" maps to a specific set of country codes, or that "active customer" has a precise definition your finance team agreed on. Hand a model just the schema and it hallucinates the business logic.

Cortex Analyst closes that gap with a semantic view, a schema-level Snowflake object that defines the business layer over your tables: logical tables for entities like customers and orders, dimensions for categorical context, facts for row-level numbers, metrics for the KPIs with their correct aggregation formulas, and the relationships that define how tables join. That metadata is what turns a vague question into the right SQL.

Bar chart of text-to-SQL accuracy: about 45 percent from raw schema, about 90 percent with a semantic view
Illustrative: giving Cortex Analyst a semantic view rather than a bare schema is the single biggest lever on answer accuracy. Source: Snowflake Cortex Analyst documentation on semantic models.

The practical consequence: the work is not the AI, it is the semantic model. Snowflake handles the language model, the model selection, and the text-to-SQL machinery. Your job is to encode the business definitions once, well, so the answers are trustworthy. Skip that and you ship a confident liar.

-- A semantic view is the business layer Cortex Analyst reasons over.
-- It names entities, the metrics with their real formulas, and join paths,
-- so "revenue" means what finance means, not whatever a column is called.
CREATE SEMANTIC VIEW sales_analytics
  TABLES (
    orders AS analytics.public.orders PRIMARY KEY (order_id),
    customers AS analytics.public.customers PRIMARY KEY (customer_id)
  )
  RELATIONSHIPS (
    orders (customer_id) REFERENCES customers (customer_id)
  )
  FACTS (orders.line_total AS quantity * unit_price)
  METRICS (orders.net_revenue AS SUM(line_total) WHERE status != 'returned')
  DIMENSIONS (customers.region AS region);

You can build it with the Semantic View Autopilot or hand-write the YAML, and you should seed it with verified example questions and their correct SQL, which Snowflake uses to guide generation and lets you measure accuracy over time.

What does it cost, and how is that different from raw Cortex?

This is where Cortex Analyst surprises people in a good way. Most Cortex AI functions bill per token, so a long prompt costs more. Cortex Analyst bills per message instead: each successful request (HTTP 200) counts as one unit, and the number of tokens does not affect the price unless you call it through Cortex Agents. Failed requests are not charged.

The cost you must not forget is the second meter. Cortex Analyst's per-message charge covers only the text-to-SQL generation. The generated SQL then runs on your virtual warehouse, and that compute is billed separately. So a chatty dashboard that fires hundreds of questions an hour costs you on two lines: the Analyst messages and the warehouse time to execute every query. Track the first with the CORTEX_ANALYST_USAGE_HISTORY view in ACCOUNT_USAGE and the second the same way you watch any warehouse, as covered in the warehouse sizing guide.

  • Right-size the warehouse behind it. The questions are usually small aggregations, so a small warehouse with auto-suspend is plenty. You do not need a big cluster to answer "total revenue last month".
  • Cache the obvious. If the same ten questions arrive all day, the generated SQL is deterministic enough to cache results upstream rather than re-running every time.
  • Watch multi-turn cost. Follow-up questions resend the whole conversation history on every turn, and the cost grows with each round, so long rambling sessions cost more than crisp ones.

What can it not do yet?

Set expectations honestly with stakeholders, because Cortex Analyst is narrower than "ask anything". It answers questions that can be resolved with SQL over your structured data, and nothing else. It does not generate open-ended business insight: ask "what trends do you see" and it has no answer, because that is not a SQL query. It also cannot reference the results of a previous query, so "what is the revenue of the second product you just listed" breaks, since it does not have the earlier result set in hand. And very long, intent-shifting conversations degrade, at which point the fix is to reset and start clean.

Governance is the part you can reassure security about. Cortex Analyst runs inside Snowflake's perimeter, the default models from Mistral and Meta keep data and prompts within Snowflake's governance boundary, it does not train on your data, and the generated SQL executes under the calling user's role-based access control, so a user can never get an answer from data their role cannot see. Access is gated by the SNOWFLAKE.CORTEX_ANALYST_USER database role, which you grant to a custom role rather than directly to users. For the broader access-control pattern, see the governance guide.

The honest read

Cortex Analyst is one of the few enterprise AI features where the value is real and the work is well understood: it moves the analyst queue off your team and onto a managed service, and it does so without your data leaving Snowflake. The catch is that it is only as good as the semantic model you invest in, and that model is ordinary, unglamorous data-modelling work, not magic. Teams that treat the semantic view as the product ship something business users trust. Teams that point it at a raw schema and call it AI ship a demo that quietly gives wrong numbers, which is worse than no answer at all.

Sources