Coder Legion - Recent posts tagged snowflake

Ask Your Snowflake Account Anything — Build an AI Admin Agent with Cortex + GitHub Copilot ( Part 1 )

Mon, 07 Sep 2026 05:46:43 +0000

TL;DR — Spin up a Snowflake Cortex Agent that can answer admin questions like "Which warehouses burned the most credits last month?" or "Who are my top 5 spenders?" — all from a natural-language prompt inside GitHub Copilot Chat.

The Problem

Snowflake ACCOUNT_USAGE contains everything you need to understand spend, performance, and security. The catch? You have to know the right table, the right join, and write it correctly every time.

What if you could just ask?

What You'll Build

GitHub Copilot Chat
      │  (natural language)
      ▼
MCP Server (Python, local)
      │  ask_admin tool
      ▼
Snowflake Cortex Agent
      │  routes to the right semantic view
      ▼
SNOWFLAKE.ACCOUNT_USAGE (+ optional ORGANIZATION_USAGE)

By the end you'll be able to type questions like these into Copilot Chat and get back answers with real numbers:

What are total compute credits by warehouse in the last 30 days?
Which users consumed the most credits this month?
How many failed logins occurred in the last 7 days?
What are serverless credits by service type?

Prerequisites

Requirement	Notes
Snowflake account (any paid edition)	`ACCOUNTADMIN` or a role with `ACCOUNT_USAGE` access
Python 3.9+	For the MCP bridge
VS Code + GitHub Copilot Chat	Agent mode enabled
Git	To clone the template

Step 1 — Clone the Template

git clone https://github.com/LALITHASWAROOPK/agent_snowflake_admin_assistant.git
cd agent_snowflake_admin_assistant/agent_snowflake_admin

Open the folder in VS Code:

code .

Step 2 — Deploy the SQL Objects (5 scripts, ~5 minutes)

All SQL is in the sql/ folder. Replace the four placeholders before running:

Placeholder	What to set
`<APP_DB>`	A database to hold your views/agent
`<APP_SCHEMA>`	Schema inside that database
`<ADMIN_ROLE>`	Role that owns the objects
`<DEVELOPER_ROLE>`	Role that will query the agent
`<EXEC_WAREHOUSE>`	Warehouse the agent will use at runtime

Run them in order in a Snowflake worksheet or SnowSQL:

@sql/01_create_views.sql        -- Base views over ACCOUNT_USAGE
@sql/02_create_semantic_views.sql  -- Semantic layer (natural-language metadata)
@sql/03_create_agent.sql        -- Cortex Agent wired to those views
@sql/04_create_budget.sql       -- Optional: spending guardrails
@sql/05_grants.sql              -- RBAC grants

What the Views Cover

01_create_views.sql builds seven base views, all sourced exclusively from SNOWFLAKE.ACCOUNT_USAGE — no custom tables, no proprietary schemas:

View	Source
`V_WAREHOUSE_COST_BY_TAG`	`WAREHOUSE_METERING_HISTORY` + `TAG_REFERENCES`
`V_QUERY_PERFORMANCE`	`QUERY_HISTORY`
`V_USER_SPEND`	`QUERY_ATTRIBUTION_HISTORY`
`V_SERVERLESS_COSTS`	Tasks, pipes, clustering, search, MV refresh
`V_STORAGE_USAGE`	`STORAGE_USAGE` + `DATABASE_STORAGE_USAGE_HISTORY`
`V_LOGIN_HISTORY`	`LOGIN_HISTORY`
`V_DATA_TRANSFER`	`DATA_TRANSFER_HISTORY` + `REPLICATION_USAGE_HISTORY`

02_create_semantic_views.sql wraps each base view with a COMMENT block that tells the Cortex Agent what the view is for — this is how the agent knows which view to query for any given question.

Why Semantic Views?

Snowflake Cortex Agents use semantic views as tool definitions. A semantic view is just a standard view with a COMMENT that describes its purpose in natural language. The agent reads those comments at inference time to decide which tool (view) answers the user's question.

No prompt engineering required on your end.

Step 3 — Start the MCP Bridge

The MCP (Model Context Protocol) server is a lightweight Python HTTP server that exposes one tool — ask_admin — which Copilot Chat can call.

Install dependencies

pip install -r mcp/requirements.txt

Configure your environment

Create a .env file in the repo root (never commit this):

SNOWFLAKE_ACCOUNT=<your_account>
SNOWFLAKE_USER=<your_user>
SNOWFLAKE_AUTHENTICATOR=externalbrowser
SNOWFLAKE_ROLE=<DEVELOPER_ROLE>
SNOWFLAKE_WAREHOUSE=<EXEC_WAREHOUSE>
SNOWFLAKE_AGENT_FQN=<APP_DB>.<APP_SCHEMA>.<AGENT_NAME>
MCP_PORT=3000

