In this round-up, we’ve targeted the key announcements for data engineers from Snowflake Summit. The aim is to discuss what each announcement means in practice, where we've already seen these features work, where the gotchas are, and what data leaders should prioritizse in H2 2026.
This round-up has been created by Mike Droog, one of our three Data Superheroes.
Horizon Context: Your Metadata Finally Becomes Useful
Every data team I've talked to in the last year has the same problem.
Your head of sales sees $14.2 million in Q3 revenue. Your CFO sees $12.8 million. Both asked an AI agent the same question this morning. Same data. Different answer. Why? Because "revenue" is defined in three different places, (such as a BI model, a dashboard calculation, and an LLM prompt) and none of them agree.
That's not a model problem. It's a context problem. And it gets worse with every agent you deploy.
Snowflake just built the layer that fixes this.
What was announced
Horizon Context - a native "system of understanding" that connects your data definitions, semantic views, governance policies, and business context into a single layer that other tools (including AI) can actually consume.
What this means in practice
Context objects store business meaning alongside your data - not in a separate catalog, not in a wiki, but in Snowflake itself. When Cortex Agents or CoWork query your data, they can now reference those definitions. "Revenue" means what your business says it means, not what the model inferred from column names.
New Metadata Connectors (private preview) now pull context from PostgreSQL, Microsoft SQL Server, Tableau, Power BI and dbt - collecting schemas, query logs, dashboard definitions and lineage from across your estate into one catalog. OpenLineage API (public preview) lets tools like Apache Airflow send lineage information directly. And Snowflake is leading Open Semantic Interchange (OSI) - an open standard with 54 participating vendors and a published spec for exchanging semantic metadata across tools.
Semantic View Autopilot generates semantic views from existing assets: your SQL queries, Tableau data sources, Power BI models, or OSI-compatible models. New at Summit: Semantic Studio (private preview) - a full AI-assisted IDE in Workspaces with CoCo and Git integration for building semantic views visually. And Advanced Semantics (private preview) brings LOD calculations, composable definitions and user-defined materializations with automatic query rewrite.
The activation layer is what makes this more than another metadata project: CoCo now automatically retrieves relevant context using Universal Search (hybrid keyword + semantic) and automatically discovers and queries relevant semantic views when you ask a data question. Semantic views are also now exposed via MCP - connect from Claude, Cursor or any MCP-compatible agent.
Why this matters for your team
The "which table do I use?" problem gets solved at the platform level, not by pinging the right analyst. Context objects can signal which semantic views are active, which definitions are approved, and which tables are authoritative.
Your existing BI investment becomes a starting point. Have Tableau data sources? Power BI models? Autopilot and the new metadata connectors pull that context in automatically. You're not starting from zero - you're formalizing what's already there.
The BI ecosystem integration is also expanding: beyond Omni, Sigma, Hex and Tableau, Snowflake is adding Power BI and Excel (private preview soon), ThoughtSpot (early access), and Looker from Google Cloud (preview). Semantic views become the governed layer that every tool reads from.
The governance implication is also worth naming: because Horizon Context is native to the Snowflake engine, RBAC and row-level masking follow the context. A definition restricted for the finance team stays restricted in Power BI, in Salesforce, and in any agent that queries it. That's what separates this from third-party semantic layers bolted on top.
Mike's hands-on experience with Autopilot
The demo I saw was genuinely impressive. Point it at existing SQL queries or BI data sources and it proposes a semantic view with dimensions, measures, and relationships inferred from your usage history. It's not perfect out of the box - you still need human review - but it eliminates the cold-start problem that kills most semantic layer projects. Most teams don't fail at semantic layers because of the technology. They fail because building from scratch is painful and nobody has time for it.
The Power BI model import (currently private preview) is particularly interesting for shops that have invested heavily in Power BI measures and want to bring that logic into Snowflake's native semantic layer without rebuilding it by hand.
What to do about it
If you have existing BI or semantic investments, prepare an inventory of your Tableau data sources and Power BI models. These become inputs to Autopilot. Then identify your three to five most critical business concepts - Revenue, Customer, Active User - and plan to define them as context objects.
If you're deploying AI agents, this needs to come before you build more agents. Without context, agents hallucinate business definitions. With context, they reference your approved logic. Prioritize it.
If you're a CDO thinking about data strategy, the frame that lands with boards is "making our data self-describing." The goal: any tool, human, or agent that touches your data knows what it means without having to ask someone.
Snowflake Datastream: Kafka-Compatible Streaming, Built Into Snowflake
Every data team I know has two stacks: the batch stack (Snowflake, dbt, orchestrators) and the streaming stack (Kafka, Flink, Spark Streaming, Confluent). They live in different worlds. Different infrastructure. Different teams. Different budgets.
The streaming stack is powerful, but it's also the thing that wakes your on-call engineer at 3am. Managing Kafka clusters, Schema Registry, consumer groups, partition rebalancing, connector configs... it's a full-time job for a full team.
Snowflake just announced they're collapsing that gap.
What was announced
Snowflake Datastream — a fully managed streaming service built directly into Snowflake. Kafka-compatible. No separate infrastructure. Private preview starting shortly.
Read that again: Kafka-compatible streaming as a native Snowflake service. Not a connector to Kafka. Not a Kafka-to-Snowflake pipe. An actual streaming layer that speaks the Kafka protocol, managed entirely by Snowflake.
Why this is a big deal
- You can eliminate an entire infrastructure layer. If you're running Kafka primarily to get data into Snowflake (which is the majority use case for most data teams), you may no longer need to manage Kafka at all. Datastream handles the ingestion natively.
- Kafka compatibility means zero rewrite. Your existing producers (apps, services, IoT devices, etc) that speak the Kafka protocol can point at Datastream without code changes. Same API. Same protocol. Different, simpler backend.
- One fewer team to staff. Kafka operations is a specialization, that includes cluster management, partition tuning, consumer lag monitoring, and Schema Registry maintenance. That's 1-3 FTEs for a mid-size org. If Snowflake manages the streaming layer, those people can work on higher-value problems.
- The batch-streaming divide starts to blur. If your streaming layer and your analytical layer are the same platform, the "how do I get streaming data into my warehouse" question disappears. Data lands in Snowflake as it arrives. No staging. No intermediate storage. No Kafka Connect configs.
What we know so far
- Fully managed — no cluster provisioning, no partition management, no infrastructure tuning
- Kafka-compatible — existing Kafka producers can connect without rewriting
- Private Preview starting shortly after Summit (not GA yet)
- Built natively into Snowflake — not a separate service, not an acquisition bolted on
What to watch for (honest caveats)
- This is Private Preview. Not Public Preview. Not GA. That means limited availability, likely invite-only, and production readiness is likely months away.
- "Kafka-compatible" can mean different things. These details will determine whether this replaces Kafka or supplements it. Key questions include:
- Which Kafka API version?
- Does it support exactly-once semantics?
- What about Schema Registry?
- Consumer groups?
- The pricing model is unknown. Streaming workloads are continuous and high-volume. The credit consumption model will make or break adoption.
- If you're using Kafka for use cases beyond Snowflake ingestion (event sourcing, microservice communication, real-time ML features), Datastream likely doesn't replace those. It replaces Kafka-as-a-data-pipe, not Kafka-as-an-event-backbone.
What to do about it
If you're running Kafka primarily for Snowflake ingestion:
→ Get on the Private Preview waitlist. This is potentially the highest-ROI simplification you can make in your stack. → Inventory your Kafka topics that feed into Snowflake. These are your migration candidates.
If you're evaluating streaming architectures:
→ Pause any new Kafka infrastructure investments that are primarily about Snowflake ingestion. Wait to see Datastream's GA timeline and capabilities. → Continue investing in Kafka for non-Snowflake use cases (microservices, event-driven architecture).
If you're a data leader building a business case:
→ Calculate your current Kafka TCO for Snowflake-bound data: infrastructure, staff, Confluent licensing. That's the number Datastream competes against.
Snowsight Pipeline Builder: You Can Finally Show People What Your Pipeline Looks Like
I've been in too many meetings where someone asks "can you show me how the data flows?" and the answer is... a whiteboard drawing. Or a dbt DAG that nobody outside the data team can parse. Or worse: "let me walk you through the code."
The pipeline exists in your head. Maybe in your team's heads. But it's not visible to anyone else. And when someone new joins, or something breaks at 2am, or your VP asks "what would be affected if we changed the source system?", the answer requires archaeology.
What was announced
Snowsight Pipeline Builder. A visual representation of your data pipeline, directly in Snowsight. Now in Private Preview.
Sources, transformations, targets, and the relationships between them, all rendered as a graph that you can look at instead of tracing through SQL files.
Why this matters more than it sounds
The flashy Summit announcements get the attention. A visual pipeline tool doesn't make anyone's top 5 "most exciting" list. But in terms of daily utility for data teams, this might be more impactful than half the AI announcements.
Onboarding is where it hits hardest. Right now, a new engineer joins your team and spends weeks understanding how data flows. "Read the dbt project" is not onboarding, it's a hazing ritual. A visual graph doesn't replace understanding the code, but it gives you the map before you start exploring the territory.
Debugging gets faster too. When something breaks, the first question is always "what's downstream of this?". A visual graph gives you that answer in a glance instead of grep-ing through dependency files.
And for stakeholder communication, when your VP asks "what's our pipeline?", you can show them a picture instead of attempting to explain DAGs to someone who doesn't know what a DAG is.
The caveats
It's Private Preview. Rough edges are expected. I don't yet know which pipeline types it supports; Dynamic Tables, Tasks, Streams, dbt models? The scope of what's visualized will determine whether this replaces your existing lineage tooling or supplements it.
If you already have Atlan or Monte Carlo or dbt docs doing this for you, Pipeline Builder might be redundant. But if you don't, or you want something native that doesn't require a separate vendor, this fills a real gap.
What we recommend
Get on the waitlist. Even in early form, having visual pipeline representation inside Snowsight (where you're already working) removes a context switch. And if you're hiring soon, having a visual pipeline map will save your new engineers weeks of confusion.
Mike Droog is a Data Superhero and Solution Architect at Aimpoint Digital, a Snowflake partner helping teams build and manage production data pipelines. If your team needs help designing observable, maintainable pipelines on Snowflake, we can help.
