Snowflake Summit 2026: What Actually Shipped, and What It Means

Snowflake Summit wrapped up back in early June, but the second day of keynotes got pushed to a virtual session a few weeks later after a medical emergency forced Snowflake to cancel the in-person portion. That delay is also why this recap took a while. We wanted to wait until every announcement was actually confirmed before trying to make sense of all of it.

Ian Whitestone, co-founder of SELECT, and Jeff Skoldberg, founder of Green Mountain Data Solutions, sat down to go through it. Summit produces something like 70 announcements in a single event, and most of them blur together unless someone sorts out what's actually new, what's finally hit general availability, and what's still just a roadmap slide. That's what this post does, organized by the same topics Ian and Jeff worked through on the call.

The rebrand behind everything else

Snowflake kicked things off with two renames that end up touching almost every other announcement. Cortex Code is now called Coco. Snowflake Intelligence is now called Cowork. Coco is built for developers and builders. Cowork is built for business users who want answers, not code.

Nearly every other feature in this recap either runs on Coco or feeds into Cowork. That's the throughline for the whole event.

Data engineering and ingestion

OpenFlow goes headless. OpenFlow extracts and loads data into Snowflake, competing directly with tools like Fivetran and orchestrators like Dagster. Jeff pointed out that the OpenFlow UI has historically been hard to use. The fix Snowflake shipped is a headless, programmable object model you can drive entirely through Coco, so instead of clicking through a confusing interface, you describe what you want and an agent builds it.

Snowflake DataStream is Kafka on Snowflake. It's wire-compatible with Kafka, so in theory you point your existing Kafka producers at a new Snowflake URL and data starts landing directly in your tables, no intermediate bucket required. Ian called this one of the bigger announcements of the event: it removes a whole category of external vendor dependency for real-time ingestion, and it works with both native Snowflake tables and Iceberg tables.

Postgres data mirroring might be the single biggest announcement for application builders. Flip a switch, and your Postgres data shows up in Snowflake automatically through change data capture, no ETL pipeline required. Traditional BI is stale by definition: batch loads run once an hour or once a day, so anything that happened in your source system since the last load doesn't show up yet. This closes that gap for use cases where Postgres is the operational database. Ian sees this as Snowflake's answer to the hybrid transactional-analytical pattern that Unistore was originally built for, minus the complexity of standing up that architecture yourself.

Snowflake Postgres hit GA, along with private link support for business-critical accounts, customer-managed keys, and something called PGLake: a way to use Postgres itself as your Iceberg catalog instead of a JSON-based one. Jeff reads this as a direct answer to DuckLake, which made a similar catalog-alternative move first.

AI-powered migrations claim an 88% time reduction. Neither Ian nor Jeff is willing to vouch for that number. Ian's read: "This is peak marketing, a number that's pulled out of thin air to make it look really good." Take it as a directional signal that AI-assisted migration is faster, not a number to plan a budget around.

Compute and performance

A few announcements here build on each other rather than standing alone:

• Adaptive compute is going GA. It's Snowflake's move toward something closer to BigQuery's model, where you think less about warehouse sizing. Jeff's take, based on SELECT's own webinar on the topic before Summit: there's still sizing to think about, but this is clearly the direction Snowflake is heading, and it's likely to become the default compute option within a few years. Ian flagged one important caveat: several customers have assumed adaptive compute is a cost-saving feature. It isn't. It's designed to improve performance without manual tuning, not to lower your bill.
• Interactive workloads builds on interactive tables and interactive warehouses, which exist to compete with ClickHouse on low-latency analytics. This release adds cluster sizing, key selection, and precaching improvements on top.
• The interactive compiler claims a 40x speedup on compile time. Jeff dug into this one and still isn't fully certain whether it applies only to interactive workloads or to every query running on standard Snowflake warehouses. The public information is inconsistent enough that we're flagging the uncertainty rather than guessing.
• Unistore engine optimization shipped alongside these, with fewer public details so far.

