10 min read

7 Snowflake Summit 2026 launches data engineers should know

Snowflake Summit 2026 was more than its own AI Data Cloud announcements. Here are the Snowflake and ecosystem launches data engineers should know, from Datastream and Horizon Context to RudderAI, dbt, Posit, dltHub, and AtScale.
Snowflake Summit 26

Snowflake Summit 26 ran from June 1 to June 4, 2026, in San Francisco. Most of the obvious coverage went to Snowflake's own announcements, especially the agentic AI pieces. That is understandable. Snowflake had plenty to talk about: CoCo, Horizon Context, Datastream, Cortex updates, Adaptive Compute, CoWork, Iceberg work, and more.

Snowflake Summit 26 opening keynote stage with Sridhar Ramaswamy

But the event was not only a Snowflake product launch week. It was also a launchpad for companies building on, around, or inside the Snowflake AI Data Cloud such as RudderStack, Fivetran, dbt Labs, Posit, dltHub, etc.

That matters for data engineers because most teams do not experience Snowflake as a standalone warehouse. They experience it through the surrounding stack: ingestion tools, transformation frameworks, customer data platforms, data science workbenches, governance catalogs, BI tools, enterprise assistants, and agents that now want access to governed data.

So this article does not try to cover every keynote announcement. Instead, it picks the launches and product updates that say something practical about where the data stack is going after Summit: streaming closer to the warehouse, more shared business context for agents, more AI-assisted data engineering, and more partner tools trying to run natively against Snowflake data.

1. Snowflake Datastream brings Kafka-compatible streaming into Snowflake

The most directly data-engineering announcement from Snowflake was Snowflake Datastream, a fully managed streaming service for Apache Kafka-compatible workloads. Snowflake announced Datastream for private preview, so this is not something every team can turn on immediately.

Snowflake Summit keynote slide showing Datastream routing event data to Iceberg and Snowflake tables

A lot of teams start with Snowflake as the analytics warehouse, then bolt on Kafka, connectors, stream processors, monitoring, and separate access controls once real-time use cases show up. After that, they spend a surprising amount of time keeping the streaming side and the warehouse side consistent.

Datastream is Snowflake's attempt to pull more of that work into the same environment where the data is already governed. If streaming data can land directly in Snowflake tables, teams can apply the same masking policies, access controls, lineage, and audit expectations earlier in the pipeline.

That does not make streaming simple. Data engineers still have to think about ordering, replay behavior, schema changes, latency expectations, and downstream consumers. But it does reduce one common source of architecture sprawl: running a streaming estate next to Snowflake just to get data into Snowflake.

For teams already standardizing on Snowflake, Datastream is the kind of launch that may matter more in production than the flashier AI demos.

2. Horizon Context tries to make agents speak the same business language

Agents are not very useful if each one invents its own meaning for revenue, customer, churn, active user, or pipeline. That is why Snowflake's Horizon Context announcement is worth taking seriously.

Snowflake Summit keynote slide showing Horizon Context collecting, enriching, and activating context for AI and BI

Horizon Context is part of the expanded Snowflake Horizon Catalog. The basic idea is to give AI and BI tools a shared context layer: business definitions, metadata, lineage, governance information, semantic views, and other signals that help systems reason from the same meaning.

This is one of those unglamorous problems that becomes urgent when agents enter the picture. In a demo, the model usually knows which table to query and which definition to use. In a real enterprise account, there may be five versions of the same metric, multiple customer identifiers, old dashboards no one wants to delete, and business rules that live half in SQL and half in people's heads.

Snowflake also announced Semantic Studio and Semantic View Autopilot in this area. The direction is clear: make semantic views easier to create, maintain, and reuse across BI and AI workflows.

For data engineers, the takeaway is a bit boring, but important. AI does not remove the semantic layer. It makes the semantic layer harder to avoid.

3. RudderStack launched RudderAI and Lookout for customer data workflows

RudderStack had one of the more relevant Summit-week partner launches for data teams that work with customer data.

RudderStack session at Snowflake Summit 26 titled Bridging the dev data divide with AI agents

On June 2, RudderStack introduced RudderAI, an agentic layer for the customer data lifecycle. It uses RudderStack's CLI, MCP server, Terraform, and agent skills so teams can work with agents across tracking plans, pipelines, transformations, identity workflows, activation, and governance.

