SAP HANA Cloud: The In-Memory Database for Cloud-Native SAP Apps

SAP HANA Cloud is the cloud-native, managed-service edition of SAP's HANA in-memory, columnar database. It is the persistence layer that powers S/4HANA extensions, CAP-built applications, and analytical services on SAP BTP, and it is the database most new SAP cloud development targets. Where the on-premise HANA appliance asks you to install, patch, and tune the engine yourself, HANA Cloud delivers the same columnar engine, SQLScript runtime, and predictive libraries as a database-as-a-service across AWS, Azure, and GCP, with scaling, backups, and high availability handled by SAP.

If you are building anything on SAP BTP, HANA Cloud is almost certainly in your stack. This guide covers what HANA Cloud is, how it differs from on-premise HANA, its architecture and HDI container model, the developer-facing features, how to connect and work with it, and how AI coding assistants can speed up HANA development when given the right context.

What is SAP HANA Cloud?

SAP HANA Cloud is the database-as-a-service version of the SAP HANA platform, delivered as a managed service on SAP BTP. At its core is the same in-memory, hybrid row-and-column relational engine that has powered SAP's flagship products since 2011, but re-architected for cloud economics: compute and storage are separated, scale-up and scale-out are self-service, and operational tasks like patching, backup, and disaster recovery are automated by SAP.

HANA Cloud is available across the three major hyperscalers (AWS, Microsoft Azure, and Google Cloud), and it is deployed into a BTP subaccount in a specific region. A single instance is created from the BTP Service Marketplace (or via the cf or btp CLI), given a size in compute (vCPUs and memory) and storage, and then bound to applications just like any other BTP service. S/4HANA Cloud private editions, SAP Datasphere, CAP apps, and custom cloud-native services all consume HANA Cloud under the hood.

Beyond the transactional database, HANA Cloud bundles several engines that on-premise HANA offered as separate capabilities: a data lake (for cost-effective warm and cold storage of large volumes on object storage), predictive analytics (PAL and APL algorithm libraries), spatial and graph processing, and multi-model support for JSON, full-text search, and vector operations. The result is a single managed service that covers OLTP, OLAP, and advanced analytics without a separate data warehouse.

SAP HANA Cloud vs SAP HANA On-Premise

Because HANA Cloud and HANA on-premise share the same core engine, the differences are mostly operational rather than functional. The choice usually comes down to who manages the infrastructure and how elastic you need your capacity to be.

In practice, on-premise HANA is still common for large S/4HANA private-cloud landscapes where full OS-level control, custom hardware, or strict data-residency rules matter. HANA Cloud is the default for new cloud-native development, BTP-hosted extensions, and any scenario where elastic scaling and hands-off operations are valuable. They also coexist: HANA Cloud can federate queries to on-premise HANA and other remote sources via smart data access, so a hybrid landscape is a normal pattern, not an exception.

Architecture

SAP HANA Cloud is structured so that compute, memory, and persistent storage are decoupled and independently scalable. The main building blocks are:

• Compute instance — the HANA database engine itself, sized in vCPUs and memory (for example, a 3 vCPU / 60 GB instance). This is what runs your SQL, SQLScript, and calculation views. Compute instances can be scaled up (more memory/vCPUs) or scaled out (multiple nodes for throughput).
• In-memory store — the row and column tables that live in memory. Hot transactional and analytical data sits here for sub-millisecond access.
• Persistent storage — durable disk-backed storage for data that must survive restarts and for persisting in-memory snapshots. Storage is billed separately from compute and can be grown without resizing the instance.
• Data lake — an optional integrated store for warm and cold data at lower cost, using object storage under the hood. Useful for large historical tables, logs, or IoT feeds that do not need in-memory latency.
• HDI containers — isolated deployment units (one per application or tenant) that hold design-time artifacts and a dedicated runtime schema. See the next section.

All of this is exposed through a single connection endpoint (host, port, user, password) that you get from the BTP service key. Standard JDBC, ODBC, and native drivers connect to that endpoint; there is no special HANA-Cloud-only protocol.

A key architectural consequence of the compute-storage split is that resizing memory does not require migrating storage, and growing storage does not require a larger instance. This is a meaningful difference from on-premise HANA, where memory and disk are tied to the appliance you bought.

Key Features for Developers

From a developer's perspective, HANA Cloud is much more than a SQL database. The features that shape how you build applications are:

• SQLScript — an imperative extension to SQL with typed variables, control flow, table variables, and parameterized procedures and functions. SQLScript is how you push data-intensive logic into the in-memory engine instead of hauling rows into the app layer. See the dedicated section below.
• Calculation views — declarative, graphical data models that join, aggregate, filter, and compute over tables and other views. They are the primary unit of analytical modeling in HANA and are consumed via SQL or OData.
• Predictive Analytics Library (PAL) and Automated Predictive Library (APL) — hundreds of in-database algorithms for classification, regression, clustering, time series, and recommendation, callable from SQLScript or the hana-ml Python client.
• Spatial and graph — native geometry, geography, and graph traversal, useful for logistics, network, and relationship analysis without a separate database.
• Multi-model — JSON document store, full-text search with fuzzy matching, and vector types for similarity search, increasingly relevant for RAG-style AI applications.
• Multi-tenancy — HANA Cloud supports tenant isolation via HDI containers and database users, which is how CAP multitenant apps and SaaS scenarios separate customer data.

The unifying principle is code-to-data: rather than pulling data out of the database to process it in your application, you push the processing down into HANA's in-memory engine where the data already lives. SQLScript, calculation views, and PAL are the main mechanisms for doing that.

HDI Containers

The HANA Deployment Infrastructure (HDI) is the deployment and lifecycle model that HANA Cloud uses for application database artifacts. An HDI container is an isolated schema that holds design-time objects (table definitions, views, procedures, synonyms, roles) deployed from a source repository, together with the generated runtime objects and two dedicated technical users: an object owner (used to deploy) and an application user (used by the runtime app to read and write).

Why HDI matters in practice:

• Isolation — each app, microservice, or tenant gets its own container. Two apps can both have a table called Orders without colliding, because each lives in a separate container schema.
• Declarative deployment — you commit .hdbtable, .hdbview, .hdbprocedure, and similar design-time files to a repository and a deployer (@sap/hdi-deploy) creates or updates the runtime objects. Schema changes are handled by diffing the design-time state.
• Versioned and repeatable — because artifacts come from source, the same container can be recreated in dev, test, and prod, which is essential for CI/CD.
• Native to CAP — CAP projects that target HANA generate an HDI container automatically when you run cds deploy --to hana. The CDS models compile to HDI design-time artifacts.

Creating an HDI container in a HANA Cloud instance bound to a Cloud Foundry space:

# Create an HDI container service instance
cf create-service hana hdi-shared my-app-hdi

# Create a service key to inspect the container credentials
cf create-service-key my-app-hdi my-key
cf service-key my-app-hdi my-key

The service key returns a JSON object with host, port, user, password, schema, and certificate. Those are the values you use to connect any driver, deployer, or tool.

For native HANA development (not using CAP), you author the design-time files directly in a db/ module, add @sap/hdi-deploy as a dependency, and run the deployer as part of your MTA build. The deployer computes the diff against the container's current state and applies only the changes, which is what makes iterative development safe.

Connecting and Working with HANA Cloud

The first step is always creating a HANA Cloud instance and a service key. Once you have the credentials, you connect through standard drivers and tooling.

The SAP HANA CLI (hana-cli)

The hana-cli npm package is the most productive command-line tool for HANA Cloud. It covers 90+ commands for inspecting and administering the database:

# Install globally
npm install -g @sap/hana-cli

# Connect using a service key (or pass host/user/password directly)
hana-cli connect --host <host> --port 443 --user <user> --password <pwd>

# Inspect tables in a schema
hana-cli tables --schema MYAPP_HDI_DB_1

# Run a SQL query
hana-cli sql --sql "SELECT CURRENT_TIMESTAMP FROM DUMMY"

# List HDI containers
hana-cli hdi --container MYAPP_HDI_DB_1

hana-cli is especially useful for exploring an unfamiliar instance, generating CDS or EDMX from existing tables, and scripting database operations in CI/CD.

JDBC and ODBC

For Java applications, the SAP HANA JDBC driver (com.sap.db.jdbc.Driver) is the standard connection method. A typical JDBC URL looks like:

jdbc:sap://<host>:443/?encrypt=true&validateCertificate=true&communicationTimeout=10000

