SAP Data in Snowflake and Databricks: Who Governs What Your AI Is Fed?

SAP now shares data with Snowflake and Databricks with no copy. It is a real step forward, and it has generated plenty of excitement. But getting SAP data into your platform is the easy half.

For AI, success is determined by what the model is fed. This post looks at what zero-copy sharing solves, what it does not, and how to stay in control of the SAP data your analytics and AI actually use.

The news is real

SAP now shares data with both Snowflake and Databricks using zero-copy. Databricks went live first, in late 2025, and Snowflake followed in 2026. In each case the data stays in SAP, and your platform reads it in place. There is no pipeline to build for that read, and no second copy to govern.

If you run a recent SAP cloud edition and you want trusted SAP figures inside Snowflake or Databricks for reporting, or to ground an AI model on real business data, this is a clean way to do it. We are glad to see it. Making SAP data easier to read into these two platforms is good for our customers.

What the headline leaves out

"No copy" and "no ETL" are true for one thing: the read. They do not mean the work is done.

• The share into your platform is read only. You can query it. You cannot change it.
• Any transformation is still yours to build. Zero-copy gives your AI access to the data. It does not clean it, join it, or shape it the way a model needs. Your team builds that in Snowflake or Databricks.
• To keep a prepared result, you write it into your own table. That is a copy. The moment you do real work, the copy you were told you had avoided comes back.
• It does not write into your core SAP systems. Data can be shared back to SAP's data cloud, but not into the SAP applications your business runs on.
• There is no zero-copy share into Alteryx, KNIME, Dataiku, Power BI, Excel, or the other tools most analysts work in every day.

None of this is a fault. It is just the limit of what the feature is built to do.

For AI, the question is control

A model is only as good as what it is fed. This is where the choice matters.

A live share hands your AI whatever sits in the view. A curated workflow puts a step you control between SAP and the model. Your team builds that step in Alteryx, KNIME, Dataiku, or the DVW Flow Tool. In it you:

• Choose the exact fields and rows the model sees, and nothing more.
• Mask sensitive data, check it, and apply your own business rules before it reaches the model.
• Save a dated, repeatable dataset, so you can show exactly what the model saw when it made a decision.

Access lets your AI reach SAP data. Control lets you decide what SAP data your AI is allowed to learn from.

For a bank, an auditor, or any regulated team, this is what matters most. It is the difference between hoping your AI was trained on the right data and being able to prove it.

DVW does far more than feed one warehouse

This is what the DVW Connectors for Alteryx, KNIME and Dataiku are built for, alongside the standalone DVW Flow Tool.

• They read SAP directly, from inside your analytics tool. Not a pre-shaped slice. Tables and views, BW queries, SAP queries, the data behind SAP transactions (T-Codes), reports and Fiori apps, attachments, and archived records.
• The Alteryx Connector, the KNIME Connector and the Flow Tool write back into SAP itself. Extract, prepare, model, then write the result into the SAP system your business runs on. The loop closes where the work happens, not just at a data platform.
• They reach more than 20 platforms. And they work with the SAP systems most companies actually run, from SAP ECC to SAP S/4HANA, not only the newest cloud editions.
• They put SAP data next to your non-SAP data. Most of your data does not live in SAP. Because the connectors run inside Alteryx, KNIME and Dataiku, SAP data lands right where those tools already reach your files, databases, cloud applications and other systems. You blend SAP and non-SAP data in one workflow, wherever it lives, without first loading everything into a warehouse.
• The cost is a fixed yearly subscription, and the install uses the skills your team already has.

Read and write SAP data from any analytics or data platform.

Who runs it, and how fast

Getting SAP data into Snowflake or Databricks with zero-copy is usually an IT-led program. SAP data has to be modeled into data products, the platforms are connected with admin rights, and the transformation is built by engineers. The business waits on IT to deliver it.

DVW is often run by the business. Once SAP access is granted, an analyst installs the connector in the tool they already use and can be building useful workflows in days, not weeks or months. They keep control of it, and they change it themselves as new questions come up, without raising a ticket every time.

You do not have to choose

It helps to be clear about scope. Teams do four things with SAP data. They analyze it, they migrate it, they automate the work around it, and they feed it to AI. Zero-copy helps with one slice of the first and the last: reading SAP data into Snowflake or Databricks for reporting and for grounding a model. It does not migrate SAP data. It does not automate SAP tasks. It does not write results back into your core SAP systems. Those needs do not disappear because one read got easier.

DVW covers all four. Self-service analytics into Alteryx, KNIME, Dataiku, Power BI and more, which is what most customers use DVW for every day. SAP data migration, including SAP ECC to SAP S/4HANA. Process automation across SAP GUI and Fiori. And AI pipelines that prepare SAP data and write the results back.

So this is not SAP or DVW. For governed, read only SAP data in Snowflake or Databricks, zero-copy is a good fit. For everything else your teams do with SAP data, DVW is built for it, and many customers will use both. Whatever SAP data platform you adopt, DVW is the bridge that makes SAP data usable in both directions, in the tools your teams already work in.

Sources

• SAP BDC Connect for Snowflake reached general availability on 4 May 2026, with zero-copy sharing "without moving or duplicating data": Snowflake documentation, SAP BDC Zerocopy Connector (general availability).
• Shared SAP data products appear in Snowflake as a read-only schema of semantic views generated from SAP Core Schema Notation: Snowflake documentation, About Snowflake and SAP Zero-Copy Integration and Explore Data Products from SAP BDC Connect for Snowflake.
• SAP BDC Connect for Databricks reached general availability in October 2025, with bidirectional, zero-copy sharing via Delta Sharing: Databricks, Announcing the General Availability of SAP Business Data Cloud Connect to Databricks.
• SAP's overview of zero-copy data sharing with Snowflake and Databricks: SAP News, Introducing SAP Snowflake and new data fabric innovations.

Sharing between these platforms and SAP Business Data Cloud can be bidirectional. That is separate from writing data into SAP business applications, which is what DVW does.

Try DVW with your SAP data

Read and write SAP data from any analytics or data platform. Free 30-day trial, full functionality, no commitment.

Start Free Trial Book a 30-Minute Live Demo

Trusted by 500+ enterprises.