Ian's summary: interactive workloads and Unistore are aimed squarely at teams building fast, application-style experiences on top of Snowflake. Adaptive compute targets more traditional ETL and BI workloads, and it's about performance, not cost.

AI functions and Cortex

AI Complete now reads audio and video, not just text and images.

Cortex AI Function Studio (public preview) lets you build your own custom Cortex functions. Point it at rows containing images, ask it to flag which ones show a specific attribute, and it returns a function you can call like any other. Platform teams can vet the function before it rolls out broadly.

xAI joins the model lineup, alongside Anthropic, OpenAI, Google, Meta, Mistral, and DeepSeek. This one matters less for Grok specifically and more for what it signals: Snowflake is positioning itself as a secure aggregation layer for whichever LLM you want to use, governed through your existing Snowflake credentials instead of managing separate API keys per provider.

Agentic search is easy to confuse with the existing Cortex Search. The distinction: Cortex Search pulls back text snippets and wordy answers from unstructured documents. Agentic search is built to return a single, deterministic answer, so a question like "how many contracts are dated 2025" comes back with a number instead of a stack of contract excerpts.

Code bundles let you run Python as a plain .py file. Previously, running Python in Snowflake meant wrapping it in a SQL stored procedure or working in a notebook, neither of which supported normal debugging workflows. Now you upload a Python file to a stage and schedule it directly. Ian called out how long this took: "I have to wrap it in this other language in order to define it? That's not what I wanted." The stored-procedure requirement was a genuinely clunky part of the developer experience, and removing it matters for winning over teams that just want to write Python.

On the ML side: Cortex Training (private preview) lets you fine-tune open models like Qwen and Mistral on your own data, reportedly getting a much smaller model to outperform a much larger one once it's trained on your specific dataset. The Snowflake Pipeline Builder adds a drag-and-drop interface for building ML pipelines, similar in spirit to tools like Alteryx, with Coco available to help scaffold it. VS Code and Cursor extensions for ML, plus online A/B testing, also moved to public preview.

Apps and consumption

Streamlit on Snowflake hit GA, now running on a container runtime instead of dedicated Streamlit warehouses. Container pools bill at a fraction of a full warehouse credit per hour, so this should meaningfully lower the cost of running Streamlit apps.

App Runtime solves a real problem: discoverability. Jeff tested this directly by deploying the same app in both Snowpark Container Services and App Runtime. The functional difference is that App Runtime apps show up in an Apps tab inside Snowsight, so people across the company can actually find them. Apps built directly in Container Services require someone to already have the URL bookmarked, or nobody finds them at all.

Snap and Ask lets you select a chart Cowork generated and ask follow-up questions about it directly. Snowflake didn't demo it live, so there's not much more to say yet beyond watching for it in upcoming releases.

Interoperability and data sharing

Iceberg v3 reached GA, and Snowflake is claiming the broadest v3 support of any Iceberg vendor, including full support for atomic inserts, updates, deletes, and merges. The Iceberg REST catalog also makes cross-engine workflows possible: transform data in DuckDB, and the changes show up in Snowflake through the shared catalog.

Snowflake-managed Iceberg storage is GA on AWS, with Azure and GCP coming soon. One structural change worth knowing about even though it wasn't a headline slide: standing up and managing your own Polaris catalog is going away entirely. Everything now routes through the Horizon catalog by default, running Polaris underneath without ever surfacing that concept to the user. Create a table as type Iceberg, and it shows up in Horizon automatically.

Ian's read on Iceberg adoption more broadly, based on SELECT's customer base: it's still concentrated in two groups. Digital-native companies with very large datasets and strong engineering teams (think Coinbase, Shopify), and large enterprises with the engineering headcount to manage the complexity. Snowflake's continued investment here is aimed at lowering that barrier to entry.

