The Setup: What Teams Expected vs What They Got

When Snowflake first pushed Cortex as a built-in AI layer, the pitch was simple. Keep your data in Snowflake, run LLMs against it, skip the data movement headache. For teams already paying Snowflake bills, that sounded like a reasonable trade.

Practitioners on r/dataengineering and the Snowflake subreddit had a fairly consistent take in the early threads. The expectation was that Cortex would behave like a managed LLM endpoint with Snowflake’s governance baked in. What they got instead was a more opinionated system, one that works well for specific patterns and gets awkward when you push past them.

The split shows up clearly in HN discussions from late 2025 and into 2026. People running Cortex for routine tasks (summarization, classification, extraction against warehouse tables) tend to stay. People trying to build agentic workflows or complex RAG pipelines tend to migrate out within a quarter or two.

Where Cortex Actually Delivers

The strongest signal from practitioner threads is around three specific use cases.

First, batch LLM functions over warehouse data. The COMPLETE, SUMMARIZE, and EXTRACT_ANSWER functions work well when you’re running them against millions of rows in a single SQL statement. One data engineer on Reddit reported processing 4 million rows of customer support tickets through SUMMARIZE in roughly 18 minutes, with the cost landing around $340. That’s roughly $0.085 per 1k tokens for the Mistral-Large model, which is competitive with direct API calls once you factor in the engineering time saved.

Second, Cortex Search for internal document retrieval. Teams running RAG over PDFs and Confluence pages stored in Snowflake stages report decent results for straightforward Q&A. Latency sits around 800ms to 1.4s for typical queries, which is acceptable for internal tools but too slow for customer-facing chat.

Third, Cortex Analyst for text-to-SQL. This one gets mixed reviews, but for the narrow case of “business user asks a question, system generates SQL against a curated semantic model,” it works. Practitioners consistently note that the semantic model file is where the magic happens. Teams that invest time defining measures and verified queries get useful results. Teams that skip that step get garbage.

The pricing model is per token, and Cortex bills through your Snowflake credit consumption rather than a separate LLM provider invoice. That accounting convenience is genuinely useful for finance teams who hate tracking multiple AI vendors.

The Cost and Latency Reality

Here’s where the community signal gets more nuanced.

Latency on Cortex LLM functions is higher than calling OpenAI or Anthropic directly. A common report: 1.2 to 2.5 seconds for a typical COMPLETE call, versus 400 to 900ms for direct API access. For batch processing, this doesn’t matter. For interactive applications, it does.

Cost surprises are the most consistent complaint. Several threads on r/Snowflake describe teams who underestimated credit consumption on Cortex Search and Analyst workloads. One team reported a $14k monthly bill after Cortex Analyst usage spiked during a business user pilot. The lesson that keeps coming up: Cortex credit consumption is harder to forecast than API-based LLM costs because the underlying warehouse compute is harder to attribute.

Model selection is another friction point. Cortex supports Llama 3.1, Mistral, and Claude variants, but you don’t get the full menu you’d have calling these providers directly. If your team has standardized on GPT-4o or Claude Sonnet 4.5 with specific prompting patterns, you’ll need to retest everything on Cortex’s available models.

The token counting also catches people off guard. Cortex counts input and output tokens differently than OpenAI’s API, and the pricing per million tokens varies by model. A practitioner on the Snowflake subreddit put it this way: “Budget for 30% more than the calculator shows, especially on Search.”

Where It Falls Short

The reliability gaps show up in a few specific places.

Cortex Analyst struggles with multi-table joins and complex aggregations. Practitioners consistently report that anything beyond a simple WHERE clause or GROUP BY produces unreliable SQL. One data scientist on HN described spending three weeks building a semantic model that could handle a 4-table join, only to have it break when business users asked questions with ambiguous column references.

Cortex Search has a context window limit that surprises teams. The default chunking doesn’t always preserve document structure, and practitioners report needing to do significant preprocessing to get useful retrieval. A common workaround is to chunk manually before loading documents into stages, which defeats some of the “managed service” benefit.

The biggest gap, based on community discussion, is around custom workflows. If you want to build an agent that calls tools, maintains state, or integrates with external systems, Cortex doesn’t have a native framework. You end up orchestrating from outside, which means you’re paying for Snowflake compute plus your orchestration layer plus your LLM calls. At that point, several practitioners on r/MachineLearning have noted, you’re better off building directly on the LLM provider’s API.

Onboarding friction is real but not catastrophic. New users report a 2 to 4 week ramp to get Cortex functions working in production, mostly around understanding the credit consumption model and the semantic model syntax for Analyst. That’s faster than standing up a custom RAG pipeline from scratch, but slower than calling an LLM API directly.

Who It Fits Best

The pattern from community discussion is fairly clear.

Cortex works best for teams who are already Snowflake-native and want to add AI features without moving data. If your data warehouse is Snowflake, your governance is Snowflake, and your security model is Snowflake, then Cortex removes a category of integration work that would otherwise eat weeks.

Team size matters. The sweet spot in practitioner reports is 5 to 50 person data teams at companies with $1M+ annual Snowflake spend. Below that, the credit-based pricing gets expensive relative to alternatives. Above that, the limitations become more painful as use cases get more complex.

Use case fit is specific. Cortex is well-suited for batch enrichment of warehouse data (summarization, classification, extraction), internal RAG over documents already in Snowflake stages, text-to-SQL for business users against curated semantic models, and compliance-sensitive workloads where data cannot leave Snowflake’s network.

It’s poorly suited for customer-facing chat applications where latency matters, agentic workflows with tool use, anything requiring the latest model from OpenAI or Anthropic, and high-volume, low-latency inference.

Common Pairings and Replacements

The most common pairing practitioners describe is Cortex for warehouse-resident AI tasks, plus direct LLM API access for everything else. Several teams on r/dataengineering report running Cortex for batch processing and OpenAI or Anthropic directly for interactive applications, with a routing layer deciding which path to take.

For teams replacing Cortex, the alternatives depend on the use case. For text-to-SQL, the common replacements are open-source options like Wren AI, or building custom solutions on top of GPT-4o with good prompt engineering. For RAG, teams typically move to dedicated vector databases (Pinecone, Weaviate) with their preferred LLM provider. For batch enrichment, the migration path is usually direct API calls orchestrated from Airflow or dbt.

One pattern worth noting: teams rarely replace Cortex entirely. The data gravity argument is real. Once your data is in Snowflake and your pipelines depend on Snowflake functions, the cost of moving AI workloads elsewhere is high. Most teams end up with a hybrid approach, using Cortex where it makes sense and direct LLM APIs where Cortex falls short.

The Bottom Line

Snowflake Cortex is a competent AI layer for the Snowflake ecosystem, with real strengths in batch processing and warehouse-resident RAG, and real limitations around latency, model selection, and complex workflows. The community signal is consistent: it’s worth piloting if you’re already on Snowflake, but don’t expect it to replace your general-purpose LLM infrastructure.

The teams getting the most value are the ones who scope Cortex narrowly. Use it for what it’s good at, route around what it isn’t, and keep your credit consumption dashboards visible to finance.

The practical next step is the free Working With Claude field guide. Thirty-two pages covering the ecosystem, Claude Code, and how to govern a rollout properly. Get your copy.