Supports externalbrowser (SSO), snowflake (password), and OAuth — set SNOWFLAKE_AUTHENTICATOR and the matching credential variable.

Launch the server

./scripts/start-mcp.ps1

Or directly:

python mcp/server.py

Verify it's up:

Invoke-RestMethod -Uri http://127.0.0.1:3000/health -Method Get
# → {"status":"ok"}

Step 4 — Connect Copilot Chat

The repo ships a pre-configured .vscode/mcp.json that wires the local MCP server into VS Code:

{
  "mcpServers": {
    "snowflake-admin": {
      "url": "http://127.0.0.1:3000"
    }
  }
}

VS Code picks this up automatically when you open the workspace. You'll see the ask_admin tool listed inside Copilot Chat's tool picker.

There's also a GitHub Copilot instruction file at .github/instructions/admin.instructions.md which gives Copilot context about the agent's scope so it routes questions there automatically.

Step 5 — Ask It Questions

Switch Copilot Chat to Agent mode and try:

What are my top 5 warehouses by compute credits in the last 30 days?

Which users have spent the most credits this month?

Show me failed logins by user in the last 7 days.

What serverless services are costing me the most right now?

What's my current storage usage broken down by database?

The agent selects the right semantic view, runs the query, and returns a plain-English answer with the numbers inline — no SQL, no context switching.

Optional: Budget Guardrails

04_create_budget.sql sets up a Snowflake Budget object so you can enforce credit limits at the agent level. Handy for keeping a shared admin agent from running runaway queries:

CALL <APP_DB>.<APP_SCHEMA>.<BUDGET_NAME>!SET_SPENDING_LIMIT(100);
CALL <APP_DB>.<APP_SCHEMA>.<BUDGET_NAME>!GET_SPENDING_HISTORY();

Architecture Recap

┌─────────────────────────────────────┐
│         GitHub Copilot Chat         │
│      (Agent mode + ask_admin tool)  │
└────────────────┬────────────────────┘
                 │ HTTP / MCP
┌────────────────▼────────────────────┐
│      MCP Bridge  (mcp/server.py)    │
│  Exposes: /mcp/tools/list           │
│           /mcp/tools/call           │
│           /health                   │
└────────────────┬────────────────────┘
                 │ snowflake-connector-python
┌────────────────▼────────────────────┐
│   SNOWFLAKE.CORTEX.DATA_AGENT_RUN   │
│   ← Cortex Agent (semantic router)  │
└────────────────┬────────────────────┘
                 │ picks the right tool
┌────────────────▼────────────────────┐
│     Semantic Views (SV_*)           │
│     Base Views    (V_*)             │
│     ↑ SNOWFLAKE.ACCOUNT_USAGE       │
└─────────────────────────────────────┘

Key Things to Know

Account Usage latency: SNOWFLAKE.ACCOUNT_USAGE is typically delayed by up to a few hours — not real-time.
Rate sheet: ORGANIZATION_USAGE.RATE_SHEET_DAILY is optional and depends on your edition/region.
Auth flexibility: The MCP server supports SSO (externalbrowser), OAuth, and password auth — configure once in .env.

Get the Code

github.com/LALITHASWAROOPK/agent_snowflake_admin_assistant

PRs and issues welcome. If you build on top of this, tag me — I'd love to see what you add.

Moving Data Is Easier Than Moving Knowledge

Mon, 07 Sep 2026 05:45:44 +0000

This is Part 1 of a two-part technical series. Rupak's article on building AI-ready data products describes the larger destination: a machine-readable context layer, governed semantics, and engineering guardrails. This post tackles the migration problem that comes first—recovering legacy knowledge and turning it into grounded SQL. Part 2 will cover natural-language questions, governed execution, and explained answers.

All examples and names below are synthetic

Moving data is often the easier part of an SAP-to-cloud migration. Moving the knowledge is harder.

A pipeline can copy a table. It does not automatically carry forward why two tables are joined, which filter defines an open order, how technical statuses become business terms, or who owns the report.

Without that context, a new platform can produce a technically valid answer that is wrong for the business.

A question the copied tables cannot answer

Imagine an estate with more than 5,000 SAP HANA calculation views, hundreds of Qlik and Spotfire applications, and more than 2,500 cloud tables.

A data engineer receives a simple request:

Rebuild our sales-order backlog dashboard. What existing logic should I preserve?

The answer is scattered. A HANA calculation view may define the joins, filters, and open quantity. A Qlik application may map technical statuses and write a shared QVD. A Spotfire analysis may implement its own aging logic. Ownership and downstream usage may live in reporting metadata, while field-level dependencies live in a lineage graph.

