Coming from an on-prem HANA background, I wanted to see what basic admin looks like in HANA Cloud from the command line. hdbsql is familiar; cf is what you use for the service instance itself, since the database is provisioned and managed as a BTP service instance.
Everything below uses a hana-free trial instance called HANA_TRAINING_FREE. This is very much a starter for 10 rather than a complete guide to HANA Cloud administration.
Installing hdbsql
No Homebrew formula exists for the SAP HANA client. The npm package @SAP/hana-client looked like a shortcut but isn’t one — it only ships a native Node.js driver binary (hana-client.node), not the hdbsql executable. It’s for connecting from Node.js code, not a command-line SQL shell.
Download the SAP HANA Client from the SAP HANA tools site (.dmg for Mac, arm64 build for Apple Silicon). Once downloaded and mounted:
“/Volumes/SAP HANA Client/hdbinst” –batch –path=/Applications/sap/hdbclient
–batch runs it unattended with default values. Output:
Installing SAP HANA Database Client to /Applications/sap/hdbclient…
Installation done
Add it to PATH:
export PATH=”/Applications/sap/hdbclient:$PATH”
Getting connection details via cf
A service key gives me the connection details for the HANA Cloud instance, including the host and port, along with service-binding credentials such as the XSUAA information. It doesn’t give me the DBADMIN password I need for this direct hdbsql connection, so I’m using the database credentials set when the instance was created.
cf create-service-key HANA_TRAINING_FREE hdbsql-key
cf service-key HANA_TRAINING_FREE hdbsql-key
Relevant fields from the output:
{
“credentials”: {
“host”: “<host>”,
“port”: “443”
}
}
This instance uses TLS on port 443, unlike on-prem HANA’s 3<instance>15 convention.
Connecting
hdbsql -n <host>:443 -u DBADMIN -p ‘<password>’ -ssltrustcert-n — host:port-u / -p — DB user/password-ssltrustcert — trust the server’s TLS cert for this connection without importing it into a local truststore first
First attempt failed:
* -10709: Connection failed (RTE:[89013] Socket closed by peer …)
Cause: the instance’s network access was restricted to Cloud Foundry IPs in the same BTP region, blocking a direct connection from a local machine. Fixed by updating the instance’s IP allowlist:
cf update-service HANA_TRAINING_FREE -c ‘{“data”: {“whitelistIPs”: [“<your-ip>/32”]}}’
<your-ip> is the connecting machine’s public IP, obtainable via curl -s https://api.ipify.org.
After the update completed (confirmed via cf service HANA_TRAINING_FREE showing update succeeded), the connection worked:
hdbsql -n <host>:443 -u DBADMIN -p ‘<password>’ -ssltrustcert -j “SELECT * FROM M_BACKUP_CATALOG;”
07-28 18:53:20.358000000″,”successful”,””,”<ok>”,””,”<backup encrypted>”,””,?,””
1785264800361,”log backup”,1785264800361,”2026-07-28 18:53:20.361000000″,”2026-07-28 18:53:20.361000000″,”2026-07-28 18:53:21.519000000″,”2026-
07-28 18:53:21.519000000″,”successful”,””,”<ok>”,””,””,””,?,””
Output truncated here for the purposes of this blog.
Instance-level cf commands (hana-cloud offering)
cf create-service hana-cloud hana-free <name> -c ‘{“data”:{“edition”:”cloud”,”memory”:16,”systempassword”:”…”}}’ # create the instance
cf update-service <name> -c ‘{“data”:{“serviceStopped”:true}}’ # stop
cf update-service <name> -c ‘{“data”:{“serviceStopped”:false}}’ # start
cf update-service <name> -c ‘{“data”:{“whitelistIPs”:[“<your-ip>/32”]}}’ # update IP allowlist
cf service <name> # status, dashboard URL
cf create-service-key <name> <keyname> # create a service key
cf service-key <name> <keyname> # read a service key’s contents
cf delete-service <name> -f # delete the instance
cf marketplace -e hana-cloud # available plans/params
The following commands are documented but were not tested here. The hana-free plan is fixed at 16 GB and cannot be resized.
cf update-service <name> -c ‘{“data”: {“vcpu”:4, “memory”:64, “storage”:200}}’ # resize
cf rename-service <name> <new-name>
cf delete-service-key <name> <keyname>
cf services # all service instances in the space, with status
Memory and vcpu values must be compatible — a mismatched request returns an error stating the correct value, e.g. “HANA with 4 CPUs requires 64 GB memory (32)”. Storage can only be increased, never decreased once set; decreasing size requires a support ticket rather than a CLI command.
Schema-level cf commands (hana / hdi-shared offering)
An HDI container is a schema plus two auto-generated technical users: a deployer user (_DT) that owns and changes database objects, and a runtime user (_RT) that applications use to access them.
In normal HDI development, you don’t create tables directly with SQL. You define .hdbtable/.hdbview/CDS files, and hdi-deploy works out the required database changes and applies them. The idea is that database artefacts become part of the application’s lifecycle. Containers are created, bound, and removed through BTP service instances rather than being manually provisioned by a DBA.
The container lives inside the hana-cloud instance rather than being a separate database. It is isolated from other containers through separate schemas, technical users, and generated grants, and has its own lifecycle.
Creates the container, binds it to an app, unbinds it, and deletes it:
cf create-service hana hdi-shared <container-name> # create the container
cf bind-service <app> <container-name> # bind: writes credentials into the app’s environment
cf unbind-service <app> <container-name> # unbind
cf delete-service <container-name> # delete the container
Testing the container create/bind cycle
cf create-service hana hdi-shared mycontainer
cf service mycontainer | grep -A2 “last operation” # wait for “create succeeded” before binding
cf bind-service csp-test mycontainer
Confirmed via cf services:
name offering plan bound apps last operation
mycontainer hana hdi-shared csp-test create succeeded
Cleanup:
cf unbind-service csp-test mycontainer
cf delete-service mycontainer -f
That’s about it for this starter for 10: cf for the BTP service side, and hdbsql when you need to work directly inside HANA.
Coming from an on-prem HANA background, I wanted to see what basic admin looks like in HANA Cloud from the command line. hdbsql is familiar; cf is what you use for the service instance itself, since the database is provisioned and managed as a BTP service instance.Everything below uses a hana-free trial instance called HANA_TRAINING_FREE. This is very much a starter for 10 rather than a complete guide to HANA Cloud administration.Installing hdbsqlNo Homebrew formula exists for the SAP HANA client. The npm package @SAP/hana-client looked like a shortcut but isn’t one — it only ships a native Node.js driver binary (hana-client.node), not the hdbsql executable. It’s for connecting from Node.js code, not a command-line SQL shell.Download the SAP HANA Client from the SAP HANA tools site (.dmg for Mac, arm64 build for Apple Silicon). Once downloaded and mounted:”/Volumes/SAP HANA Client/hdbinst” –batch –path=/Applications/sap/hdbclient–batch runs it unattended with default values. Output:Installing SAP HANA Database Client to /Applications/sap/hdbclient…
Installation doneAdd it to PATH:export PATH=”/Applications/sap/hdbclient:$PATH”Getting connection details via cfA service key gives me the connection details for the HANA Cloud instance, including the host and port, along with service-binding credentials such as the XSUAA information. It doesn’t give me the DBADMIN password I need for this direct hdbsql connection, so I’m using the database credentials set when the instance was created.cf create-service-key HANA_TRAINING_FREE hdbsql-key
cf service-key HANA_TRAINING_FREE hdbsql-keyRelevant fields from the output:{
“credentials”: {
“host”: “<host>”,
“port”: “443”
}
}This instance uses TLS on port 443, unlike on-prem HANA’s 3<instance>15 convention.Connectinghdbsql -n <host>:443 -u DBADMIN -p ‘<password>’ -ssltrustcert-n — host:port-u / -p — DB user/password-ssltrustcert — trust the server’s TLS cert for this connection without importing it into a local truststore firstFirst attempt failed:* -10709: Connection failed (RTE:[89013] Socket closed by peer …)Cause: the instance’s network access was restricted to Cloud Foundry IPs in the same BTP region, blocking a direct connection from a local machine. Fixed by updating the instance’s IP allowlist:cf update-service HANA_TRAINING_FREE -c ‘{“data”: {“whitelistIPs”: [“<your-ip>/32”]}}'<your-ip> is the connecting machine’s public IP, obtainable via curl -s https://api.ipify.org.After the update completed (confirmed via cf service HANA_TRAINING_FREE showing update succeeded), the connection worked:hdbsql -n <host>:443 -u DBADMIN -p ‘<password>’ -ssltrustcert -j “SELECT * FROM M_BACKUP_CATALOG;”
07-28 18:53:20.358000000″,”successful”,””,”<ok>”,””,”<backup encrypted>”,””,?,””
1785264800361,”log backup”,1785264800361,”2026-07-28 18:53:20.361000000″,”2026-07-28 18:53:20.361000000″,”2026-07-28 18:53:21.519000000″,”2026-
07-28 18:53:21.519000000″,”successful”,””,”<ok>”,””,””,””,?,””Output truncated here for the purposes of this blog.Instance-level cf commands (hana-cloud offering)cf create-service hana-cloud hana-free <name> -c ‘{“data”:{“edition”:”cloud”,”memory”:16,”systempassword”:”…”}}’ # create the instance
cf update-service <name> -c ‘{“data”:{“serviceStopped”:true}}’ # stop
cf update-service <name> -c ‘{“data”:{“serviceStopped”:false}}’ # start
cf update-service <name> -c ‘{“data”:{“whitelistIPs”:[“<your-ip>/32”]}}’ # update IP allowlist
cf service <name> # status, dashboard URL
cf create-service-key <name> <keyname> # create a service key
cf service-key <name> <keyname> # read a service key’s contents
cf delete-service <name> -f # delete the instance
cf marketplace -e hana-cloud # available plans/paramsThe following commands are documented but were not tested here. The hana-free plan is fixed at 16 GB and cannot be resized.cf update-service <name> -c ‘{“data”: {“vcpu”:4, “memory”:64, “storage”:200}}’ # resize
cf rename-service <name> <new-name>
cf delete-service-key <name> <keyname>
cf services # all service instances in the space, with statusMemory and vcpu values must be compatible — a mismatched request returns an error stating the correct value, e.g. “HANA with 4 CPUs requires 64 GB memory (32)”. Storage can only be increased, never decreased once set; decreasing size requires a support ticket rather than a CLI command.Schema-level cf commands (hana / hdi-shared offering)An HDI container is a schema plus two auto-generated technical users: a deployer user (_DT) that owns and changes database objects, and a runtime user (_RT) that applications use to access them.In normal HDI development, you don’t create tables directly with SQL. You define .hdbtable/.hdbview/CDS files, and hdi-deploy works out the required database changes and applies them. The idea is that database artefacts become part of the application’s lifecycle. Containers are created, bound, and removed through BTP service instances rather than being manually provisioned by a DBA.The container lives inside the hana-cloud instance rather than being a separate database. It is isolated from other containers through separate schemas, technical users, and generated grants, and has its own lifecycle.Creates the container, binds it to an app, unbinds it, and deletes it:cf create-service hana hdi-shared <container-name> # create the container
cf bind-service <app> <container-name> # bind: writes credentials into the app’s environment
cf unbind-service <app> <container-name> # unbind
cf delete-service <container-name> # delete the containerTesting the container create/bind cyclecf create-service hana hdi-shared mycontainer
cf service mycontainer | grep -A2 “last operation” # wait for “create succeeded” before binding
cf bind-service csp-test mycontainerConfirmed via cf services:name offering plan bound apps last operation
mycontainer hana hdi-shared csp-test create succeededCleanup:cf unbind-service csp-test mycontainer
cf delete-service mycontainer -fThat’s about it for this starter for 10: cf for the BTP service side, and hdbsql when you need to work directly inside HANA. Read More Technology Blog Posts by Members articles
#SAP
#SAPTechnologyblog
