HANA Cloud: Architecture and Use

JinJin48

SAP Consultant | BTP · S/4HANA · US Global Rollout

May 11, 2026 · 15 min read

Where This Article Sits#

References#

1) The Data and Analytics Landscape#

The L2-C domain covers the services that store, move, model, and visualize data within SAP BTP. Each component plays a different role, and they are designed to complement each other. Source: SAP HANA Cloud Features.

They are not substitutes. HANA Cloud is the persistence and compute layer; the others depend on it, sit beside it, or consume from it.

2) How It Connects to S/4HANA#

SAP S/4HANA in any deployment model (Public Cloud Edition, Private Cloud Edition, or on-premise) generates transactional data that BTP-hosted services consume. SAP HANA Cloud sits at the center of this integration.

┌─────────────────────────────────────────────────────────────────┐
│                        SAP BTP Subaccount                        │
│                                                                   │
│  ┌────────────┐    BTP Service     ┌──────────────────────────┐  │
│  │  CAP App   │◄──── Binding ─────►│   SAP HANA Cloud         │  │
│  │ (Node/Java)│   (VCAP_SERVICES)  │   - Relational Store     │  │
│  └─────┬──────┘                    │   - Document Store       │  │
│        │                           │   - Graph Engine         │  │
│        │ OData / REST              │   - Vector Engine        │  │
│        ▼                           │   - Spatial Engine       │  │
│  ┌─────────────┐                   └───────────┬──────────────┘  │
│  │  SAP BTP    │                               │                  │
│  │  Cockpit /  │                    HDI        │  Data Lake IQ    │
│  │  HANA Cloud │◄──── Admin ───────►Containers │  (petabyte-scale │
│  │  Central    │                               │   analytics)     │
│  └─────────────┘                   ┌───────────▼──────────────┐  │
│                                    │   SAP Data Lake Files     │  │
│                                    │   (Azure/AWS/GCP object   │  │
│                                    │    storage, SAP-managed)  │  │
│                                    └──────────────────────────┘  │
└─────────────┬───────────────────────────────────────────────────┘
              │
     Replication / Virtualization
              │
┌─────────────▼───────────────────────────────────────────────────┐
│  SAP S/4HANA (on-premise / PCE / Public Cloud)                   │
│  SAP ECC / non-SAP sources                                       │
└─────────────────────────────────────────────────────────────────┘

Data flows from SAP and non-SAP source systems into HANA Cloud through replication (SLT, SDI) and virtualization services ( SAP HANA Cloud Getting Started Guide). Applications built with SAP Cloud Application Programming Model (CAP) receive database credentials automatically at runtime via BTP service binding (VCAP_SERVICES), eliminating manual credential management. HDI containers provide schema-per-tenant isolation within the same HANA Cloud instance.

Key point: HANA Cloud is not an isolated database — it is the data persistence hub for the entire BTP application and analytics ecosystem, and its provisioning decisions (region, size, multitenancy model) affect every downstream service.

3) Maturity Map#

4) Requirements Checklist#

Tenant and contract prerequisites#

Data integration and source system readiness#

Application and HDI container governance#

Security and compliance#

5) Decision Criteria#

The three questions to ask first#

Q1. What measurable inefficiency or performance bottleneck does this solve?

Define the pain point in numbers: query latency (current vs. target), reporting delay (batch window vs. real-time requirement), or data silo count. If the answer is “we want to modernize the data platform” without a specific metric, the project scope is not ready to proceed. HANA Cloud’s in-memory architecture eliminates the need for separate OLTP and OLAP systems, but this benefit is only realized when both workloads have been quantified.

Q2. Where does the data live today, and who owns residency decisions?

HANA Cloud region selection is effectively irreversible after initial provisioning — moving to a different region requires a full data copy, not a configuration change ( SAP HANA Cloud Getting Started Guide). Data residency approvals from legal and compliance must be in hand before subaccount and instance creation. For EU data residency requirements, confirm which region option applies and verify that the cloud infrastructure provider (Azure, SAP Cloud Infrastructure, AWS, or Google Cloud) meets the applicable standard.

Q3. Is there an internal sponsor with budget authority and a committed go-live date?

HANA Cloud’s credit-based pricing means ongoing cost accrues from the moment an instance is running ( SAP Tutorials — HANA Cloud vs. On-Premise). Projects that start provisioning without signed cost approval face forced downsizing or instance deletion mid-development, losing environment state and adding re-setup cost. Confirm budget holder sign-off before any instance is provisioned in a productive or near-productive subaccount.

Domain selection by project context#

Licensing and cost#

6) Common Failures#

Failure 1: Region lock-in from premature instance provisioning

A subaccount and HANA Cloud instance provisioned before data residency approval forces a choice between a costly migration and a compliance violation. Migrating to a different region after provisioning requires a full data copy. Make region confirmation a formal gate before any instance is created.

Failure 2: Treating HANA Cloud as a drop-in replacement for on-premise HANA

HANA Cloud shares a common SQL codebase with on-premise HANA ( SAP Tutorials), but the operational model is fundamentally different. OS-level access, manual backup configuration, and custom kernel parameter tuning are unavailable. Projects that assume these capabilities exist on the cloud version discover the limitation late, when redesign is expensive.

Failure 3: HDI container proliferation without governance