Qlik and Spotfire are parallel reporting platforms over HANA. They are not sequential stages feeding one another; the same HANA model may support applications in either or both.

The migration task is therefore not just code conversion. It is evidence discovery.

How the assistant builds context

We call the user experience an Enterprise Data Discovery Assistant. Under the hood, a bounded Snowflake Cortex Agent selects retrieval and analysis tools. “Agent” describes the architecture; “assistant” describes its read-only responsibility. It does not change source systems, deploy code, or promote pipelines.

Engineer question
       |
       v
Enterprise Data Discovery Assistant
       |
       +-- HANA repository code
       +-- Parallel BI artifacts
       |      +-- Qlik scripts and QVDs
       |      +-- Spotfire queries and metadata
       +-- Reporting metadata catalog
       +-- Schema, object, and column lineage
       |
       v
Recovered logic + ownership + dependencies
       |
       v
Grounded SQL draft -> data-engineer validation

The four evidence layers play different roles:

HANA repository code provides the calculation-view definition. Parsing indexed .hdbcalculationview XML reveals sources, joins, filters, calculated columns, unions, and nested-view dependencies.
Parallel BI artifacts reveal reporting logic. Qlik contributes load queries, aliases, mappings, resident loads, and QVD flow. Spotfire contributes source queries, columns, and any calculations present in its indexed metadata or exports.
The reporting metadata catalog connects Qlik and Spotfire applications to HANA models, queries, fields, owners, paths, saved-query details, and comments. It adds operational context around the code; it does not replace the code.
Schema and lineage metadata traces upstream sources, downstream consumers, object dependencies, and column paths, then helps map recovered logic to approved target objects.

Together, these sources answer more than “What SQL should I write?” They can also answer: Who owns this dashboard? Which reports use this HANA view? Which QVDs feed the application? What could break if the model changes?

Search locates the artifacts. Deterministic parsers extract their structure. The language model relates the findings to the engineer's question.

From a question to grounded SQL

The experience should feel like a conversation, not a metadata report. The engineer asks one question; the assistant shows what it checked and returns an evidence-backed answer with SQL.

Synthetic chat demonstration: no production data or internal interface is shown.

The response separates recovered facts from the proposed target design. In this example, the assistant verifies the HANA joins and filter, recovers the Qlik status mapping and QVD flow, identifies the owner, and finds downstream Qlik and Spotfire consumers before drafting SQL.

Only then does the assistant propose a starting point:

SELECT
    i.order_id,
    i.ordered_qty - i.confirmed_qty AS open_quantity,
    s.business_status
FROM sales_order_item AS i
LEFT JOIN status_map AS s
    ON i.status_code = s.status_code
WHERE i.cancelled_flag = 'N';

The SQL is useful because its origin and limitations are visible—not because it appeared quickly.

Grounded SQL is a handoff

The draft is not a production pipeline. A data engineer still confirms the grain, compares results with the legacy report, maps the logic to canonical target names, and preserves null, fallback, and refresh behavior. Production work also requires incremental patterns such as CDC or watermarks, data-quality tests, security, documentation, owner approval, and CI/CD which was covered in Developer Toolkit.

Trust comes from a few explicit boundaries:

Prefer exact identifiers when available; use semantic search for discovery, then verify the selected objects.
Parse large HANA XML and Qlik scripts deterministically.
Separate verified evidence, proposed design, and missing evidence.
Keep generated code read-only until it passes normal engineering review and testing.

If an expected Qlik or Spotfire expression is absent from the indexed sources, the assistant says so instead of reconstructing it from assumptions.

The same human-in-the-loop pattern shaped the assistant itself. Snowflake CoCo,supported the build-and-tune cycle by helping refine tool instructions, test prompts, failure analysis, and response behavior. Engineers decided which changes to adopt and validated the results.

Moving data gives a new platform rows and columns. Moving knowledge preserves the meaning, ownership, and dependencies people rely on—and provides the context needed to build governed data products.

Part 2 will follow a natural-language question through governed SQL execution and show how the final answer explains its sources and limitations.

Snowflake Summit 26: What Developers, Engineers, and Architects Need to Know

Tue, 02 Jun 2026 13:00:00 +0000

Snowflake's biggest user conference yet kicked off June 1 in San Francisco, and the company arrived with a full slate of product announcements aimed squarely at builders. Here's what matters most if you're writing code, managing data infrastructure, or designing systems on Snowflake.

First, Two New Names