On June 4, RudderStack launched Lookout, an AI-powered analytics and instrumentation workspace. Lookout is meant to sit across the warehouse, instrumentation code, tracking plans, and data infrastructure. It can answer natural-language questions against Snowflake, create dashboards, detect missing or broken instrumentation, review pull requests for tracking-plan issues, and generate instrumentation changes as reviewable PRs.

That is a useful Summit story because it connects the agentic AI theme to a very specific operational problem. Customer data breaks in boring ways: renamed events, missing properties, mobile and web drift, identity joins that do not quite work, dashboards that no longer mean what people think they mean. Agents do not fix that by existing. They need access to the instrumentation layer, the warehouse, and the contracts around the data.

RudderStack's angle is that the customer data layer should become agent-aware without moving customer data out of the warehouse-centered architecture. That fits the broader Snowflake story, but it is not just a Snowflake platform feature. It is a partner product trying to make one messy part of the data stack more operational.

4. dbt Labs and Fivetran are now one company, with dbt Core v2.0 Open Source

One of the biggest ecosystem items landed on Day 1 of Summit. On June 1, Fivetran announced that it had completed its merger with dbt Labs. dbt Labs also published a Summit recap covering dbt Core v2.0, the Fusion runtime, dbt State, and dbt Wizard.

Snowflake Summit hands-on lab on making data AI-ready with Fivetran, Snowflake, and dbt

For data engineers, the merger is interesting because ingestion and transformation have often been separate buying, operating, and debugging surfaces. Fivetran moves data into the warehouse. dbt turns that data into modeled, documented, tested analytics layers. In practice, teams spend a lot of time between those two layers, especially when upstream changes break downstream models.

The dbt announcements point in the same direction. dbt Labs has open-sourced the Fusion runtime as dbt Core v2.0 under Apache 2.0, currently in alpha. dbt State is meant to provide system context across code, warehouse state, and metadata. dbt Wizard is an AI assistant for dbt development.

Mergers take time to become better products, and teams will care about licensing, packaging, pricing, and whether open-source users feel the benefits. But the direction is obvious: the ingestion-to-transformation path is being packaged as a more connected workflow, with AI assistants sitting closer to the metadata and code.

5. Posit brought AI-assisted R and Python data science into Snowflake

Posit used Summit to announce Posit Assistant, an AI agent for data scientists working in Positron that can run within the Snowflake data perimeter. The company also highlighted broader Posit Team Native App updates for Snowflake.

Posit session at Snowflake Summit 26 showing the Posit Team Native App for Snowflake

This is not a generic chatbot sitting next to a notebook. Posit's point is that data scientists should be able to work in R and Python while keeping data, compute, governance, and model access inside the Snowflake boundary. Posit says the Assistant is powered by Snowflake Cortex LLMs and works with the Posit Team Native App.

The surrounding product updates are also worth noting. Posit Connect is now generally available in the Posit Team Native App on the Snowflake Marketplace, so teams can publish Shiny apps, Jupyter notebooks, Quarto documents, Plumber APIs, Streamlit apps, and other data products inside Snowflake. Posit Package Manager is in public preview in the same native app, aimed at governed R and Python package management.

For data engineers, this matters because data science work often becomes a shadow platform. Data gets exported, packages drift, notebooks run somewhere else, and governance becomes a set of exceptions. Posit's Snowflake-native work is trying to keep code-first data science closer to the governed warehouse.

6. dltHub pushed code-first (Python), AI-assisted ingestion into Snowflake

dlt is the open-source Python library for data pipelines. dltHub Pro is the company's agentic data engineering platform around it. The Summit announcement describes developers using AI coding agents such as Claude Code, Cursor, or Codex to find a source, build a pipeline, validate it locally, and deploy it to production.

The company also pointed to its Snowflake Native App for MSSQL, Oracle, MySQL, and PostgreSQL replication. The important part is that replication can run inside the customer's Snowflake account, without a separate external orchestrator.

This sits in a slightly different part of the stack than Fivetran. It is not only about packaged connectors. It is about code-first ingestion for the long tail of APIs, internal systems, legacy databases, and awkward sources that do not always fit cleanly into GUI ETL tools.

That is still real data engineering work. AI can draft a connector, but someone has to validate schema behavior, retries, incremental loading, secrets, cost, and failure modes. dltHub's bet is that more of that work will be generated or assisted by agents, then made production-grade through a platform.

7. AtScale extended Snowflake Semantic Views to Power BI and Excel

