# Horizontal Pod Autoscaling (HPA) > Horizontal Pod Autoscaling (HPA) is a built-in Kubernetes mechanism that dynamically adjusts the number of pod replicas based on resource utilization, optimizing how available system resources are leveraged to efficiently handle current operations and tasks. *Source: https://docs.sisense.com/main/SisenseLinux/horizontal-pod-autoscaling.htm* --- Last updated: June 10, 2026 | | | | --- | --- | | [Tier](https://www.sisense.com/pricing/#pricing) | [Deployment](https://docs.sisense.com/main/SisenseLinux/introduction-to-sisense-cloud-managed-services.md#ComparisonofManagedCloudandSelfHosted) | | Enterprise | On-Prem | ## Introduction IMPORTANT: HPA can be enabled on self-managed deployments starting with version L2025.1 SP2. Horizontal Pod Autoscaling (HPA) is a built-in Kubernetes mechanism that dynamically adjusts the number of pod replicas based on resource utilization, optimizing how available system resources are leveraged to efficiently handle current operations and tasks. At a high level, the process can be described in the following steps: 1. Ongoing monitoring of resource consumption. 2. Evaluation of scaling actions against target metrics. 3. Scaling action – adjusting the number of pod replicas by scaling up or down. ![HPA Flow](https://docs.sisense.com/main/Resources/Images/HPA_Flow_789x561.png) The core benefit of HPA is its ability to provide automatic scaling for Kubernetes microservices, ensuring optimal resource utilization based on real-time demand. By continuously monitoring resource usage, such as CPU and memory, HPA helps maintain application responsiveness during peak traffic while minimizing resource waste during periods of lower activity. This automated scaling improves application reliability, optimizes infrastructure costs, simplifies management, and enables organizations to efficiently handle fluctuating workloads without manual intervention. For more information, see: - [HPA Walkthrough](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) - [HPA](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) ## How HPA Works ### Core Components - **HorizontalPodAutoscaler** - A Kubernetes API object that defines the scaling behavior for a specific workload. It specifies the target resource metrics and the desired range for the number of replicas, including conditions for scaling up or down, as well as minimum and maximum replica limits. - **Metrics Provider** - The source of metrics used by the system to determine whether pod replicas should be scaled up or down. This can be the native Kubernetes Metrics Adapter ([Metrics Server](https://kubernetes.io/docs/tasks/debug/debug-cluster/resource-metrics-pipeline/#metrics-server)) or a Custom Metrics Adapter. - **Controller Manager** - Runs the HPA controller, which periodically evaluates current resource utilization against the defined scaling thresholds and adjusts the number of replicas accordingly. HPA in Sisense is based on CPU consumption as the primary resource metric for scaling decisions. ### Supported Services See [Sisense services](https://docs.sisense.com/main/SisenseLinux/sisense-linux-services.md) for a list of all services that support HPA. Note: Do not create scaling configuration files in services which are not included in the list. They are not certified by Sisense, and can lead to unpredictable behavior. ## Configuration Note: In order to avoid overload, the query pod HPA settings should correlate with the number of EC-qry replicas. ### HPA Settings - `minReplicaCount` - Defines the minimum number of pod replicas that must always be running. Even if workload demand is low, the system will not scale below this value to ensure baseline availability. - `maxReplicaCount` - Defines the maximum number of pod replicas that HPA can scale up to. This prevents excessive scaling, ensuring that resource usage and costs remain controlled. - `stabilizationWindowSeconds` - Specifies the cooldown period (in seconds) that HPA waits before applying another scaling action. This prevents rapid fluctuations (scaling up and down too frequently), ensuring stable operations. - `pollingInterval` - Determines how often (in seconds) HPA checks resource metrics (e.g., CPU, memory) to decide whether scaling is needed. Frequent polling provides more responsive scaling but may increase system overhead. - `scaleUpPercent` - Defines the CPU utilization threshold that triggers the Horizontal Pod Autoscaler (HPA) to scale up pod replicas. The following example shows how these settings work together: [Copy](javascript:void(0);) ```  autoscaling:     minReplicaCount: 2     maxReplicaCount: 20     stabilizationWindowSeconds: 300     pollingInterval: 30     scaleUpPercent: 700 ``` - The system starts with at least 2 pods and can scale up to 20 pods. - HPA checks resource usage every 30 seconds (`pollingInterval`). - When the average CPU utilization of pods reaches 700% (0.7 CPU, or 70% of a single CPU core), HPA recognizes increased demand and triggers scaling actions. - Scaling up/down actions will not occur more frequently than every 5 minutes (`stabilizationWindowSeconds`) to prevent instability. ### Sample Configuration The configuration is mostly common to all supported services and has different values depending on whether it is a [single or multi node deployment type](https://docs.sisense.com/main/SisenseLinux/planning-your-configuration.md). [Copy](javascript:void(0);) ``` ## Sisense chart extra values ## Single node sample: service:   autoscaling:     minReplicaCount: 1     maxReplicaCount: 10     stabilizationWindowSeconds: 300     pollingInterval: 30     scaleUpPercent: 700 ## Multi node sample: service:   autoscaling:     minReplicaCount: 2     maxReplicaCount: 30     stabilizationWindowSeconds: 300     pollingInterval: 30     scaleUpPercent: 700 ``` For the following services, the configuration differs from the common configuration: Important Note: It is strongly recommended to use the Sisense default configuration, as it provides certified, optimized, and constantly improved settings for optimal performance. [Copy](javascript:void(0);) ``` exporter-xlsx:   autoscaling:     minReplicaCount: 1     maxReplicaCount: 30     stabilizationWindowSeconds: 300     pollingInterval: 30     scaleUpPercent: 700 nlq-compile:   autoscaling:     minReplicaCount: 1     maxReplicaCount: 20     stabilizationWindowSeconds: 300     pollingInterval: 30     scaleUpPercent: 5600 nlq-rt:   autoscaling:     minReplicaCount: 1     maxReplicaCount: 20     stabilizationWindowSeconds: 300     pollingInterval: 30 ## depending on the deployment size - small or large (cluster_config.yaml)     small:       scaleUpPercent: 2100     large:       scaleUpPercent: 3500 query:   autoscaling:     minReplicaCount: 1     maxReplicaCount: 20     stabilizationWindowSeconds: 300     pollingInterval: 30 ## depending on the deployment size - small or large (cluster_config.yaml)     large:       scaleUpPercent: 3500     small:       scaleUpPercent: 2100 translation:   autoscaling:     minReplicaCount: 1     maxReplicaCount: 20     stabilizationWindowSeconds: 300     pollingInterval: 30 ## depending on the deployment size - small or large (cluster_config.yaml)     large:       scaleUpPercent: 3500     small:       scaleUpPercent: 2100 ``` ## Enablement Note: When [installing Sisense using Provisioner and Helm](https://docs.sisense.com/main/SisenseLinux/installing-sisense-using-provisioner-and-helm.md), you can also configure the `installer-values.hpa.enabled` HPA parameter to `true` or `false` (default: `false`). To enable HPA on your deployment: 1. Enable HPA in the yaml configuration file (i.e., *single\_config.yaml*, *cluster\_config.yaml* etc.): set `hpa.enabled` to `true`. 2. Modify the HPA Settings: Sisense has a default configuration that is continuously tuned based on performance insights and feedback from all Managed Cloud customers. If the configuration in the deployment file is left empty, the default settings will be applied automatically. Important Note: It is strongly recommended to use the Sisense default configuration, as it provides certified, optimized, and constantly improved settings for optimal performance. However, if you need to override the default configuration, you can do so by updating the */installer/extra\_values/helm/sisense.yml* file in the *extra\_values* folder for each service. For example, in Galaxy, you can configure it as follows: - Single node: [Copy](javascript:void(0);) ``` galaxy:   autoscaling:     minReplicaCount: 1     maxReplicaCount: 10     stabilizationWindowSeconds: 300     pollingInterval: 30     scaleUpPercent: 700 ``` - Multi node: [Copy](javascript:void(0);) ``` galaxy:   autoscaling:     minReplicaCount: 2     maxMultiReplicaCount: 30     stabilizationWindowSeconds: 300     pollingInterval: 30     scaleUpPercent: 700 ``` ## Verifying the Deployment Check that the HPA has been created and is functioning correctly: [Copy](javascript:void(0);) ``` kubectl -n sisense get hpa  kubectl -n sisense describe hpa ``` [Copy](javascript:void(0);) ``` [sisense]$ kubectl -n sisense get hpa NAME                   REFERENCE                     TARGETS               MINPODS   MAXPODS   REPLICAS   AGE analyticalengine-hpa   Deployment/analyticalengine   cpu: 1%/700%          2         30        2          47h api-gateway-hpa        Deployment/api-gateway        cpu: 5%/700%          2         30        2          47h configuration-hpa      Deployment/configuration      cpu: 19%/700%         2         30        2          47h exporter-xlsx-hpa      Deployment/exporter-xlsx      cpu: 33%/700%         1         30        1          47h exporting-hpa          Deployment/exporting          cpu: 1%/700%          2         30        2          47h galaxy-hpa             Deployment/galaxy             cpu: 1%/700%          2         30        2          47h identity-hpa           Deployment/identity           cpu: 1%/700%          2         30        2          47h model-graphql-hpa      Deployment/model-graphql      cpu: 1%/700%          2         30        2          47h oxygen-hpa             Deployment/oxygen             cpu: 1%/700%          2         30        2          47h pivot2-be-hpa          Deployment/pivot2-be          cpu: 1%/700%          2         30        2          47h query-hpa              Deployment/query              cpu: 2%/2100%         2         30        2          47h reporting-hpa          Deployment/reporting          cpu: 1%/700%          2         30        2          47h translation-hpa        Deployment/translation        cpu: 2%/2100%         2         30        2          47h ``` ## Tuning Recommendations A prerequisite for optimization of the existing configuration is establishing reliable means of monitoring. The suggested monitoring tool is [Grafana](https://docs.sisense.com/main/SisenseLinux/monitoring-sisense-on-linux.md#Grafana). Sisense provides already preset dashboards that can be used to adjust the configuration. It is also possible to use official [HPA Grafana dashboards](https://grafana.com/grafana/dashboards/22128-horizontal-pod-autoscaler-hpa/). Note: If the current configuration is not suitable for your needs or you observe unexpected behavior, Sisense recommends that you open a ticket with Support so that the official default configuration can be adjusted. This ensures that certified and supported settings will be used. ## FAQ [When and who should enable it?](#) HPA is enabled by default on the [Sisense Managed Cloud](https://docs.sisense.com/main/SisenseLinux/introduction-to-sisense-cloud-managed-services.md) and is managed by Sisense Cloud team. For self-hosted deployments we recommend having it enabled and using the default configuration by keeping the*/installer/extra\_values/helm/sisense.yml* file empty in the *extra\_values* folder . You can validate the decision based on CPU consumption in the [performance metrics](https://docs.sisense.com/main/SisenseLinux/monitoring-sisense-on-linux.md). For more information, see [Using Grafana to Troubleshoot Performance Issues](https://community.sisense.com/t5/knowledge-base/using-grafana-to-troubleshoot-performance-issues/ta-p/9591). [Is HPA available only for AWS deployments?](#) No. Although commonly utilized in AWS environments, Sisense's HPA implementation is cloud-agnostic and works seamlessly across all Kubernetes-supported environments. For detailed information on supported environments and configurations, refer to Sisense's [Minimum Requirements for Linux Environments](https://docs.sisense.com/main/SisenseLinux/linux-minimum-requirements.md). [How does HPA correlate with Data Groups configuration in Sisense?](#) Data Groups in Sisense enables administrators to allocate and manage resources for ETL and querying of ElastiCubes by grouping them based on priority, usage patterns, or other criteria. HPA operates at the application level, automatically adjusting the number of pod replicas based on real-time metrics. It is suggested to balance properly to prevent bottlenecks when querying is autoscaled, but data groups settings are limited. For more details on configuring Data Groups, see [Creating Data Groups](https://docs.sisense.com/main/SisenseLinux/creating-data-groups.md). [Is this for single or multi node?](#) It is for both. We suggest using the default configuration which dynamically defines scale for single and multi node deployments. [Is the Cloud team monitoring when pods scale up or is this just a 'set it and forget it'?](#) `horizontalPodAutoscalerConfig` has the policy which defines when the amount of pod replicas should be scaled up and down. The Cloud team constantly monitors and tunes the configuration for the best results. There is no action needed from the customer. If unexpected behavior is observed, create a ticket for the Support team. [Is there a config that a customer or Support can engage?](#) HPA configuration is established on the helm chart level used for the deployment. Therefore, there is no publicly available config that can be changed in real time. [Can HPA configuration be overriden with side by side upgrades?](#) Side by side upgrades do not override the new HPA configuration, as it can be changed only via `extra_values/helm configuration`. [Is native HPA or KEDA used for autoscaling?](#) While Sisense has settings for both, Keda was added somewhat experimentally for a few customers, while HPA is the primary autoscaling mechanism that is being continually enhanced.