Search
FREE DEMO
FREE DEMO
E-mail
Phone
Home Snowflake AI Data Cloud

Snowflake AI Data Cloud

0
(0)
  • 6 min reading time
Image of Tobias Vogler

Tobias Vogler

_Snowflake AI Data Cloud

In this article, we explore the integration of SAP BDC with Snowflake AI Data Cloud in more detail. With SAP Business Data Cloud (BDC), SAP has successfully established its new strategic platform for data and AI on the market. One of the key innovations of BDC is its openness to other cloud platforms via SAP BDC Connect, allowing semantically valuable and often business-critical SAP data to be used in semantically well-structured (SAP-managed) data products across different platforms without significant engineering effort.

Table of contents
 

1. What is Snowflake and what can it do?

But first, we should address the fundamental question of what Snowflake is and what makes it so special.
 
Snowflake has been active in the market since 2012 and is one of the largest providers in the data warehousing sector. Snowflake was founded by Benoit Dageville, Thierry Cruanes (both former Oracle engineers), and Marcin Zukowski (co-founder of Vectorwise). Their vision was to develop an analytical database system (data warehouse/OLAP system) from the ground up exclusively for the cloud. Users should have to worry about nothing other than their use cases, which is why Snowflake was set up as a SaaS platform. No one should have to worry about hardware, updates/patches, or other operational issues; “It just works” was the goal.
 
Problems that were keeping competitors and their customers up at night were to be eliminated in one fell swoop. For example, if the computing capacity of a system at the time (such as Teradata or Netezza) reached its limit, you had to buy new hardware along with storage, even though the additional storage capacity wasn’t actually needed—it was really just more computing power that was required. (Or vice versa.)
 
This results in unnecessarily high costs for hardware and operational staff, and the system is generally not very flexible or adaptable to changing needs. On hyperscaler cloud platforms (AWS, Azure, GCP), resources can be provisioned in seconds as needed and are available in virtually unlimited quantities. And it is precisely these characteristics that Snowflake leverages with its architecture:
 
As shown in the previous figure, Snowflake is divided into three layers from bottom to top:
  1. Storage Layer,
  2. Compute Layer and
  3. Cloud Services Layer.

The storage layer is where the data loaded into Snowflake is stored. This is done using the Object Object of the cloud provider hosting the Snowflake account (S3 for AWS, Azure Blob Storage, and GCP Cloud Storage). In this way, Snowflake leverages the unmatched availability and scalability of these technologies, demonstrating that Snowflake was built for the cloud without compromise. A fixed monthly fee per TB is charged for storage in Snowflake. The amount depends on the cloud provider hosting Snowflake and its region/data center.
 
The Compute Layer provides a flexible way to provision and manage computing resources for data processing. Snowflake uses the concept of a so-called virtual warehouses. These are computing resources (VMs) that can be flexibly provisioned and decommissioned. The size—and thus the performance—of a virtual warehouse in Snowflake is defined by T-shirt sizes ranging from XS to 6XL, i.e., ten different sizes.
 
You pay for the time during which a Virtual Warehouse is active. An XS Warehouse (the smallest size) consumes one credit for every hour that the Virtual Warehouse is active. Each tier doubles the capacity and, accordingly, doubles the credit consumption. The price of a credit depends on the hyperscaler, its region, and the Snowflake edition:
 
In this example, a credit in the Enterprise Snowflake Edition at the GCP data center in Frankfurt costs $3.90.
 
Virtual warehouses can be configured with a high degree of flexibility, allowing them to, for example, shut down automatically after a certain period of inactivity and then restart automatically when the system needs them again. This means that Snowflake offers maximum flexibility and resource elasticity in terms of compute capacity.
 
The Cloud Services Layer is a multi-tenant application that handles all administrative tasks for all Snowflake customers. This primarily includes metadata and access management, as well as automated performance tuning.
 

2. How has Snowflake evolved since its founding?