Before getting into the announcements, note two product rebranding moves. Cortex Code is now officially Snowflake Coco. The informal name had already taken hold with customers, so Snowflake made it official. Snowflake Intelligence is now Snowflake Cowork — a rename that reflects how the product has grown from a next-gen BI tool into a broader productivity platform for knowledge workers.

Coco Gets a Lot More Surface Area

The biggest news for developers is how many places Coco now lives. Snowflake is introducing a VS Code extension, an Excel plugin, Slack integration, and a standalone Coco Desktop app. Claude Code support is also on the list — useful for any team already using Anthropic's CLI in their workflow.

On the capability side, Coco can now handle long-running autonomous tasks via Cloud Agents, create reusable workflows through Skills, and support automations for recurring monitoring and validation tasks. New integrations with Retool, Superblocks, and Vercel let developers turn a prompt into a deployed app on Snowflake's App Runtime.

Bala Kasiviswanathan, Snowflake's VP of Developer and AI Experiences, framed the shift this way: "A year ago, building on enterprise data meant writing code, managing infrastructure, and stitching together disconnected tools for orchestration, streaming, governance, and deployment. Today, Snowflake CoCo is collapsing that complexity into a single AI-native development experience."

CEO Sridhar Ramaswamy added that Coco can already outperform frontier models on operations within Snowflake, and that partners are shifting from time-and-material billing to outcome-based engagements because of it.

The customer numbers are concrete. Fanatics reduced pipeline troubleshooting from days to hours. Thomson Reuters modernized legacy systems and delivered insights in days instead of weeks across more than 37,500 governed tables.

Coco also works across data sources beyond Snowflake — including AWS Glue, dbt, Apache Airflow, Databricks, and Postgres.

Snowflake Datastream: Managed Streaming, Built In

For data engineers managing streaming infrastructure, Snowflake introduced Datastream — a fully managed, Kafka wire protocol compatible streaming service built natively into the platform. Existing Kafka clients and applications can point to it without rewriting integrations. Under the hood, it's pure Snowflake technology, not a Kafka wrapper.

The practical appeal: streaming data routes directly into Snowflake tables with low latency, and it automatically inherits existing governance, access controls, masking policies, and lineage. No separate broker to manage. Datastream enters private preview shortly after Summit.

Apache Iceberg v3 Goes GA — and Open Data Gets Serious

Snowflake announced several moves on the open data front. Apache Iceberg v3 support is now generally available, with the broadest feature set on the market — expanded data types, cross-system change tracking, and improved semi-structured data performance.

Snowflake Storage for Apache Iceberg Tables is also GA, with bi-directional read/write access to Snowflake-managed Iceberg tables from external engines via Horizon Catalog, powered by Apache Polaris. The Iceberg REST Scan Plan API ensures security and masking policies travel with data even when accessed by external tools.

Zero-copy integrations for SAP, Salesforce, and Workday mean direct access to that data without replication. The architectural goal: work on a single, governed copy of data wherever it lives, without moving it.

Two new context layers sit on top of all of this. Horizon Context brings in explicit, customer-defined metadata — including from the Select Star acquisition, which ingests metadata from Postgres, SQL Server, Tableau, and Power BI. Cortex Sense builds implicit context automatically from usage patterns, feeding both Coco and Cowork without requiring manual configuration.

Natoma Acquisition: Governing What Agents Actually Do

This is the announcement that architects should pay the most attention to. Snowflake announced its intent to acquire Natoma, an enterprise Model Context Protocol (MCP) platform. The significance: Natoma extends governance beyond data access to cover AI agent actions — sending emails, summarizing Slack threads, updating Jira tickets, checking calendars — all from within Snowflake's governed environment with policy enforcement and full audit trails.

For anyone designing agentic systems, this signals where Snowflake is heading. The goal is to be the control plane not just for what data agents can see, but for what they can do across enterprise systems.

AI Security: Three New Layers

Four security announcements are worth noting for teams building agentic workloads:

Agent Identity gives every agent a verified identity with role-based permissions and a full audit trail. Prompt Injection Protection uses ML-driven detection to block jailbreak attempts. The Trust Center is getting an AI security package with codified best practices for agent configuration, credential usage, and data access. And multi-party authorization requires a second approver for sensitive operations — protecting against both insider threats and runaway agents.

A Few More Things Worth Noting

Snowflake Apps now supports native React development alongside AI-powered workflows, moving from prompt to a production-ready app deployed inside the security perimeter.

Adaptive Compute goes GA at Summit. It automatically determines the right mix of compute resources in real time — no manual warehouse sizing — with reported gains of up to 3.5x over first-generation warehouses.

Cowork is adding automations, background agents, and a next-generation artifacts and dashboards layer. For architects: Cowork is the governed, managed experience for everyone in the organization. Coco is the power tool for technical users who know what they're doing.