In multi-team projects, HDI containers multiply when there is no naming convention or ownership model. Each container is a DTC/RTC pair with a dedicated schema owner. Uncontrolled proliferation makes it impossible to track what is deployed where and complicates upgrade sequencing. Establish the HDI container governance model at project kick-off.

Failure 4: Connection pool sizing omitted from non-functional requirements

CAP for Java defaults to a HikariCP pool with a maximum of 10 connections. In production with hundreds of concurrent sessions, this causes connection exhaustion and cascading timeouts. Pool sizing — per service, per expected concurrent load — must appear in the requirements checklist and be validated in load testing before production cutover ( Connection pool sizing insight).

Failure 5: Data governance and classification delayed until after provisioning

When data sensitivity levels are not defined before integration pipelines are built, the team discovers mid-project that certain datasets cannot be placed in the selected region or require customer-managed encryption keys. Each discovery requires architectural rework. Data classification is a business responsibility — assign an accountable owner before design begins.

Failure 6: Workload isolation not designed for mixed OLTP/OLAP

Without workload class definitions, a long-running analytical query can consume all available threads and starve transactional processes. Projects that deploy mixed workloads without configuring workload classes will experience unpredictable latency spikes in production. Workload class design belongs in the requirements phase.

Failure 7: Budget approval deferred while development instances accrue cost

HANA Cloud credits accrue from instance start time. Development environments left running without stop/start automation generate unplanned cost. Confirm the stop/start policy for non-production instances, and ensure continuous-run cost is explicitly approved before provisioning.

FAQ#

Q: Can we use SAP HANA Cloud for an S/4HANA on-premise extension project, or does it only apply to cloud deployments?

HANA Cloud is suitable for S/4HANA extension scenarios regardless of deployment model (Public Cloud Edition, Private Cloud Edition, or on-premise). Extensions built with CAP on BTP can federate or replicate data from an on-premise S/4HANA system via Cloud Connector and SAP HANA smart data integration. The key prerequisite is network connectivity between the BTP subaccount and the on-premise landscape, which requires security team approval before project design is finalized.

Q: How is HANA Cloud licensing different from on-premise HANA, and what should I communicate to the CFO?

On-premise HANA uses a traditional upfront license purchase plus annual maintenance, with the customer owning all infrastructure. HANA Cloud uses a credit-based consumption model — no upfront license purchase, but ongoing credits accrue based on the size of the running instance. The practical message for finance: no large upfront capital expenditure, but the operating cost is perpetual and tied to instance size and run-time hours. Stopping non-production instances outside working hours reduces cost; right-sizing matters more than it does on-premise.

Q: When should we descope HANA Cloud from a project and use a different persistence option?

Descope HANA Cloud if the workload is pure object storage (unstructured files only, no SQL queries), if the budget does not support ongoing credit consumption, or if the use case can be fully served by a standard database in the target cloud provider. HANA Cloud’s value is highest when the workload combines transactions, analytics, and multi-model data in a single system. If the project is purely analytical with no transactional requirement and petabyte-scale volumes, evaluate whether SAP HANA Cloud Data Lake alone is sufficient and more cost-effective.

Q: How do I document the HANA Cloud requirement properly for a solution proposal or blueprint?

The requirement document should specify: (1) workload type (OLTP, OLAP, or mixed), (2) expected data volume at go-live and 12-month growth, (3) concurrency profile (peak simultaneous users and query types), (4) data residency and encryption requirements, (5) HA/DR tier required (backup-only vs. system replication), and (6) multitenancy model (single-tenant vs. native multi-tenant with schema separation). These six parameters map directly to the sizing, region, and configuration decisions that determine both technical fit and cost.

Q: Is SAP HANA Cloud the same as SAP S/4HANA Cloud?

No. SAP HANA Cloud is the database and data platform service within SAP BTP. SAP S/4HANA Cloud is the ERP application (successor to SAP ECC), which runs on top of an SAP HANA database. The two are related — S/4HANA Cloud uses HANA internally — but they are different products with different licensing, administration, and integration points. In the BTP context, “HANA Cloud” means the standalone database service, not the ERP.

Q: What administration tools are available for HANA Cloud, and do we need separate training?

HANA Cloud uses three layered tools: SAP HANA Cloud Central (instance-level administration shared with Analytics Cloud and Data Lake), SAP HANA Cockpit (database-level monitoring and administration), and SAP HANA Database Explorer (SQL query execution and catalog inspection). Cockpit and Database Explorer functionality is being progressively integrated into HANA Cloud Central ( Admin Tools). Administrators familiar with on-premise HANA Cockpit will find the cloud equivalents recognizable; the main learning curve is BTP-level access management (role collections, subaccount structure).

Summary#

SAP HANA Cloud is the persistence and compute foundation for the SAP BTP Data and Analytics domain. Its in-memory column-store engine, multi-model support (relational, graph, spatial, JSON, vector), native multitenancy, and SAP-managed HA/DR make it production-ready for a wide range of workloads. The shift from on-premise HANA to HANA Cloud is primarily operational: SAP manages infrastructure, backups, and patching, while the customer’s responsibility moves to sizing, data governance, HDI container lifecycle, and connection pool management. The most common project failures happen at the requirements stage — when region, data residency, and workload class decisions are deferred. Treat HANA Cloud provisioning decisions as architectural commitments, not configuration details.

What to Read Next#