In the past, or rather when Snowflake was first launched, the system was primarily designed as a data warehouse or database system, and this remains the case today. When using Snowflake, it is immediately apparent that SQL queries and statements are the primary means of interaction. In Snowflake, everything can be managed via SQL—from creating users and permissions to loading and processing data, all the way to deploying auto-scaling web applications. Another aspect that has defined Snowflake from the very beginning is the aforementioned separation of storage and compute, allowing both to scale independently of one another. That is why billing in Snowflake is also handled separately based on these two components. Over the years, additional capabilities and functionalities have been added to the core features. Most notably in the recent past, a wide range of AI features have been introduced with Snowflake Cortex AI and Snowflake Intelligence, which integrate large language models (LLMs) and AI agents into the platform. There is a strong focus on this, which is why Snowflake has also undergone a rebranding to Snowflake AI Data Cloud.
 

3. How do Snowflake and SAP Business Data Cloud fit together?

As part of SAP BDC Connect, a partnership and compatibility with Zero-Copy Data Sharing for Snowflake have now been announced. This gives existing Snowflake customers the ability to use and make available SAP Data Products bidirectionally via SAP BDC Connect. To do this, SAP BDC Connect must be configured and managed for the Snowflake account.
 
But there is also the option of using Snowflake as an SAP-managed solution extension, SAP Snowflake. This is comparable to SAP Databricks, though there are also differences. While SAP Databricks offers significantly fewer features than Native Databricks, SAP Snowflake requires users to forgo far fewer features. At the time of writing, there was no indication that any significant Snowflake features would have to be sacrificed.
 

4. What are the benefits of SAP Snowflake?

SAP Snowflake is fully integrated into the SAP ecosystem, which is why SAP also becomes the primary support partner. Furthermore, once provisioned, SAP Snowflake is immediately capable of consuming and delivering SAP Data Products without requiring an extensive setup of SAP BDC Connect. Thanks to its integration into the SAP ecosystem, security and governance issues such as user management, connectivity, and so on are also easier to manage.
 
Furthermore, there are no licensing restrictions on the use of SAP Data Products within SAP Snowflake, whereas Native Snowflake and other SAP BDC Connect platforms do have some restrictions in this regard. In terms of licensing and billing models, SAP Snowflake is quite straightforward. It is not billed using SAP Capacity Units (CUs), but rather in the form of two separate SKUs—specifically, Compute and Storage, similar to Native Snowflake.
 

5. What is the cost structure for zero-copy data sharing?

Regardless of whether SAP Data Products are used via Native or SAP Snowflake, infrastructure fees apply in both cases—in addition to the platform’s own resource consumption.

These fees are incurred because using SAP Data Products generates costs on the underlying cloud provider —particularly for I/O workloads in the Object Store ( storing, reading, and transferring data).

Side Note: How are SAP Data Products and Snowflake tables stored?

SAP Data Products are stored as Delta Lake tables in the cloud provider's object store. A helpful background article on this topic is: https://delta.io/blog/delta-lake-vs-parquet-comparison/
In short: A table does not exist as a single file, but is divided into many individual files (data files), each of which contains only a portion of the table data. Metadata (e.g., which files belong to which table and how they should be read optimally) is managed separately.

Data storage in Snowflake works in much the same way: there, too, data is organized in the background into files and metadata.

Why does this result in additional costs?

Every access to the Object Store—that is, an API call or processing request to read a file—incurs costs for the hyperscaler, which are billed accordingly.

These costs are usually lower when the consuming application operates within the same cloud region. However, as soon as data crosses regional boundaries (or has to leave the data center), transfer costs can rise significantly.

What do the infrastructure fees consist of?

Infrastructure fees typically consist of two components:

  1. Inter-Region Data Transfer Fee
    For SAP Data Product data that must leave the BDC Data Center.

  2. Processing Requests
    For API calls to the Object Store (e.g., reading files/objects).