How to Handle NULLs in Snowflake: A Complete Guide!

Tue, 07 Apr 2026 14:39:38 +0000

Dear Readers,

NULL in data is like a weed, it can mess up your analysis and calculations, and ultimately bleed the value out of your analytics work. In this article, we’ll dive into what NULL is, why it exists, when it appears, and how to deal with it in Snowflake ?

So, without further ado, let’s meet this culprit.

What NULL?

In SQL, NULL is basically the database equivalent of a shrug.It is a special marker that represents a missing or unknown value. It's not the same as an empty string ('') or the number zero (0). It simply means “I don’t know” or “there’s no value here at all.”

Why NULL Exists?

NULL is essential because sometimes your data just doesn’t exist yet, or never will. NULL allows the database to acknowledge the gap without faking a value.

Eg:

A customer doesn’t have a middle name.
A product doesn’t have a discount yet.
A delivery date is unknown at the time of record insertion.

When NULL Appears?

NULL occurs anytime there is a lack of value from the user.

Common reasons include:

Optional fields with no provided value.
Data not yet available (future delivery dates, pending approvals)
Inapplicable values (someone’s “date of divorce” who never married)

How to Deal with NULL in Snowflake?

Snowflake provides multiple functions and methods to deal with NULL dataset aka unknown data similar to other databases. I have listed some of them below:

Use IS NULL / IS NOT NULL to identify the NULL data.
Use COALESCE(col, default) or IFNULL(col, default) to replace them in select , joins, aggregates etc
Use explicit filter on WHERE clauses to include NULL rows as it can can drop NULL rows unexpectedly.
Use NVL, CASE WHEN, or similar functions to handle them in calculations or strings.
Comparisons with NULL return UNKNOWN in SQL’s three-valued logic. Use COALESCE or IS NULL checks to avoid surprises.

Eg:

==Using NULL/NOT NULL

-- Finds all employees without a manager
SELECT name FROM employees WHERE manager_id IS NULL;

-- Finds all employees with a manager
SELECT name FROM employees WHERE manager_id IS NOT NULL;

==Using COALESCE

-- Calculates total compensation, treating a NULL bonus as 0

SELECT salary + COALESCE(bonus, 0) AS total_compensation FROM employees

The Trouble NULL Causes:

1. Comparison Traps

NULL comparisons are a common pitfall because standard operators like = or != don’t work as expected. Any comparison involving NULL returns UNKNOWN, not TRUE or FALSE. Use IS NULL or IS NOT NULL to handle the traps.

Eg:

--Evaluates to UNKNOWN when NULL = NULL

SELECT *
FROM employees
WHERE manager_id = NULL;

-- The correct way to find employees with a NULL manager_id is:
SELECT *
FROM employees
WHERE manager_id IS NULL;

2. Math & Concatenation Failures:

NULL acts like a virus in arithmetic and string concatenation operations. Any operation involving NULL will result in NULL.

Eg:

--Return of NULL total+compensation when bonus is NULL:

SELECT salary + bonus AS total_compensation
FROM employees;

--The correct way to add bonus is use COALESCE :

SELECT salary + COALESCE(bonus, 0) AS total_compensation
FROM employees;

3. Aggregate Surprises:

Aggregate functions like SUM() and AVG() ignore NULL values. This can lead to misleading results if you’re not aware of it.

Eg:

--Excludes NULL rows

SELECT AVG(salary) AS avg_salary, SUM(salary) AS total_salary
FROM employees;

--Use COALESCE to treat NULL salaries as 0 to get more accurate company-wide average

SELECT AVG(COALESCE(salary, 0)) FROM employees;

4. Join Issues:

NULL values in join keys never match each other. If an employee has a NULL in manager_id, that row won’t link to any id in the employees table even if other employees also have NULL as manager_id.

Use a LEFT JOIN + COALESCE to tackle the NULL issue.In following demonstrated way, you keep all employees in the output, and NULL managers are clearly labeled without risking false matches.

Eg:

--This INNER JOIN excludes employees with no manager_id

SELECT

   E.name AS employee,
   M.name AS manager

FROM employees AS E
INNER JOIN
employees AS M
ON E.manager_id = M.id;

--Use COALESCE to include employees without a manager

SELECT
E.name AS employee,
COALESCE(M.name, 'No Manager') AS manager
FROM employees E
LEFT JOIN employees M
ON E.manager_id = M.id;

5.Logic Surprises

In SQL’s three-valued logic (TRUE, FALSE, UNKNOWN), an UNKNOWN result in a WHERE clause acts like FALSE and discards the row. However, UNKNOWN can have different effects in other clauses such as CASE.

