SAP HANA Cloud
SAP HANA Cloud Elastic Compute Node: Architecture, Routing, and Sizing
Learn how SAP HANA Cloud elastic compute nodes extend read capacity, how query routing works, and what to consider before adding one to an instance.
SAP HANA Cloud elastic compute nodes provide additional compute capacity for read-intensive workloads without changing the primary database architecture. They are useful when analytical queries, reporting, or other read activity competes with transactional processing on the primary node.
An elastic compute node is added to an existing SAP HANA Cloud instance and works with the primary node as part of a coordinated deployment. The feature is primarily about read scaling, not about creating an independent database or replacing capacity planning for the primary node.
What an Elastic Compute Node Is
An elastic compute node is an additional compute resource associated with an SAP HANA Cloud database instance. It can process eligible read queries while the primary node continues handling transactional activity and other database work.
The node does not represent a separate tenant database, a new SAP HANA Cloud edition, or a general-purpose failover replacement. SAP HANA Cloud capacity is planned by instance configuration, service plan, and capacity. Elastic compute nodes extend that design for a particular performance requirement.
A node is most relevant when the workload has a sustained or predictable read-heavy component. Examples include dashboards, operational reporting, data exploration, and analytical queries that can place pressure on the primary compute layer.
How Elastic Compute Nodes Fit the Architecture
The primary node remains the system of record for the database instance. An elastic compute node connects to the same data service and receives the information required to execute eligible queries. The resulting architecture separates some read processing from primary-node processing while preserving a common database context.
Application or reporting client
|
Query routing decision
/ \
Eligible read work Transactional or unsupported work
| |
Elastic compute node Primary database node
\ /
Shared SAP HANA Cloud instance
This separation can reduce contention, but it does not make every query faster. A query may still be limited by joins, filters, data movement, memory pressure, poor modeling, or the primary node when it cannot be routed to an elastic node.
For the broader administration model, use SAP HANA Cloud Central to manage the cloud service and review the instance-level resources available to it.
How Query Routing Works
Elastic compute nodes deliver value only when suitable queries reach them. Routing depends on the connection and workload configuration supported by the service, together with the characteristics of the query. Applications and reporting tools therefore need a deliberate routing design rather than an assumption that all traffic will automatically move to the additional node.
A practical routing plan separates read-only analytical traffic from transactions, administrative operations, and requests that require primary-node processing. Validate the behavior with the client technology and connection settings used by the application. Also confirm that the routed workload is compatible with the consistency and feature requirements of the use case.
The main routing questions are:
- Which users, applications, or connection pools generate read-heavy traffic?
- Which queries can tolerate the supported read consistency behavior?
- Which operations must remain on the primary node?
- How will connection routing be tested after a deployment change?
- What happens when an elastic node is unavailable or reaches its capacity?
Routing should be tested with representative workloads. A successful connection test alone does not prove that the intended queries are executing on the desired node.
When to Add an Elastic Compute Node
Consider an elastic compute node when performance analysis shows that read activity is competing with primary-node workloads. Strong candidates include recurring reporting windows, dashboard bursts, exploratory analytics, and workloads whose concurrency grows faster than transactional demand.
Before adding capacity, identify the actual bottleneck. High response times can result from inefficient SQL, missing or unsuitable modeling, excessive data transfer, locking, memory consumption, or poorly tuned application behavior. Adding an elastic node will not correct those causes automatically.
Use SAP HANA memory usage as part of the investigation, and compare the observed pressure with the workload pattern. If the issue is a general capacity shortage rather than read contention, review the available SAP HANA Cloud scaling options instead of selecting an elastic node by default.
Provisioning and Administration
Elastic compute nodes are provisioned as part of SAP HANA Cloud instance administration. SAP HANA Cloud Central is the appropriate service-level location for reviewing the instance, changing supported capacity settings, and checking the resulting deployment state.
After provisioning, use SAP HANA database explorer for database-focused validation. Review connections, execute representative tests, inspect workload behavior, and confirm that users and applications still have the required privileges. Database explorer is also useful when you need to examine SQL behavior rather than only the infrastructure state.
A change should have an operational plan covering provisioning time, application routing, validation, monitoring, and rollback. Record which clients use the elastic node and which remain on the primary node so that later performance investigations have reliable context.
Monitoring and Validation
Monitor the primary and elastic nodes as a combined workload system. Compare query response time, throughput, concurrency, memory use, CPU pressure, and workload distribution before and after the change. A lower primary-node load is useful only if end-to-end application performance also improves.
Validate at least three cases: an eligible read query, a transaction that must use the primary node, and a query that is not suitable for elastic execution. Test during realistic concurrency, because routing behavior and contention can differ substantially between an isolated test and a production-like workload.
Set an operational baseline before making changes. Capture representative query durations, peak periods, resource consumption, and error rates. Afterward, compare the same measurements rather than relying on a single dashboard value.
Sizing and Cost Considerations
Choose elastic capacity according to the volume and concurrency of the workload that can actually be routed. A larger node is not automatically better if the application sends most traffic to the primary node or if inefficient SQL dominates the response time.
Evaluate the expected benefit against the additional service cost, provisioning requirements, and operational complexity. Start with measured demand, use a representative test window, and revisit the configuration as data volume and user concurrency change.
Elastic compute nodes should complement, not replace, SQL optimization, data-model improvements, workload scheduling, and sensible application connection management. The best result usually comes from combining targeted capacity with evidence-based tuning.
Practical Decision Checklist
Use this checklist before requesting an elastic compute node:
- Confirm that the primary-node workload is constrained by read-heavy activity.
- Identify the applications and queries that can be routed to an elastic node.
- Check whether SQL, modeling, memory, or connection behavior is the real bottleneck.
- Define the consistency and availability expectations for routed reads.
- Establish baseline performance and resource measurements.
- Provision the node through SAP HANA Cloud Central.
- Validate query routing and database behavior with SAP HANA database explorer.
- Monitor the result and adjust the configuration based on measured demand.
This process keeps the capacity decision connected to a measurable performance objective rather than treating an elastic node as a universal acceleration switch.