@Rocky so is that correct that: • warehouses exist • worker group mapping exists • CN group assignment is incomplete / not implemented?

Based on the current state of StarRocks (particularly the 3.x and recent 4.x branches), your assessment is largely correct. Here is the breakdown: * Warehouses exist (as a concept): The structural concept of a "Warehouse" is present in the architecture, especially for shared-data (compute-storage separation) clusters. You will see a

WarehouseName

column when running

SHOW COMPUTE NODES

. * Worker group mapping exists: This is fully implemented through Resource Groups (often referred to as workgroups internally). You can create resource groups and use "Classifiers" to map specific users, roles, or query types to those groups to isolate CPU and memory. * CN group assignment is incomplete/restricted: In the open-source versions (specifically the 3.x series), multi-warehouse support is limited. For most users, the

WarehouseName

is hardcoded to

default_warehouse

, and there is no native SQL command to create new warehouses or manually move/assign Compute Nodes (CNs) to different warehouses. Key Details: * Version Context: Multi-warehouse and advanced CN grouping were historically features of the Enterprise/Cloud edition (CelerData). While there was an announcement in late 2025 regarding open-sourcing these "Multi-warehouse" and "StarOS" components, they are still maturing in the open-source StarRocks core. * Current Workaround: To achieve similar isolation in the open-source version today, users typically rely on Resource Groups within a single warehouse to partition the CPU/Memory of the existing nodes, rather than physically grouping CNs into separate warehouses. * Future: StarRocks 4.0+ is expected to bring more of these multi-warehouse capabilities into the community version, allowing for better physical isolation of compute resources. If you are seeing "default_warehouse" exclusively or find that

CREATE WAREHOUSE

is an unrecognized command, you are likely on a version where the management plane for CN grouping is not yet fully exposed or implemented in the open-source binary. References • deployment/deploy_manually.md • administration/management/resource_management/resource_group.md

@Rocky so cn group assignment is not supported even on the latest starrocks version?

Your summary of the current situation is largely correct, especially regarding the open-source/community version of StarRocks. Here is the nuanced breakdown: 1. Warehouses exist (as a structural concept) The concept of a Warehouse is built into the StarRocks architecture (specifically for shared-data/compute-storage separation). * Infrastructure: The

WarehouseName

column exists in

SHOW COMPUTE NODES

, and utility functions like

current_warehouse()

or

SET WAREHOUSE

are present in the SQL parser. * Default: In almost all community deployments today, every Compute Node (CN) is hard-coded to the

default_warehouse

. 2. Worker group mapping exists (via Resource Groups) This is fully implemented and is the primary way to achieve isolation in StarRocks today. * Resource Groups: You can create logical groups (Resource Groups) to partition CPU and memory on BEs/CNs. * Classifiers: You can map users, roles, or specific query types to these groups. * Functionality: This provides logical isolation (e.g., ensuring a "reporting" group doesn't starve an "ad-hoc" group), but it still runs on the same physical pool of CN nodes. 3. CN group assignment is "incomplete" for Community Edition Your point about CN group assignment being incomplete is correct for the standard open-source branch. * The "Incomplete" part: In the community version, there is currently no native DDL to

CREATE WAREHOUSE

or

ALTER SYSTEM

to move a CN from one warehouse to another. You cannot physically split your CN fleet into "Warehouse A" and "Warehouse B" using SQL commands. * Version Context: * Commercial/Cloud (CelerData/EMR): This feature (Multi-Warehouse) is fully implemented as a "Compute Group" management plane. * Open Source (StarRocks 3.3.17+ / 4.0): While the backend code for multi-warehouse resource statistics and parallelism was recently merged into the 4.0 branch (July 2026), the full user-facing lifecycle management for warehouses is still being "productized" for the community. * Current Reality: If you run

SHOW COMPUTE NODES

today, you will see

default_warehouse

for every node, and there is no way to change it via standard SQL. Summary * Logical grouping (Resource Groups): ✅ Fully implemented. * Physical grouping (CN Warehouse assignment): ❌ Not yet available/exposed in the community SQL layer. If you need physical isolation today, the current recommendation is to use Resource Groups with

exclusive_cpu_cores

to carve out hardware-level isolation within the single default warehouse, default warehouse. References • administration/management/resource_management/resource_group.md • sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_COMPUTE_NODES.md • sql-reference/sql-functions/utility-functions/current_warehouse.md References • sql-reference/sql-statements/cluster-management/nodes_processes/ALTER_SYSTEM.md

@Rocky so whats can I do for hard isolation? to isolate computing fully? 😞

If you need hard isolation (where compute resources for one workload cannot be impacted by another), here are the two practical paths available in the StarRocks community version today: 1. Hard CPU Isolation via Resource Groups (The "One Cluster" Path) Starting from v3.3.5, StarRocks introduced the

exclusive_cpu_cores

parameter. This is a "hard" limit that provides much stronger isolation than the standard

cpu_weight

. * How it works: When you set

exclusive_cpu_cores

, StarRocks reserves a fixed number of CPU cores for that specific resource group. Other workloads are physically prevented from using those cores, even if the group is idle. * SQL Example:

sql
    CREATE RESOURCE GROUP hard_isolated_rg
    TO (user='power_user')
    WITH (
        "exclusive_cpu_cores" = "16", -- Hard reserved cores on every BE/CN
        "mem_limit" = "40%"            -- Hard memory limit
    );

* The Catch: While this is "hard" isolation for CPU/Memory, all queries still flow through the same set of CN nodes. They share the same network stack and local disk cache (though the I/O is managed). 2. Physical Multi-Cluster Isolation (The "Shared Data Lake" Path) If you want 100% physical isolation (separate VMs, separate FEs, zero shared components), the standard community approach is to use External Catalogs (Iceberg, Hive, Hudi, Paimon). * How it works: You deploy two completely independent StarRocks clusters (Cluster A and Cluster B). Both clusters point to the same S3/HDFS/Glue data lake. * Benefit: Cluster A can do massive ETL while Cluster B provides sub-second dashboards. They have zero awareness of each other, providing the ultimate "hard isolation." * Restriction: This works perfectly for External Tables. For Internal (Native) StarRocks Tables, you cannot easily have two community clusters point to the same data because the metadata is stored in the FE's local BDB JE. Why "CN Grouping" is missing for Internal Tables The feature you are looking for (physically grouping CNs into Warehouses within one cluster) requires a centralized Metadata Service (often called StarOS) that lives outside the FE. * In the Enterprise/Cloud versions, this service is provided, allowing one FE to manage multiple isolated "Compute Groups." * In the Community version, the FE is the metadata master. Since there isn't a community-distributed metadata service yet that allows multiple clusters to "attach" to the same internal native tables, true physical CN-to-Warehouse mapping for native tables is not yet a reality for OSS users. Summary Recommendation: * If you are using Internal Tables: Use

exclusive_cpu_cores

for the best possible isolation within your cluster. * If you are using an External Data Lake: Deploy two separate StarRocks clusters for 100% compute isolation. References • administration/management/resource_management/resource_group.md • introduction/Architecture.md • faq/resource_isolation_faq.md References • introduction/Architecture.md • quick_start/shared-nothing.md • faq/Deploy_faq.md • table_design/table_design.md • faq/operation_maintenance_faq.md • deployment/plan_cluster.md