Eg:

--Logic Mishandling for NULL data.

SELECT
CASE

WHEN bonus > 10000 THEN 'High Bonus'
WHEN bonus > 5000 THEN 'Mid Bonus'
ELSE 'Low or No Bonus'

END AS bonus_category
FROM employees;

-- Explicitly checks for NULL first

SELECT
CASE

WHEN bonus IS NULL THEN 'No Bonus'
WHEN bonus > 10000 THEN 'High Bonus'
WHEN bonus > 5000 THEN 'Mid Bonus'
ELSE 'Low Bonus'

END AS bonus_category
FROM employees;
Closing thoughts,

NULLs aren’t a bug, they’re part of SQL’s design.NULL is tricky. The safest approach is to scan your dataset for every attribute that could be NULL, then apply handling strategies suited to your business context. In Snowflake, a few well-placed COALESCE, IS NULL, and CASE statements can save you from major data quality headaches.

Hope you enjoyed the article! If you like my writing, feel free to connect with me on Linkedin and follow for more such interesting reads.

Snowflake Brings Google's Gemini 3 Models to Its Data Platform

Tue, 06 Jan 2026 19:18:31 +0000

Snowflake announced today that Google's Gemini 3 models are now running natively inside Snowflake Cortex AI. This means enterprises can use Google's latest AI models on their data without copying or moving it to another platform.

The integration includes both Gemini 3 Pro and Gemini Flash 2.5, available now in public preview through Cortex AI Functions. Support for Snowflake Intelligence and Cortex Agents is coming soon.

What This Solves

Moving enterprise data between platforms creates security risks, compliance headaches, and performance bottlenecks. By running Gemini models directly in Snowflake's governed environment, companies can build AI applications where their data already lives.

Gemini 3 Pro handles complex tasks that require deep reasoning across financial records, logs, product data, and documents. It's designed for production AI agents that need to understand context and make decisions based on structured and unstructured data.

Gemini Flash 2.5 focuses on speed and cost efficiency. It handles high-volume tasks like call summarization, invoice processing, and customer service interactions where you need fast results at scale.

How It Works

Developers can access Gemini models using SQL through Cortex AI Functions. Here's an example of analyzing financial documents:

SELECT 
    SNOWFLAKE.CORTEX.AI_COMPLETE(
        'gemini-3-pro',
        PROMPT(
            'Review the following financial filing and summarize key revenue trends, margin changes, and risk factors: {0}',
            filing_text
        )
    ) AS financial_summary
FROM financial_documents;

The models support cross-region inference, so you can run them across all supported clouds by enabling GCP_US or ANY_REGION in your admin settings.

Real-World Use Cases

BlackLine is using Gemini models embedded in Snowflake to build agentic AI for finance and accounting teams. Jeremy Ung, BlackLine's CTO, says they're moving beyond simple automation to create AI that actively partners with financial professionals on complex processes.

Fivetran CEO George Fraser notes that tasks that used to take weeks of custom development now happen in days. Teams can ask questions and get answers from their business data without building custom integrations.

Broader Partnership

This announcement deepens the relationship between Snowflake and Google Cloud beyond just AI models. The companies are aligning their sales teams, expanding product integrations, and making Snowflake available through Google Cloud Marketplace.

Snowflake is also expanding its Google Cloud footprint. It recently launched in Saudi Arabia and will launch in Melbourne, Australia in early 2026.

The integration includes connections to Google Cloud's Vertex AI platform and BigQuery, giving customers more options for how they build and deploy AI applications.

What Developers Should Know

Gemini joins other models from Anthropic, Meta, and OpenAI already available in Cortex AI. This gives teams flexibility to choose the right model for each task without changing their data architecture.

The focus on running models inside Snowflake's governance perimeter means you maintain security controls while experimenting with different AI capabilities. You're not trading off between innovation and compliance.

[Christian Kleinerman][1], Snowflake's EVP of Product, puts it simply: "By combining Google Cloud's industry leadership with Snowflake's ability to bring AI directly to enterprise data, we're empowering customers to move faster, innovate more freely and redefine what's possible through data and AI."

For organizations already running on Snowflake and Google Cloud, this reduces the complexity of adding AI capabilities to existing data workflows. For those evaluating platforms, it's another data point in favor of keeping your data stack consolidated.



  [1]: https://www.linkedin.com/in/christian-kleinerman-a973102/

SAP partnered with its competitors to let customers choose their data platform. That's not weakness.

Wed, 05 Nov 2025 22:59:30 +0000

SAP's Data Strategy: Why the Snowflake Partnership Makes More Sense Than It Seems

The Partnership Nobody Expected

