@Rocky If I assign my application Stream Loading data to the FE (for my PK table) a resource group, will this resource group classification persist to the BE? That is, will the cpu_weight and mem_limit assigned use what is defined within the assigned resource group or once the task reaches the BE, it will use the default_wg resource group for ingestion?

Based on current StarRocks documentation and behavioral design, the short answer is no: Resource group classification (specifically

cpu_weight

and

mem_limit

) does not persist to the BE for Stream Load tasks, even for Primary Key (PK) tables. Here is the detailed breakdown of how this works and why it behaves this way: 1. Classification vs. Enforcement While you can match a Stream Load request to a resource group at the FE (e.g., using a

user

or

role

classifier), this classification is primarily used for monitoring or tracking in the audit logs. For the actual execution on the BE: * Stream Load and Routine Load are currently not managed by the Resource Group scheduler. * The BE execution logic for Stream Load bypasses the Resource Group's resource-limiting mechanisms (

cpu_weight

,

mem_limit

). 2. Default Resource Behavior When a Stream Load task reaches the BE: * CPU: It typically runs in a dedicated thread pool (governed by the BE configuration

enable_streaming_load_thread_pool

) or the general execution pool. It does not adhere to the

cpu_weight

of the assigned resource group. Effectively, it behaves as if it belongs to the

default_wg

or is governed by global system-wide thread limits. * Memory: It uses memory from the BE's global load buffer or general memory pool rather than being restricted to the

mem_limit

percentage defined in a specific resource group. 3. Primary Key Table Context Primary Key tables are particularly resource-intensive during ingestion because the BE must perform primary index lookups and generate delete vectors (the "Delete+Insert" strategy). * Because these tasks are part of the Stream Load internal process, they remain outside the Resource Group's control. * High-concurrency Stream Loading into PK tables can therefore impact other queries in the

default_wg

or other resource groups because the ingestion is not "sandboxed." 4. Comparison with Other Load Types If you require resource isolation for ingestion, consider the following: * Broker Load: Supports Resource Group isolation (since v3.1). * INSERT INTO ... SELECT: Supports Resource Group isolation (since v2.5). * Routine/Stream Load: Currently not supported for resource isolation (as of v3.3/v3.4). Summary Table Feature | Supported in Resource Group? Stream Load | ❌ No Routine Load | ❌ No Broker Load | ✅ Yes (from v3.1+) INSERT INTO | ✅ Yes (from v2.5+) Rocky's Tip: To prevent Stream Load from overwhelming your BE nodes, you should rely on global BE configurations such as

streaming_load_thread_pool_num_min

and

flush_thread_num_per_store

rather than resource groups. If you need strict multi-tenant isolation for large batches, Broker Load is the more robust choice for leveraging Resource Groups. References • administration/management/resource_management/resource_group.md • sql-reference/sql-statements/cluster-management/resource_group/CREATE_RESOURCE_GROUP.md • sql-reference/sql-statements/loading_unloading/STREAM_LOAD.md