7 Things to Know About Snowflake Support Partners

Under the Hood: grounding CoWork with Cortex Sense — not just prompting it

Your agent isn't wrong because your data is dirty. It's wrong because it doesn't know what your data means. An LLM can read your schema perfectly — table names, column types, row counts — and still have no idea that net revenue means gross revenue after discounts, that the fiscal year starts in February, or that "active customer" excludes anyone who churned last quarter. That gap between the schema an agent sees and the business meaning it doesn't is where confident, wrong answers come from. Closing it is now the single highest-leverage thing a data team can do for AI.

That's also the thesis Snowflake built its entire Summit 2026 agentic story around.

What actually changed at Summit 2026

Two things matter for anyone running agents on Snowflake:

Snowflake Intelligence is now CoWork. Same product lineage — the personal work agent that decomposes a question, researches across structured and unstructured data, and returns a cited answer — new name. If you saw Episode 3, this is the thing you already built against. Existing deployments migrate automatically.

Cortex Sense is the headline, and it's about accuracy, not features. Cortex Sense is a runtime context-enrichment layer: it automatically assembles business context — query history, object metadata, BI dashboards, and Horizon Context semantic views — and feeds it to CoWork and CoCo at query time, with no manual configuration. Snowflake's own internal benchmark puts the difference starkly: 47% accuracy on complex enterprise queries without it, 83% with it— and just 23% for frontier coding agents wired up through Snowflake's MCP connector alone. The message Snowflake is sending could not be clearer: context, not the model, determines agent quality.

We agree with that framing. But there are two catches, and they're exactly where a data team's real work lives.

The two catches nobody puts on the keynote slide

Catch #1 — Cortex Sense is private preview (as of June 2026). CoWork is shipping to enterprises now; Cortex Sense is not generally available yet. So the default CoWork deployment today operates closer to that 47% baseline, withoutSnowflake's own context infrastructure at production readiness. You can't wait for the feature to flip on and rescue answer quality before your stakeholders start trusting (or distrusting) the agent.

Catch #2 — even at GA, Cortex Sense is only as good as what's underneath it. Read the description again: it assembles context from your semantic views, metadata, and dashboards. If those definitions are missing, ambiguous, or contradictory, Cortex Sense faithfully assembles ambiguous context. And there's a deeper trap that governance alone never solves: access control is not correctness. RBAC enforces who can query the revenue table; it says nothing about whether that table is accurate, consistently defined, or current. An agent querying a revenue figure with an upstream ingestion error will return a confident, beautifully-cited, wrong number — and every guardrail will have done its job.

So the work is the same whether Cortex Sense is in preview or GA: you build the governed context layer and you make sure the data beneath it is actually right. The good news is that this work is not throwaway — the semantic layer you build now is precisely the substrate Cortex Sense consumes later. You're not waiting for the feature; you're getting ahead of it.

Here's how we build it.

Under the Hood: the context layer, step by step

Step 1 — Put the business definitions in a governed semantic view

A semantic view is a schema-level Snowflake object that maps physical columns to business concepts — facts, dimensions, and metrics — and stores the definitions natively, under RBAC, where both Cortex Analyst and (eventually) Cortex Sense read them. This is where you kill ambiguity once, centrally, instead of in fifty different dashboards.

The canonical example is the one Snowflake itself uses: revenue is physically stored in a column called amt_ttl_pre_dsc, but the business always means gross revenue after discounts. You encode that once:

CREATE OR REPLACE SEMANTIC VIEW analytics.sales.revenue_model
  TABLES (
    orders AS prod.sales.orders
      PRIMARY KEY (order_id)
      WITH SYNONYMS ('sales', 'bookings')
      COMMENT = 'One row per order line. Source of truth for revenue.',
    unit AS prod.sales.business_unit_dim
      PRIMARY KEY (unit_id)
  )
  RELATIONSHIPS (
    orders_to_unit AS orders (unit_id) REFERENCES unit (unit_id)
  )
  FACTS (
    orders.gross_amount   AS amt_ttl_pre_dsc,
    orders.discount_rate  AS disc_rate
  )
  DIMENSIONS (
    unit.unit_name    AS unit_name WITH SYNONYMS ('business unit', 'segment'),
    orders.order_date AS order_dt
  )
  METRICS (
    orders.net_revenue AS SUM(orders.gross_amount * (1 - orders.discount_rate))
      COMMENT = 'Net revenue = gross revenue after discounts. Use this for ALL
                 revenue reporting. Never sum amt_ttl_pre_dsc directly.'
  )
  COMMENT = 'Governed revenue model. These definitions are the single source
             of truth for agents and BI alike.';