SAP announced a partnership with Snowflake at TechEd 2025. The announcement included a new "SAP Snowflake" solution extension that brings Snowflake's data and AI capabilities to SAP customers.

The immediate reaction from the analyst community: why would SAP do this? They already have SAP HANA Cloud. They already have SAP Datasphere. Why partner with a competitor?

Muhammad Alam's answer in the post-keynote Q&A session cut through the confusion: "What customers want from us is optionality."

That word, "optionality." reveals SAP's entire data strategy.

What SAP Actually Built

SAP Business Data Cloud is not a data warehouse. It's a data fabric architecture.

The distinction matters. A data warehouse consolidates data in one location. A data fabric connects data wherever it lives while maintaining business semantics, the business meaning and relationships in the data.

Alam explained it in the keynote: "Every intelligent application starts with trusted data. SAP is giving developers more ways to put that data to work through SAP Business Data Cloud."

The technical implementation has three layers:

Layer 1: Data Products

Data products are SAP's key abstraction. They package raw data with metadata, business semantics, and governance rules into reusable assets.

The new Data Product Studio (general availability planned H1 2026) gives developers a visual workspace to model, configure, and manage custom data products across SAP and third-party sources.

Developers can turn raw data into ready-to-use assets known as data products that support analytics, AI and application development.

Layer 2: Business Data Cloud Connect

This is where the partner integrations happen. Business Data Cloud Connect enables secure, zero-copy sharing of SAP's data products into customers' existing data lakes and platforms.

The key technical feature: data stays in its original location. No ETL pipelines. No data duplication. Data products are published into partner catalogs with business semantics intact.

Layer 3: Partner Compute Platforms

This is where Snowflake, Databricks, Google BigQuery, and Microsoft Fabric come in. They provide compute infrastructure for analytics and AI workloads.

The architecture: SAP provides data semantics and governance. Partners provide compute and storage. Customers use both.

The Snowflake Integration Specifically

SAP Business Data Cloud Connect for Snowflake does two things:

Outbound: Publishes SAP data products directly into the Snowflake Horizon catalog. Business semantics, lineage, and governance from SAP Business Data Cloud are preserved. Users working in Snowflake see SAP data with full business context.

Inbound: Exposes Snowflake data products within the SAP Business Data Cloud catalog. SAP applications and agents can access Snowflake data through standardized data products.

General availability is planned for H1 2026.

Alam explained the value proposition: "A new SAP Snowflake solution extension for SAP Business Data Cloud brings Snowflake's fully managed data and AI capabilities directly to SAP customers, enabling seamless, zero-copy data sharing that maintains governance and business context."

Why This Actually Makes Sense

Bharat Sandhu framed it as customer reality: customers "already know what they need to do." SAP's job is to "provide customers with rich data products."

The practical truth: enterprises have already invested in data platforms. Some chose Databricks three years ago. Others standardized on Snowflake. Some are committed to Google Cloud or Microsoft Azure.

Requiring migration to SAP HANA Cloud for all analytics workloads creates friction. Enterprises resist because:

Migration projects are expensive and time-consuming
Data teams have built expertise in their chosen platform
They've already built analytics and ML pipelines
Breaking those dependencies creates business risk

SAP's response: don't require migration. Instead, extend the existing platform with SAP's business semantics.

Brenda Bown described the broader strategy: "Meet customers where they are. Open ecosystem."

The Complete Partner Landscape

SAP Business Data Cloud Connect now integrates with four major platforms:

Databricks: Generally available now
Google BigQuery: Planned for H1 2026
Microsoft Fabric: Planned for H1 2026
Snowflake: Planned for H1 2026

Each follows the same pattern: SAP data products published to partner catalog, partner data products exposed in SAP catalog, zero-copy sharing, governance maintained.

Additionally, SAP is expanding native capabilities. A technical capability called "near real-time extraction" enables extraction of SAP data from on-premise systems into SAP Business Data Cloud, making it easier for developers to build custom data products enriched with SAP business context.

What About SAP HANA Cloud?

SAP continues significant investment in SAP HANA Cloud as its multi-model AI database. New capabilities announced at TechEd reveal the positioning:

Knowledge Graph Generator

Automatically maps relationships across SAP database tables, columns, and data models. Developers can see how data connects across systems and uncover underlying business insights.

Alam described it: "A new knowledge graph generator tool for SAP HANA Cloud automatically maps relationships across SAP database tables, columns, and data models, revealing how data fits together and why it matters."

General availability expected Q1 2026.

Tabular AI Capabilities

Forecasting, anomaly detection, and predictive modeling directly on structured business data. These capabilities from SAP AI Core are now generally available in SAP HANA Cloud.

Model Context Protocol Support