Additional fees for use via Native Snowflake / BDC Connect

When SAP Data Products are used via Native Snowflake and BDC Connect, the following apply in addition to:

  • Infrastructure Fees and
  • the standard Snowflake costs

as well as premium fees.

Snowflake measures the compute workloads generated within the Snowflake platform during the processing of SAP Data Products and regularly reports these values to SAP. SAP then calculates an uplift, and billing is subsequently processed in the form of CUs (Consumption Units) via SAP BDC Connect.

6. Conclusion: Architectural Elegance vs. Commercial Reality

The strategic expansion of the SAP Business Data Cloud toward the Snowflake AI Data Cloud marks a turning point in modern data management. Native zero-copy data sharing finally breaks away from the traditional, error-prone, and maintenance-intensive ETL paradigm for SAP data. Data is available across platforms without the need for replication. For companies, the primary question during implementation is which operating and licensing model is the right fit:

  • Native Snowflake with BDC Connect offers maximum independence within an existing cloud setup, but requires architects to closely monitor license restrictions as well as the premium fees charged by SAP (uplift on compute workloads via CUs).
  • SAP Snowflake (Solution Extension) stands out as a fully embedded solution with direct SAP support, no setup hurdles, and straightforward, purely resource-based billing via dedicated SKUs—with no licensing restrictions on the use of SAP Data Products.
Ultimately, however, it is not just the contractual terms that determine economic success, but the physical cloud topology. Since data delivery is based on API calls to object stores (Delta Lake format), placing Snowflake and BDC instances in the same hyperscaler region remains the most important factor for keeping infrastructure fees (particularly inter-region data transfers) to a minimum. By taking these aspects into account, you gain a state-of-the-art data architecture that seamlessly combines business-critical SAP semantics with the scalability and AI capabilities of Snowflake.
 


Would you like to understand the cost structure behind zero-copy data sharing, infrastructure fees, and premium fees in detail—and find out what that means specifically for your use case? Then contact us here!

Published by:

Tobias Vogler

author
Image of Tobias Vogler

Tobias Vogler

How did you like the article?

How helpful was this post?

Click on a star to rate!

Average rating 0 / 5.
Number of ratings: 0

No votes so far! Be the first person to rate this post!

INFORMATION

More information

IT Change Management

IT Change Management: Definition, Process, and Best Practices
Change Management, IT
Companies realize less than one-third of the expected benefits from digital transformations, not because the technology fails, but because...
LEARN MORE

What Is FP&A? Definition, Core Processes, and the Future of Corporate Management
Companies aren't managed by reports—they're managed by better decisions. FP&A, or Financial Planning & Analysis, is the strategic...
LEARN MORE

Mission Lakehouse – All Wikis at a Glance
Databricks
Our Lakehouse mission is complete. In a series of 10...
LEARN MORE

How to Build a Code-Based AI Agent in SAP: A Step-by-Step Guide Using Python & AI Core
SAP Business AI
The wiki is intended for developers and technically savvy SAP consultants who are creating a code-based AI agent using Python for the first time,...
LEARN MORE

FinOps: The Art of Maximizing Cost-Value in the Cloud
Databricks
How does this work in data sharing with SAP and Databricks? The strategic partnership between SAP and Databricks enables...
LEARN MORE
Mosaic AI

Databricks Mosaic AI: AI agents that truly master your SAP business logic
Databricks
Data access does not equate to mastery of logic. An AI agent only “masters” SAP when it operates at the semantic level—working with key performance indicator definitions, organizational structures...
LEARN MORE
Your guide to successful SAC migration

SAC Migration by Q2 2026: The Guide to Transitioning to the Optimized Story Experience
The time for the conversion of SAP Analytics Cloud (SAC)...
LEARN MORE
CONTACT

Have we sparked your interest?

Please make sure to fill in all form fields marked with (*) below.

Theresa Riesterer

Professional Analytics consultant
Back