The options
| Option | How it works | Compliant after June 2026 | Typical latency | Cost profile | Choose it when |
|---|---|---|---|---|---|
| SAP BDC Connect for Snowflake | Zero-copy, governed sharing of SAP data products into an existing Snowflake account | Yes. SAP’s own path | Near real time to scheduled | SAP license plus Snowflake compute | You want SAP semantics preserved and no duplicated storage |
| SAP Snowflake | Snowflake delivered inside SAP’s commercial and architectural envelope | Yes | As above | Commercially bundled with SAP | You are consolidating spend and governance with SAP |
| CDS views / OData | Application-level extraction through the SAP view layer | Yes | Scheduled, minutes to hours | Engineering effort, no extra license | S/4HANA, where the CDS layer is rich and stable |
| SLT | Trigger-based replication at table level | Yes | Near real time | SLT license plus source system load | You need genuinely low latency on specific tables |
| Datasphere premium outbound | Egress from SAP Datasphere to an external target | Yes | Scheduled | Metered egress. Model it before committing | Datasphere is already in the landscape |
| Database-level replication | Replication beneath the application layer | Situational. Check your agreement | Near real time | Low tooling cost, higher semantic effort | Raw speed matters and you accept rebuilding SAP semantics |
| Third-party ODP-RFC tools | Fivetran, ADF, Qlik Replicate, Informatica over ODP-RFC | No. Blocked | n/a | n/a | Not a forward option. See the ODP-RFC breakdown |
What we recommend, and why
For most landscapes moving SAP data into Snowflake today, BDC Connect for Snowflake is the right default, with CDS view based extraction covering what BDC does not.
BDC is not technically superior in every dimension. The reason to start there is that the extraction decision now carries a licensing dimension that outranks the engineering one. A design that is fast and cheap but outside what SAP permits will eventually stop working, as June 2026 demonstrated to a large number of organizations at once. Choosing SAP’s own sanctioned path removes that risk from the architecture permanently. BDC also delivers SAP-curated data products rather than raw tables, which removes a meaningful amount of semantic rebuild work downstream.
CDS views complement it well because they are equally sanctioned, well understood, and give you control at a level BDC’s curated products do not always reach. On S/4HANA the view layer is rich enough that this combination covers most requirements.
Three situations change that recommendation.
If you need genuine sub-minute latency on specific tables, SLT is the better answer, scoped narrowly to the tables that require it rather than applied across the estate.
If Datasphere is already deployed and paid for, premium outbound may be the pragmatic route. Model the egress metering against real volumes first, because that line item surprises people.
If your reporting is overwhelmingly SAP-sourced and modest in ambition, it is worth asking whether the data needs to leave SAP at all. We would rather tell you that early than build you a pipeline you did not need.
What to settle first
The connector question absorbs most of the attention and is rarely where the money is. The larger decision is which SAP objects need to leave SAP at all, and at what latency. Most estates carry feeds that exist because somebody once asked for them, replicating at a frequency nobody has revisited since. Establishing the requirement first usually changes both the route and the cost more than any comparison of tools does.
That is the first thing our assessment establishes.