Makes SAP HANA Cloud data accessible to Joule Agents and custom agents. MCP provides agents with direct access to the rich multi-model engines in SAP HANA Cloud.

General availability planned Q1 2026.

SAP is enabling bidirectional data product sharing between SAP Business Data Cloud and SAP HANA Cloud. Developers can use data across both transactional and analytical workloads while maintaining business logic, KPIs, and governance.

Bharat Sandhu explained: "This capability will allow customers to reuse their existing calculation views in SAP HANA Cloud directly in SAP Business Data Cloud, keeping the business logic, KPIs, and governance intact as data models are extended across the customer's data fabric."

General availability planned Q1 2026.

The Architecture Decision

This creates three legitimate architecture options:

Option 1: SAP-Native

Use SAP HANA Cloud for everything. Best for:

Applications requiring real-time data access
Tight integration with SAP applications
Workloads that need SAP's multi-model database capabilities (relational, graph, vector, spatial in one engine)
Organizations wanting to minimize data platform complexity

Option 2: Hybrid with Partner Compute

SAP Business Data Cloud for semantics and governance, partner platform for compute-intensive analytics and AI workloads. Best for:

Large-scale analytics requiring significant compute
Organizations with existing platform investments
Teams with deep expertise in a specific platform (Snowflake, Databricks, etc.)
Workloads that benefit from partner-specific features

Option 3: Partner-Native with SAP Semantics

Work primarily in partner platform, access SAP data products through Business Data Cloud Connect. Best for:

Data teams standardized on a non-SAP platform
Analytics and ML workloads that don't require real-time SAP data
Organizations prioritizing analyst productivity in their chosen tool

The technical requirement for all three: understanding SAP's data products and business semantics.

The Critical Mistake to Avoid

Bharat Sandhu emphasized the most common integration mistake: "Don't take data out without the semantic understanding."

This is the core value SAP is protecting. Extracting data from SAP and loading it into any data warehouse is technically simple. But you lose:

Business relationships (how entities connect)
Valid transformations (what calculations are meaningful)
Governance rules (who can access what)
Business context (what the data actually means)

One developer during the experience center tour described a failed implementation: "We pulled all our SAP data into our data lake, built our analytics, and everything looked right. But the numbers were wrong because we didn't understand how SAP calculates certain KPIs. We had to rebuild everything with SAP's semantics."

SAP Business Data Cloud Connect solves this by maintaining that semantic layer as data moves to partner platforms.

What SAP-RPT-1 Changes

SAP introduced its first enterprise relational foundation model at TechEd: SAP-RPT-1.

Unlike large language models that predict the next word, RPT models predict business outcomes. They're trained on structured business data and can perform classification and regression on tabular data.

Examples: predicting delivery delays, payment risk, sales order completion.

The technical approach: in-context learning. Users provide example records in the API call. The model analyzes patterns and makes predictions without a training phase.

Brenda Bown explained the positioning: RPT models "has business context." They're designed for accurate predictions on business data, while LLMs handle natural language understanding and generation.

SAP-RPT-1 will be generally available in Q4 2025 on the generative AI hub in SAP's AI Foundation. SAP also launched an interactive testing playground where users can experience the model without coding.

This matters for the data strategy because RPT models need access to trusted, semantically rich business data. That's exactly what SAP Business Data Cloud provides.

The Real Strategy

SAP's data strategy isn't about forcing customers onto SAP infrastructure. It's about becoming essential at the semantic layer regardless of where compute happens.

The bet: compute infrastructure will commoditize. AWS, Azure, Google Cloud, Snowflake, and Databricks will compete on price and performance for raw compute power.

But business semantics won't commoditize. Understanding how SAP calculates revenue, inventory, or employee costs requires deep domain knowledge. That knowledge is encoded in SAP's data products.

As Muhammad Alam said in the keynote: "Innovations across SAP's unique flywheel of applications, data and AI put developers in the drivers' seat."

The flywheel only works if the data layer maintains business context. That's what SAP is protecting with Business Data Cloud and its partner integrations.

What Developers Need to Understand

If you're building applications or analytics on SAP data:

Understand data products first: Before choosing a compute platform, understand what data products SAP provides for your domain. These are the building blocks.

Choose compute based on workload: Real-time applications might need SAP HANA Cloud. Large-scale analytics might benefit from Snowflake or Databricks. There's no single right answer.

Maintain semantic understanding: Whatever platform you choose, ensure you're working with SAP's data products and business semantics, not raw extracted data.

Plan for bidirectionality: Data products flow both ways. You can use SAP data in partner platforms and bring partner data into SAP applications. Design your architecture to take advantage of this.

The flexibility is real. The semantic requirement is non-negotiable.