‍

Now anyone — human or agent — asks the question the same way and gets the same number:

SELECT * FROM SEMANTIC_VIEW (
  analytics.sales.revenue_model
  METRICS    net_revenue
  DIMENSIONS unit_name
);

‍

Step 2 — Write your comments like prompts, because they are

This is the part that separates "it compiles" from "the agent is actually right." In a semantic view, Cortex Analyst reads your COMMENT text as instructions, not documentation. The comment on net_revenue above isn't a note for a future engineer — it's telling the model which column is not revenue. Be that explicit everywhere: define what a metric means, when to use it, and what to avoid. If you don't write it down, the model guesses, and a guess is how you get a wrong answer on clean data.

Two more high-leverage moves on the same object:

• Synonyms so "business unit," "segment," and "BU" all resolve to one dimension. Agents fail constantly on vocabulary mismatch; this fixes it cheaply.
• Verified queries — known-good question/SQL pairs that anchor the model on your hardest or most political metrics:

‍

-- inside CREATE SEMANTIC VIEW, after the COMMENT clause:
AI_VERIFIED_QUERIES (
  net_rev_by_unit AS (
    QUESTION  'What was net revenue by business unit last quarter?'
    VERIFIED_AT 1717200000
    VERIFIED_BY '(owner = data-platform@yourco.com)'
    SQL 'SELECT * FROM SEMANTIC_VIEW (analytics.sales.revenue_model
           METRICS net_revenue DIMENSIONS unit_name)'
  )
);

‍

One discipline worth stating plainly: only add verified queries you have actually validated. One wrong example teaches the model a bad habit at scale.

Step 3 — Measure the lift on your KPIs, don't take 47→83 on faith

Snowflake's benchmark is theirs, on their data. Before you tell your CFO the agent is trustworthy, prove it on your questions. Snowflake ships a Cortex Agent evaluation framework for exactly this — define a dataset of real questions with expected answers, then score the agent against it:

‍

evaluation:
  agent_params:
    agent_name: "revenue_agent"
    agent_type: "CORTEX AGENT"
  run_params:
    label: "Baseline — before semantic layer"
    source_metadata:
      type: "dataset"
      dataset_name: "kpi_eval_set"
  metrics:
    - answer_correctness        # how close the answer is to ground truth
    - tool_selection_accuracy   # did it call the right tools? (public preview)
    - logical_consistency       # reference-free; consistency across the run

‍

Run it once before the semantic layer exists, run it again after. The delta is your evidence — and your regression test. Wire it into CI so a careless change to a metric definition can't silently re-break answer quality next month.

Step 4 — Fix the data the context layer points at

A perfect semantic layer over a stale or half-loaded table still produces a wrong answer, just a well-defined one. So the context work has a twin: source-to-report reconciliation, freshness checks, and catching the broken or partial feeds that quietly poison a metric. That's a whole topic — it's Episode 5 — but flag it now, because "the agent gave the wrong number" is at least as often an ingestion problem as a semantics problem.

What this means, by role

If you lead data or analytics: the semantic layer is no longer a BI nicety — it's the accuracy substrate for every agent you're about to be asked to deploy. Building it now pays twice: better Cortex Analyst answers today, and a ready-made context source for Cortex Sense when it GAs.

If you're the architect or lead engineer: treat semantic views as strict contracts, not flexible SQL. Model relationships explicitly, comment like you're prompting, anchor hard metrics with verified queries, and put an evaluation set in CI. This is the build work that makes the demo survive contact with production.

If you own the platform strategy (VP / CDO): the question your stakeholders are really asking is "can we trust this for a real decision?" The honest answer is "only as far as our governed definitions and our data quality go." That's a roadmap, not a blocker — and it's a far better place to invest than another model evaluation.

How we'd approach it

Most teams we talk to don't have a context problem they can see — they have a trust problem they can feel: two dashboards disagree, an agent answer doesn't match the board deck, nobody's quite sure which number is right. The fix starts with finding where the definitions diverge and where the data underneath is wrong, before pointing any agent at it.

That's the shape of our AI-readiness assessment — a fixed-scope first step that maps your sources, definitions, and the gaps between what your reports say and what your data actually contains, so the agents you ship are accurate by construction. If your CoWork answers are landing in the "confident but wrong" zone, that's the place to start.

‍

‍

‍