For ODBC-based tools (Excel, Tableau, legacy apps), SAP provides the HANA ODBC client and a HANA client driver manager. On BTP, you usually avoid installing drivers locally and instead connect from within a Cloud Foundry or Kyma app via a bound service instance.

Node.js and Python

CAP and most Node.js services use @sap/hana-client (or the newer @sap/hana-client-ext) to talk to HANA Cloud. For Python, the hana-ml library and the underlying hdbcli/sqlalchemy-hana drivers connect to the same endpoint:

from hana_ml import dataframe as hd

conn = hd.ConnectionContext(
    address='<host>',
    port=443,
    user='<user>',
    password='<pwd>',
    encrypt='true',
)
df = conn.table('BOOKS', schema='MYAPP_HDI_DB_1')
print(df.collect().head())

The connection parameters are identical regardless of language; only the driver name changes. Always enable TLS (encrypt=true) and validate the HANA Cloud certificate, which is available in the service key JSON.

Pricing and Tiers

SAP HANA Cloud is priced per instance, based on compute (vCPUs and memory) and storage. Two commercial models dominate:

• Pay-As-You-Go — metered, no commitment, billed by the hour. Good for development, spikes, and proof of concept.
• Subscription / CPEA (Cloud Platform Enterprise Agreement) — committed spend over a term in exchange for discounts. The default for production landscapes.

SAP also offers a free tier service plan for HANA Cloud through Pay-As-You-Go or BTPEA accounts. The free tier plan has no time limit but caps compute (a small instance) and storage, making it suitable for learning, prototypes, and small non-production workloads. The separate 90-day BTP trial also includes a limited HANA Cloud instance, but it is deleted when the trial expires.

Practical guidance: use the free tier plan or Pay-As-You-Go for evaluation and dev, then move to a committed subscription for production once your sizing is stable. Scale storage and compute independently to avoid over-provisioning memory you do not need.

HANA Cloud with AI Coding Assistants

HANA Cloud has a wide developer surface: SQLScript syntax, HDI artifact conventions, dozens of hana-cli commands, the hana-ml API, calculation view modeling, and BTP-specific connection and binding patterns. General-purpose AI assistants routinely get this wrong. They confuse HANA on-premise features with HANA Cloud, invent SQLScript built-ins that do not exist, generate HDI artifacts with the wrong file extensions, or produce connection strings that ignore HANA Cloud's TLS requirements.

This is the gap that the SAP Skills fill. Each HANA skill is a curated, current reference that gives your assistant accurate in-domain context. The three most relevant for HANA Cloud development are:

• sap-hana-cli — covers the 90+ hana-cli commands, output formats, HDI container management, and BTP CLI integration so generated commands actually run.

  npx skills add secondsky/sap-skills --skill sap-hana-cli
  

• sap-sqlscript — SQLScript syntax patterns, built-in functions, exception handling, performance optimization, cursor management, and the code-to-data paradigm so generated procedures compile and perform.

  npx skills add secondsky/sap-skills --skill sap-sqlscript
  

• sap-hana-ml — the hana-ml Python client, PAL/APL algorithms, HANA DataFrame operations, AutoML, and model persistence for in-database machine learning.

  npx skills add secondsky/sap-skills --skill sap-hana-ml
  

For full-stack BTP development, pair these with sap-cap-capire (so CAP correctly generates HDI artifacts) and sap-btp-cloud-platform (so entitlement, service instance, and binding steps are correct). Note that SAP Skills is a community-maintained, open-source project and is not an official SAP product; it complements, but does not replace, the SAP Help Portal documentation.

Getting Started

1. Create a HANA Cloud instance in a BTP subaccount (free tier plan, Pay-As-You-Go, or committed) from the Service Marketplace or via the btp CLI.
2. Allow your client IP in the instance's allowed connections, or bind the instance to a Cloud Foundry or Kyma app.
3. Create an HDI container and a service key, then use the credentials to connect from hana-cli, your driver of choice, or a CAP project.
4. Install the HANA-focused SAP Skills so your AI assistant produces correct SQLScript, hana-cli commands, and HDI artifacts from the first prompt.
5. Iterate with cds watch (for CAP) or direct .hdb* file deployment, and use calculation views and SQLScript to push logic into the engine.

SAP HANA Cloud is the database layer for most modern SAP cloud applications. Understanding its architecture, HDI container model, and SQLScript is what separates a developer who can ship SAP apps from one who can only query them.