A question came in during the webinar from Paul Horan about whether fine-grained RBAC (row filtering, column masking) extends to the Iceberg REST catalog itself, so that consumers using something like Athena get governed the same way Snowflake users do. Neither Ian nor Jeff had a confident answer. Jeff's experience has been to keep governance inside the Snowflake layer while using the REST API purely for data movement, which sidesteps the question rather than answering it. This looks like a real open problem for anyone trying to build a genuinely multi-engine architecture without duplicating a governance layer across every engine.

Other data-sharing updates:

• Data resharing now includes a flag letting providers decide whether their consumers can reshare data downstream.
• Open sharing lets you expose data to non-Snowflake customers through a REST API, no Snowflake account or reader account required on their end.
• Clean rooms also got updates, though this is outside what either Ian or Jeff felt confident speaking to in detail.
• The zero-copy ecosystem expanded to include SAP, Workday, and IBM watsonx.data (spelled that way, not a typo), joining the existing Salesforce integration.

On that last point, both Ian and Jeff pushed back on the framing a bit. Standing up something like Salesforce Data Cloud or SAP Business Cloud to get zero-copy access often costs more than simply ETLing that data into Snowflake the traditional way. Jeff's take: it's not really a cost-saving move, it's a simplicity move, and worth evaluating on those terms rather than assuming it saves money by default.

Cowork also picked up connectors to Redshift, Postgres, and other external services, functioning much like MCP servers. Snowflake demoed this live: an agent pulled data from Snowflake and enrichment data from Redshift in the same conversation to answer one question.

Coco, everywhere

Coco (formerly Cortex Code) now shows up throughout Snowsight, in the Horizon catalog, and inside Workspaces, represented by a blue sparkle icon. A few specific surfaces worth knowing about:

• Coco for Desktop is a full VS Code fork with an agent mode (chat-style interface) and an editor mode that looks like standard VS Code. Jeff has been testing it and says it's genuinely well built, though he's still primarily using VS Code with the Claude Code plugin as his main setup. He estimates he's about 15% into the Coco ecosystem for the cases where it clearly handles Snowflake-specific tasks better.
• The core Snowflake VS Code extension now includes Cortex Code access directly, via a sparkle icon in the top corner.
• A public skill catalog exists outside the Coco interface itself, and Coco also has a plugin for Claude.
• Cloud agents can now run in isolated sandbox environments inside Snowsight, so agent-driven changes don't risk destroying resources they shouldn't touch.

Cowork gets smarter about routing

Cowork no longer requires picking the right agent before asking a question. An orchestrator now figures out which underlying agent should handle the request, removing a step that was asking a lot of non-technical users.

User-specific memory is new too, similar to how Claude retains context across a conversation. Cowork can now build up personal skills and memory tied to what a specific user has been working on.

The connector ecosystem is broader than the slide made it look: Slack, Teams, and calendar integrations all feed into Cowork now. The example Snowflake demoed: ask Cowork "what does my day look like," and it checks your calendar, notices a sales meeting, pulls the relevant Salesforce account notes, checks Slack history for related mentions, and pulls the most relevant Snowflake data, then returns an actual prep summary for that meeting.

Scheduled tasks and automations let you set recurring checks, like asking Cowork to check a specific product release page weekly for a feature you're waiting on. Jeff is using this himself to track when Snowflake ships the ability to combine multiple pinned artifacts (charts saved from Cowork responses) onto a single dashboard.

Cortex Sense builds context from query history, dashboards, and metadata to improve accuracy. Neither Ian nor Jeff had a clear sense of exactly how you'd interact with it directly yet.

Governance, trust, and reliability

Intent-driven governance might be the most interesting announcement in this section. Instead of manually writing policies, you describe an intent in plain English, something like making sure no Social Security numbers are exposed, and Snowflake scans the account for violations and helps you fix them.