Notes & sources: Cortex Sense status and the 47%→83% figure are from Snowflake's own materials and product announcements (Snowflake Summit 2026, June 2); Cortex Sense is in private preview as of June 2026, so treat the figure as a vendor benchmark and validate on your own data. Semantic-view DDL and the comment-as-instruction behavior follow Snowflake's CREATE SEMANTIC VIEW and semantic-view documentation; semantic-view SQL is stricter than ordinary SQL, so validate any DDL against current docs for your account version. Cortex Agent evaluation metrics (answer correctness, tool-selection accuracy, logical consistency) are from Snowflake's Cortex Agent evaluations documentation.

‍

Let's be honest. Your current database was most likely built for monthly reports, not AI products that demand regular updates and reports all the time. This is the reason why, in 2025, really innovative and data-driven businesses continue their migration away from legacy databases like Oracle, Teradata, SQL Server, and on-premises MySQL/PostgreSQL toward modern cloud-native architectures. Snowflake has become the industry leader, powering analytics and AI workloads across finance, retail, technology, and enterprise sectors.

This guide breaks down 7 core Snowflake capabilities and shows how the right Snowflake consulting can turn them into best results for your teams.

‍

What is the legacy database challenge?

Before diving into Snowflake's capabilities, it's crucial to understand the limitations organisations face with traditional databases. Therefore, let’s consider the scenario of a global FMCG company operating in multiple regions, where we helped transform the data infrastructure from legacy on-prem systems to

With our expert Snowflake migration services, the company moved to Snowflake + dbt + Fivetran + Tableau as a modern data stack.

‍

‍

The 7 core Snowflake capabilities in 2025

1. Multi-cluster shared data architecture

The fundamental differentiator: Snowflake's three-layer architecture completely separates storage from compute resources.

Key benefits:

• Unlimited concurrency
• Auto-scaling virtual warehouses
• Near-zero locking and contention
• Pay-as-you-use compute

This means analysts, data scientists, and applications can work in parallel on the same datasets without contention.

Business impact:

You no longer have to buy extra storage just to get more compute. You scale up when you need power, scale down when you don’t, and you can see what that means for your bill in minutes with our FinOps savings calculator

2. Cross-cloud & multi-region replication

This Snowflake capability is critical for regulated industries (financial services, healthcare, insurance) and companies with international operations requiring data sovereignty compliance.

Snowflake delivers:

• Multi-cloud availability on AWS, Azure, and Google Cloud Platform
• Easy cross-region replication and failover
• Global application distribution
• Built-in disaster recovery without complex configuration

Plan residency, failover, and recovery during platform architecture, then implement Snowflake like a pro.

Business impact:

A global FMCG company can maintain synchronized data across North American, European, and Asian markets while meeting local data residency requirements. This is difficult to achieve with legacy on-premises databases.

3. Zero-copy cloning & time travel

Snowflake's innovative approach to data management enables instant environment creation with zero additional storage costs.

Game-changing features:

• Clone terabyte-scale databases in seconds without duplicating data
• Time Travel for historical queries and point-in-time recovery
• Safe dev/test environment provisioning without impacting production

Development teams can spin up complete production-like environments instantly for testing, while legacy databases require duplicated environments that consume massive storage and take hours or days to provision.

Business impact:

Data engineers can test complex transformations on production-scale data without risk, dramatically accelerating development cycles and improving data reliability.

4. Built-in governance & RBAC security

In 2025, data governance and security are business-critical requirements for compliance and risk management.

Snowflake's security framework includes:

• Fine-grained access control with row-level and column-level masking
• Data lineage and classification for understanding data provenance
• Policy-based access control with external tokenisation partner support
• Automatic encryption at rest and in transit
• Dynamic data masking to protect sensitive information
• Audit logging and monitoring for compliance reporting

These are essential for organisations operating under SOC 2, HIPAA, GDPR, PCI DSS.

5. Native AI & Python ecosystem

Snowflake has built-in support for Python and machine learning, so your team can build and run models where the data already lives instead of exporting them elsewhere. With solid AI and data governance in place, it becomes easier to try new ideas safely and move them into production. The key building blocks are:

‍

Business impact:

This means that teams can train, deploy & serve ML models securely inside Snowflake. Data scientists spend less time on data engineering and infrastructure management and more time building models that drive business value.

6. Marketplace & data sharing economy

The Snowflake Marketplace reshapes how enterprises access 3rd-party data (functioning as the "App Store for data"). We are looking at:

• Thousands of data providers covering financial data, geospatial information, retail insights, weather patterns, ESG metrics, and logistics intelligence
• Live data feeds without pipelines (No ETL required)
• Private data exchange across subsidiaries, partners, and customers

Business impact:

You can now achieve faster analytics, better forecasting, and smarter decisions by instantly accessing external data sources that would traditionally require weeks of negotiation, integration work, and ongoing pipeline maintenance.

7. Extensibility: unistore & native apps

Snowflake is no longer just a data warehouse. In 2025, it can also handle simple day-to-day transactions and apps that run directly on your data.

Next-generation capabilities:

• Unistore for OLTP-lite workloads, enabling hybrid transactional/analytical processing
• Snowflake Native Apps for custom application development
• Streamlit integration for building interactive data applications
• Real-time data pipelines via Kafka connectors and Snowpipe Streaming

Business impact:

Snowflake serves hybrid workloads that legacy databases struggle to handle without significant operational complexity. Organizations consolidate their data infrastructure rather than maintaining separate systems for transactional and analytical workloads.

Real-world example: Snowflake consulting & migration results

Here’s what the shift looks like in practice. In a recent Snowflake project with a global FMCG company, we rebuilt the analytics backbone by establishing a governed core data model, automating ingestion and orchestration with native services and partner connectors, and reconnecting BI directly to a single, auditable source of truth. As seen in the table below, the result was a step-change in reliability and speed.

Documented results from migration to Snowflake:

‍

Beyond the database

Snowflake’s strengths include a unique design, flexible scaling, strong access and security controls, built-in AI features, and safe sharing across regions, which make it more than a database. It is a modern cloud data platform that powers predictive analytics, self-service reporting so product teams can trust the data and use it with ease. In business, the faster you get answers, the stronger your advantage, and Snowflake is setting the standard for company data platforms.

If you are choosing a data platform in 2025, plan for what you will need next year as well as today. Snowflake’s design is built for an AI-ready cloud-based future. We help you make that future real by setting up Snowflake, connecting your data, putting clear access rules in place, and keeping costs under control with a simple 90-day plan that we build with your team.

Ready to turn Snowflake into results?

‍

What if your PDFs, transcripts, and logs could live in the same place as your BI dashboards? For years, Snowflake was known primarily as a cloud native data warehouse built for structured analytics. It was the go-to solution for SQL analysts, BI teams, and data engineers working with neat rows and columns. Meanwhile, many teams dealing with documents, images, logs, and raw application data assumed they needed separate storage such as Amazon S3, Google Cloud Storage, Azure Blob, or NoSQL databases.

In 2025, that separation no longer has to exist. Snowflake is now a multimodal data platform that can store, process and query unstructured data.

So yes, Snowflake can store unstructured data, but more importantly, it can use it. This capability offers significant architectural advantages for modern data teams. In this blog post, we’ll break down exactly how and why it matters.

What is unstructured data?

Unstructured data refers to any information that doesn't fit neatly into traditional rows and columns. This includes:

• Documents: PDF, DOCX, TXT files
• Images: PNG, JPG, TIFF formats
• Audio and video files: Media content and recordings
• Logs and event data: Application and system logs
• Communication data: Email threads and chat transcripts
• Markup and structured text: HTML, XML, JSON blobs
• Binary files: Application-specific file formats

As organisations increasingly generate massive volumes of this data, the need for unified platforms that can both store and analyse unstructured content has become critical.

How Snowflake stores unstructured data?

Snowflake stages for unstructured data

Snowflake manages unstructured data through stages. This means through storage locations that reference files either within Snowflake's managed infrastructure or in external cloud storage:

• Internal Stages: Files are stored within Snowflake's managed storage, offering quick setup and seamless integration
• External Stages: Files remain in external cloud locations (Amazon S3, Azure Blob Storage, Google Cloud Storage), with Snowflake accessing them via metadata references

You can also combine both approaches for optimal performance and scalability based on your specific requirements.

The FILE data type in Snowflake for unstructured files and metadata

Snowflake provides a dedicated FILE data type for unstructured data. A FILE value represents a reference to a file stored in an internal or external stage, without storing the actual file content in the table itself. This approach allows:

• Efficient storage and cost management
• Fast metadata querying
• Seamless integration with processing pipelines

Accessing unstructured files in Snowflake

Snowflake provides familiar commands for file management:

• PUT: Upload files to stages
• GET: Download files from stages
• LIST: View files stored in stages

These operations mirror cloud storage interactions while maintaining Snowflake's security and governance standards.

Processing and querying unstructured data in Snowflake

Storage is just the beginning. Snowflake's real power lies in its ability to process and extract insights from unstructured data.

Snowflake Cortex AI and Document AI for PDFs, images and hybrid search

Cortex AI enables advanced analytics on unstructured data directly within Snowflake:

