Skip to main content

18.6 Cloud Warehouses

1. Why cloud warehouses appear in Datasphere architectures​

Enterprise landscapes commonly contain:

  • Amazon Redshift,
  • Snowflake,
  • Microsoft analytics platforms,
  • cloud-native relational stores,
  • legacy enterprise warehouses.

Datasphere should integrate with them deliberately rather than become a second copy of every warehouse.

2. Current connection capability​

SAP Datasphere's delivered connection catalog includes non-SAP cloud sources such as Amazon Redshift and supports different combinations of remote tables and data flows depending on the connection.

The exact feature matrix changes over time, so architects must validate the current SAP documentation for the connection type and tenant release.

3. Architecture choices​

Federate​

Use when:

  • source query performance is acceptable,
  • data must remain in the source,
  • the use case is selective.

Replicate​

Use when:

  • Datasphere should provide a stable local analytical copy,
  • repeated queries justify persistence,
  • source protection matters.

Rebuild​

Use when:

  • the existing warehouse is being retired,
  • business semantics should be redesigned,
  • historical technical debt should not be reproduced.

4. Avoid warehouse-on-warehouse duplication​

Redshift
   |
full copy
   v
Datasphere
   |
full copy
   v
another warehouse

Every copy needs:

  • storage,
  • security,
  • reconciliation,
  • monitoring,
  • lifecycle ownership.

5. Cross-cloud architecture​

Define which platform owns:

  • raw data,
  • harmonized data,
  • enterprise semantics,
  • data products,
  • consumption.

Do not let ownership emerge accidentally.

Exercise​

Your company has Redshift for marketing and Datasphere for SAP analytics.

Design a customer 360 architecture without copying the entire Redshift warehouse.