# Set Resource Limits

The **Resource Governance** (RG) feature restricts the resources that queries can use by grouping the queries into “pools” and then assigning quotas of resources to these pools. This allows you to prevent non-critical workloads from overloading the system. You can use resource pools to prevent a user’s query from making the system unusable for others connected to the database.

Resource limits are for all databases in a cluster. It is not possible to set limits at the database level.

By default, users are allowed to create up to 10 resource pools. However, this limit can be increased upto 50 by setting the `max_user_rg_pools` variable. An important consideration when setting this variable is that, increasing the number of resource pools beyond the number of available CPU cores can lead to performance degradation and increased query latency. This is because CPU resources are divided based on affinity, with each resource pool receiving at least one dedicated core. When the number of pools exceeds the number of cores, a single core may have to manage queries from multiple pools, leading to excessive context switching and reduced performance.

The resources controlled by resource pools are:

* **Concurrency:** Limits the total queries that can run simultaneously in any given pool. For example, if you define a pool with a max concurrency of 25 and there are 4 aggregators in the cluster, each aggregator will only allow FLOOR(25/4)=6 queries to run at a time in that pool. The rest of the queries will be queued in FIFO order. Only queries are queued to limit concurrency.
* **CPU:** Limits the percentage of available CPU capacity assigned to a pool. It includes both aggregator and leaf node CPUs.

  * On bare‑metal or VM‑based deployments, this corresponds to the host CPU capacity visible to the node.
  * On Kubernetes‑based deployments, the available CPU capacity is determined using the minimum of the host cores and the `cgroup` CPU limit for the container. Resource Governance then applies pool CPU percentages against this effective (cgroup‑aware) capacity.

  For example, if your leaf nodes have 100 cores, and Pool A has 20% as its CPU limit, 20 cores will be assigned to Pool A on each leaf node.

  * On a bare‑metal deployment, if your leaves have 100 cores and Pool A has 20% as its CPU limit, approximately 20 cores will be assigned to Pool A on each leaf node.
  * On a Kubernetes deployment where the host has 100 cores but the cgroup limit is equivalent to 40 cores, and Pool A has 20% as its CPU limit, Pool A can use up to 20% of 40 cores on each leaf node.

  All queries running in Pool A will share the same 20 cores between themselves. The OS will manage context switching between the queries.

  There are two variants:

  2. **SOFT\_CPU\_LIMIT\_PERCENTAGE:** Pool B can temporarily use cores from Pool A when Pool A is underutilizing its CPU reservation. As a result, Pool A might temporarily have less than 20 cores at its disposal but there will be overall better performance.

  3. **HARD\_CPU\_LIMIT\_PERCENTAGE:** Pool B can’t use cores from Pool A and hence the performance is more deterministic.

  Each pool can have both SOFT\_CPU\_LIMIT\_PERCENTAGE and HARD\_CPU\_LIMIT\_PERCENTAGE set. Which mode the resource governor is running in is determined by the variable `resource_governor_cpu_limit_mode`. To display it, execute:
  ```sql
  SELECT @@resource_governor_cpu_limit_mode;
  ```
    All pools run in either the hard or soft mode, i.e. all pools have the same mode.
* **Memory:** Limits the total leaf node memory that all queries running in a specific pool can together use.  Which queries get killed due to lack of memory is determined by the values set for `QUERY_MEMORY_PERCENTAGE` and `MEMORY_PERCENTAGE` at the time of the resource pool creation. Any single query that uses more memory than is allocated via `QUERY_MEMORY_PERCENTAGE` will be killed. Further, the total memory of all queries running in the resource pool cannot exceed the value of `MEMORY_PERCENTAGE`. Any queries that exceed that limit will be killed.
* **Query Timeout:** This can be specified to kill queries if they have been running or queued for a long period of time.

For more information on the above settings, see [CREATE RESOURCE POOL](https://docs.singlestore.com/db/v9.1/reference/sql-reference/resource-pool-commands/create-resource-pool.md).

Each client connection is assigned to a resource pool that specifies some (or all) of these limits.

> **📝 Note**: Resource limits also apply to any `LOAD DATA` queries, internal sampling queries, or stored procedures that are run by a user within a given resource pool.

To see the status of queries running in pools run:

```sql
SELECT * FROM INFORMATION_SCHEMA.MV_RESOURCE_POOL_STATUS;
```

To see the details about properties of pools run:

```sql
SELECT * FROM INFORMATION_SCHEMA.RESOURCE_POOLS;
```

To see how much memory a query is using, check `MEMORY_BS` in `INFORMATION_SCHEMA.MV_ACTIVITIES`.

To see the total memory allocated (not reserved) by a node currently use:

```sql
SHOW STATUS EXTENDED LIKE '%TOTAL_SERVER_MEMORY%';
```

Related to setting resource limits through governance is the concept of workload management. Workload management is a component of SingleStore that automatically manages cluster workloads to ensure that they are matched with available system resources. For more information, see [Workload Management](https://docs.singlestore.com/db/v9.1/user-and-cluster-administration/use-the-workload-manager-and-set-resource-limits/use-the-workload-manager.md).

## In this section

* [Resource Pool Basics](https://docs.singlestore.com/db/v9.1/user-and-cluster-administration/use-the-workload-manager-and-set-resource-limits/set-resource-limits/resource-pool-basics.md)
* [Work with Resource Pool Engine Variables](https://docs.singlestore.com/db/v9.1/user-and-cluster-administration/use-the-workload-manager-and-set-resource-limits/set-resource-limits/work-with-resource-pool-engine-variables.md)
* [Administer Default Resource Pools](https://docs.singlestore.com/db/v9.1/user-and-cluster-administration/use-the-workload-manager-and-set-resource-limits/set-resource-limits/administer-default-resource-pools.md)
* [Select a Resource Pool Dynamically](https://docs.singlestore.com/db/v9.1/user-and-cluster-administration/use-the-workload-manager-and-set-resource-limits/set-resource-limits/select-a-resource-pool-dynamically.md)

***

Modified at: March 2, 2026

Source: [/db/v9.1/user-and-cluster-administration/use-the-workload-manager-and-set-resource-limits/set-resource-limits/](https://docs.singlestore.com/db/v9.1/user-and-cluster-administration/use-the-workload-manager-and-set-resource-limits/set-resource-limits/)

(An index of the documentation is available at /llms.txt)