• Document analysis: Extract text, summarise content, and perform batch LLM inference on PDFs and documents
• Image processing: Run classification and analysis on stored images
• Multimodal SQL functions: Query and transform documents, images, and audio using SQL-powered pipelines
• Schema-aware extraction: Automatically extract structured tables from unstructured documents like invoices and reports

Snowpark for custom processing

With Snowpark, you can:

• Extract text from PDFs using Python
• Perform image classification with embedded ML models
• Parse JSON or log files into VARIANT columns
• Run OCR, NLP, and generate embeddings via external functions
• Build semantic search capabilities over document collections

VARIANT data type for semi-structured data

The VARIANT data type handles semi-structured data formats like JSON, XML, Parquet, and Avro:

• Store complex, nested data structures
• Query JSON fields directly using SQL
• Maintain schema flexibility while preserving query performance

Why unified data architecture matters?

In most companies, data still lives in many places and tools. Dashboards sit on a legacy SQL warehouse, logs go to a separate observability stack, and documents and images disappear into unmanaged cloud buckets or shared drives.

Instead of stitching together a dozen point solutions, you can use Snowflake as the backbone of your data architecture and keep external systems only where they add unique value. The table below shows how data stack functions shift when you standardise on Snowflake in 2025:

‍

Real-world use cases of handling unstructured data in Snowflake

Here is how this looks in practice. Below is our recent project, plus common patterns we see when teams bring documents, images, logs, and app data into Snowflake and put them to work.

Global finance, AI-ready in 90 days

A multinational finance firm spending more than 800K per month on cloud was battling rising costs and fragmented data. They needed a governed place for documents, logs, and tables. We used OpenFlow to ingest both structured and unstructured data into Snowflake, tracked lineage and policies in Horizon Catalog, set consistent business logic with semantic views, and enabled natural language querying through Cortex AI SQL. The result was about an 80% reduction in ingestion latency, real-time cost visibility with FinOps, and a platform ready for analytics, ML, and AI at scale.

Read how a global finance managed unstructured data in Snowflake →

Limitations and considerations of Snowflake

Snowflake’s unstructured data capabilities are strong, but it won’t fully replace your data lake or media platform. For B2B teams planning at scale, keep these practical constraints in mind:

• Not a pure object storage replacement: Snowflake complements rather than replaces S3/GCS for massive-scale raw object storage
• File retrieval performance: Binary object retrieval speed varies by file size and stage type
• Compute costs: AI and ML workloads require careful resource management
• Specialised use cases: For intensive video/audio editing, use specialised systems.

Best practices for managing unstructured data in Snowflake in 2025

1. Keep big binaries in external object storage, keep brains in Snowflake

Register S3, Blob, or GCS as external stages and reference files via the FILE type; keep only hot assets in internal stages for speed.

2. Standardize file layout and formats from day one

Use predictable paths (org/source/system/YYYY/MM/DD/id) and checksums; prefer compressed columnar formats like Parquet, with extracted text or page JSON beside PDFs and images.

3. Store metadata and embeddings in Snowflake, not in files

Put raw files in stages, but keep metadata, chunks, and embeddings in Snowflake tables linked by stable URIs for fast search and governance. Use directory tables to catalog staged files.

4. Orchestrate ingest → extract → enrich → index → serve with Snowpark

Run OCR, NLP, and parsers as Snowpark tasks and UDFs; batch, log runs, and make jobs idempotent so reruns are safe. Implementation flow in processing files with Snowpark.

5. Treat AI as a costed product

Separate warehouses for ELT and AI, strict auto-suspend, resource monitors, caching, and reuse of embeddings and summaries. Get a baseline with the FinOps savings calculator.

6. Govern at the row, column, and file edge

Classify on arrival, enforce row and column policies with masking, and keep least-privilege stage access and full lineage. For role design patterns, see Snowflake role hierarchy best practices.

Need a hand?

Our snowflake experts at Snowstack can audit your current setup, design a lean reference architecture, and prove value with a focused pilot. Read how we deliver in How we work or talk to a Snowflake expert.

‍

Final thoughts

Snowflake doesn’t just store unstructured data; it makes it usable for search, analytics, and AI. With stages, the FILE data type, VARIANT, Snowpark, and Cortex, you can land documents, images, and logs alongside your tables, extract text and entities, generate embeddings, and govern everything under a single security and policy model. The winning pattern is simple: keep raw binaries in low-cost object storage, centralise metadata and embeddings in Snowflake, and start with one focused, high-value use case you can scale.

Ready to try this in your stack?

‍