AtScale announced at Summit a new Snowflake Semantic Views XMLA Endpoint, powered by AtScale, for extending governed Snowflake metrics to Power BI and Excel. The product is expected to be available in private preview.

AtScale booth on the Snowflake Summit 26 expo floor

This is a very practical semantic-layer announcement. Snowflake Semantic Views are meant to give agents and BI tools shared business definitions. AtScale's role is to make those definitions usable from Microsoft analytics tools through live XMLA access, without copying data, rebuilding metric logic, or turning Excel and Power BI into separate sources of truth.

For data engineers, this matters because semantic consistency often fails at the edge of the warehouse. A team defines a metric in one place, then it gets recreated in a BI model, a spreadsheet, a notebook, and eventually an AI assistant. Every copy becomes another place for drift.

AtScale's Snowflake integration is trying to keep the governed definition in Snowflake while still letting business users work in familiar tools. It is less flashy than a new agent, but it speaks to one of the more important Summit themes: agents and dashboards are only useful if they are grounded in the same meaning.

Snowflake also had a broader launch slate

Datastream and Horizon Context are the two Snowflake announcements that fit this article's data-engineering angle most directly. But they were not the only Snowflake launches.

Snowflake also announced CoCo, formerly Cortex Code, as its AI coding agent for building on Snowflake. It introduced CoWork, formerly Snowflake Intelligence, as the personal agent experience for knowledge workers. OpenAI frontier models became generally available in Cortex AI, and Snowflake expanded its Anthropic partnership across Cortex AI, CoCo, CoWork, Claude Code, and Snowflake Marketplace.

There were also less flashy but important infrastructure announcements: Adaptive Compute for more automatic warehouse scaling and performance tuning, and a broader open interoperability framework around Apache Iceberg, Polaris, external engines, and zero-copy access patterns.

The common thread is that Snowflake wants more of the AI and data engineering loop to happen inside its governance boundary. The question for teams is how much of their existing stack they actually want to move into that boundary, and where independent tools still make more sense.

Other ecosystem launches worth noting

Several other product launches and integrations around Summit point in the same direction, even if they are not as central to the data engineering story.

Dataiku Cobuild on Snowflake was announced before Summit, on May 20, but Dataiku demoed it at the event. Cobuild lets users describe a data or AI project in plain language and turns that intent into an inspectable Dataiku workflow on Snowflake, using Cortex for model calls inside the Snowflake account. Because it was pre-Summit, it should not be framed as a Summit launch, but it was clearly part of the Summit partner story.

Collibra and Snowflake expanded their integration to bring governed business context and semantics across the Snowflake AI Data Cloud. The practical angle is metadata and governance flow: policies, classifications, lineage, and business definitions becoming more available to Snowflake AI and BI workflows.

Glean announced Snowflake in Glean Assistant as generally available on June 2. Employees can ask natural-language questions against Snowflake data from inside Glean Assistant, while Glean combines structured Snowflake results with enterprise context from documents, chats, tickets, and other systems.

ThoughtSpot announced integrations between Spotter, its suite of agents, Snowflake Cortex AI, and Snowflake Semantic Views. The useful part is similar to the AtScale story, but from an analytics-agent direction: semantic definitions and Cortex-powered reasoning are being pulled into the BI workflow rather than living only in Snowflake.

Chalk launched Chalk Compute on June 1, an enterprise agent runtime for running sandboxed agents in a customer's own cloud. It is not a Snowflake-specific launch, but it is relevant to the Summit's agentic data theme because Chalk's context engine connects to production sources including Snowflake, Kafka, Postgres, APIs, and SaaS systems, with an emphasis on point-in-time evaluation and governed agent execution.

Boomi added Snowflake Cortex Agents support to Boomi Agentstudio. This was announced after Summit week, so it should be treated as Summit-adjacent rather than a launch from the event floor. Still, it fits the same pattern: enterprises want a way to govern and orchestrate agents that touch data and SaaS systems.

The broader pattern is more useful than any single announcement. Snowflake is trying to become the governed execution layer for enterprise AI and data workflows. Partners are responding by moving ingestion, transformation, analytics, data science, customer data operations, governance, and enterprise assistants closer to Snowflake.

That does not mean every team should collapse its stack into one platform. It does mean that the old boundaries are shifting. The warehouse is no longer just where data lands after the real work happens elsewhere. Increasingly, it is where the agents, metadata, pipelines, data products, and business workflows want to meet.