Per-user AI quotas let you cap spend per person per day rather than relying on a single account-wide budget. Jeff's practical approach with clients: standing up Claude Sonnet 4.6 as essentially the only enabled model in some accounts, since it's efficient and priced well now that newer models like Opus and Fable exist. That way nobody accidentally queries a much more expensive model and runs up an unplanned bill.

If controlling AI spend on Snowflake is something you're actively working through, The Unofficial AI Cost Optimization Manual for Snowflake goes deeper into quotas, model selection, and where the costs actually come from.

Next-gen account replication uses log-based change data capture for cross-region failover, now with 20x faster backups and better SLAs. Snowflake shared a real data point from stage: during a major cloud outage last year, 300 customers failed over automatically to a backup region without manual intervention.

Observe by Snowflake is a Datadog-style monitoring product, but it's still early. This came from Snowflake's Observe acquisition, and neither Ian nor Jeff has seen a working demo or screenshots yet. Given how long some pieces of the earlier Select Star acquisition have taken to fully land, don't expect Observe to ship any faster.

Natoma appears to be a way to securely connect Cowork to the rest of your business ecosystem (Slack, Salesforce, and similar tools) through your existing SSO provider, whether that's Okta or Microsoft. One data point Snowflake shared: over 225 instances of unsanctioned "shadow AI" usage detected per organization on average, meaning employees using tools like ChatGPT or unapproved coding assistants without formal sanction. Jeff's read is that Natoma is likely the mechanism Snowflake uses to plug Cowork into the broader business stack safely, though the public materials don't spell that out explicitly yet.

One more thing, not from Summit itself

Dynamic tables picked up a "frozen period" feature shortly after Summit, letting you tell a dynamic table to never attempt to refresh data before a specific timestamp, including relative expressions like "today minus 30 days." Useful if you need certain historical records to stay untouched regardless of upstream changes.

Where this leaves you

Two patterns show up across almost everything in this recap. First, Snowflake keeps investing in making it cheaper and easier to get data in and out without relying on external vendors: OpenFlow, DataStream, Postgres mirroring, and the zero-copy integrations all point the same direction. Second, nearly everything now routes through Coco or Cowork, which is clearly where the platform is headed as a whole.

If you're managing cost on anything outside of Snowflake, SELECT now supports Databricks in addition to Snowflake, and BigQuery support is coming later this quarter.

If AI cost control on Snowflake is on your radar, especially with per-user quotas and model selection now part of the picture, download The Unofficial AI Cost Optimization Manual for Snowflake. Jeff put it together, and it goes well beyond what we could cover here.

FAQ

What's the difference between Coco and Cowork? Coco (formerly Cortex Code) is built for developers and builders who want to write code, build pipelines, and configure the platform. Cowork (formerly Snowflake Intelligence) is built for business users who want answers to questions, not code to write. Most other Summit announcements run on one or feed into the other.

Is adaptive compute a way to lower Snowflake costs? No. Adaptive compute is designed to improve query performance without manual warehouse-size tuning. Several customers have assumed it's a cost-saving feature, but that's not what it's built for.

What's the difference between Cortex Search and agentic search? Cortex Search returns text snippets and wordy answers pulled from unstructured documents. Agentic search returns a single, deterministic answer, so a question like "how many contracts are dated 2025" comes back with a number instead of a pile of contract excerpts.

Does Snowflake support fine-grained governance on Iceberg tables accessed outside Snowflake? This is still an open question. Snowflake didn't confirm whether row filtering or column masking policies extend to the Iceberg REST catalog for consumers using other engines like Athena. Anyone building a multi-engine architecture on Iceberg should treat this as unresolved rather than assuming Snowflake-level governance carries over automatically.

When is Observe by Snowflake available? It's still early. Observe came out of an acquisition, and no public demo or screenshots were available at the time of this recap.

Does SELECT support platforms outside of Snowflake? Yes. SELECT now supports Databricks in addition to Snowflake, with BigQuery support coming later this quarter.