@Rocky Can I have CNs linked with 2 different warehouse tag so that two tenants can use different CNs and their cache doesn't get impacted

In StarRocks (specifically in shared-data mode starting from version 3.3), you can achieve workload and cache isolation using the Multi-Warehouse (also called Compute Clusters) feature. To answer your specific questions: 1. Can a CN be linked with 2 different warehouse tags? No, a single Compute Node (CN) cannot be assigned to more than one warehouse simultaneously. In StarRocks, a warehouse is a logical grouping of specific CN nodes. Each CN belongs to exactly one warehouse at a time. You can verify this by running:

sql
SHOW COMPUTE NODES;

The output includes a

WarehouseName

column, which indicates the specific warehouse that the node is currently assigned to. 2. Achieving Cache Isolation for Tenants If your goal is to ensure that Tenant A's queries do not impact the local data cache of Tenant B, you should assign separate CN nodes to different warehouses. * Why sharing a CN won't work: Even if it were possible to "tag" a CN with two warehouses, both tenants would still be using the same physical disk on that node (

storage_root_path/starlet_cache

). Their data would compete for the same cache space, leading to evictions and performance interference. * The Recommended Setup: * Warehouse A (for Tenant 1): Link specific CN nodes (e.g., CN-1, CN-2). * Warehouse B (for Tenant 2): Link a different set of CN nodes (e.g., CN-3, CN-4). Because CNs are stateless, they both access the same shared storage (like S3), but they maintain their own independent local disk caches. This ensures Tenant A's hot data stays on its assigned CNs without being evicted by Tenant B's activity. Summary of Isolation Isolation Level | Multi-Warehouse Capability Compute Isolation | Yes, queries for different warehouses run on physically different CNs. Cache Isolation | Yes, since each CN has its own local disk for caching, using separate CNs ensures cache isolation. Storage Isolation | No, all warehouses share the same underlying data on remote storage (S3/HDFS/OSS). How to route tenants to different warehouses: Once you have created multiple warehouses, you can route a tenant's queries to their specific resources using: 1. Session Variable:

SET use_warehouse = 'tenant_a_warehouse';

2. Resource Groups: Bind a user or role to a specific warehouse via classifiers. References • sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_COMPUTE_NODES.md • sql-reference/sql-statements/cluster-management/nodes_processes/ALTER_SYSTEM.md • administration/management/Scale_up_down.md

@Rocky is this available in open source

Yes, the Multi-Warehouse (Compute Clusters) feature is available in the open-source version of StarRocks (Apache 2.0 license), starting from version 3.3. However, there is one important technical requirement: Available only in "Shared-Data" Mode The Multi-Warehouse feature is exclusive to the shared-data architecture (storage-compute separation). • In shared-data mode: Data is stored in central object storage (S3, HDFS, etc.), and CN (Compute Nodes) are stateless. This allows you to create multiple logical "warehouses" that all point to the same data but use different compute resources and local caches. • In shared-nothing mode: (The traditional BE-based architecture), compute and storage are coupled on the same nodes, so you cannot create separate compute-only warehouses against the same local data. How to use it in Open Source If you are running StarRocks 3.3+ in shared-data mode, you can use the following SQL commands to manage warehouses: 1. Create a Warehouse:

sql
    CREATE WAREHOUSE tenant_a_wh;

2. Add Nodes to a Warehouse: You link CN nodes to a warehouse by adding them to the cluster and specifying the warehouse.

sql
    ALTER SYSTEM ADD COMPUTE NODE "192.168.1.1:9050" WAREHOUSE tenant_a_wh;

3. Route Queries: Users can switch between warehouses in their session:

sql
    SET use_warehouse = 'tenant_a_wh';

Is there an Enterprise version? While the core Multi-Warehouse functionality is open-source, some commercial vendors (like CelerData) or cloud providers (Alibaba Cloud EMR, Tencent Cloud) may provide additional GUI-based management tools, automated scaling policies, or "Serverless" wrappers around these open-source commands to make them easier to operate at scale. But if you are managing the cluster yourself via SQL/CLI, the capability is fully present in the open-source distribution. References • introduction/Architecture.md • introduction/StarRocks_intro.md • introduction/Features.md • table_design/table_design.md • deployment/plan_cluster.md

@Rocky but I am getting MySQL [(none)]> CREATE WAREHOUSE wh_t1; ERROR 1064 (HY000): Multi-Warehouse is not implemented

The error "Multi-Warehouse is not implemented" occurs because the Multi-Warehouse (Compute Clusters) feature is only available in the shared-data (storage-compute separation) architecture. If you are seeing this error, it means your StarRocks cluster is currently running in shared-nothing mode (the traditional architecture where data is stored on local disks of BE nodes). Why it doesn't work in Shared-Nothing mode In a shared-nothing cluster, data is physically partitioned and stored on specific Backend (BE) nodes. Because the compute and storage are tightly coupled on these nodes, you cannot logically group compute resources into separate "warehouses" to access the same data—the data simply doesn't exist on all nodes. How to verify your current mode You can confirm your cluster's running mode by executing the following command in your MySQL client:

sql
ADMIN SHOW FRONTEND CONFIG LIKE 'run_mode';

* If the result is

shared_nothing

, the

CREATE WAREHOUSE

command is disabled. * The Multi-Warehouse feature requires

run_mode = shared_data

. How to use Multi-Warehouse To use this feature, you must deploy (or redeploy) StarRocks in shared-data mode: 1. Shared Storage: You must have a central storage system (e.g., AWS S3, HDFS, MinIO, or Google Cloud Storage). 2. FE Configuration: In your

fe.conf

, you must set:

properties
    run_mode = shared_data

(Note: You cannot switch an existing shared-nothing cluster to shared-data mode; this must be configured at initial deployment.) 3. Compute Nodes (CN): In shared-data mode, you use CN nodes instead of (or in addition to) BE nodes. These stateless nodes are what you group into warehouses. If you must stay in Shared-Nothing mode If you cannot move to shared-data mode, you can still achieve compute isolation (but not full cache isolation) using Resource Groups: * You can limit the CPU and Memory usage for different tenants/workloads. * However, because data is distributed across all BEs in shared-nothing mode, all queries will still share the same physical BE nodes and their local caches. References • administration/management/FE_configuration.md • deployment/shared_data/s3.md • introduction/Architecture.md • administration/management/resource_management/resource_group.md References • sql-reference/sql-functions/utility-functions/current_warehouse.md • faq/Sql_faq.md • sql-reference/System_variable.md

@Rocky see mysql -h127.0.0.1 -P9031 -uroot -e " SHOW FRONTENDS\G SHOW COMPUTE NODES\G SHOW BACKENDS; SHOW WAREHOUSES\G CREATE WAREHOUSE wh_proof; " *************************** 1. row *************************** Id: 1 Name: 10.127.1.15_9011_1786012388023 IP: 10.127.1.15 EditLogPort: 9011 HttpPort: 8031 QueryPort: 9031 RpcPort: 9021 Role: LEADER ClusterId: 1364628944 Join: true Alive: true ReplayedJournalId: 529873 LastHeartbeat: 2026-08-27 143319 IsHelper: true ErrMsg: StartTime: 2026-08-27 140725 Version: 3.5.20-4d17879 *************************** 1. row *************************** ComputeNodeId: 13003 IP: 10.127.1.7 HeartbeatPort: 9051 BePort: 9061 HttpPort: 8041 BrpcPort: 8061 LastStartTime: 2026-08-06 211750 LastHeartbeat: 2026-08-27 143319 Alive: true SystemDecommissioned: false ClusterDecommissioned: false ErrMsg: Version: 3.5.20-4d17879 CpuCores: 4 MemLimit: 12.658GB NumRunningQueries: 0 MemUsedPct: 30.73 % CpuUsedPct: 0.4 % DataCacheMetrics: Status: Normal, DiskUsage: 9.9GB/10GB, MemUsage: 0B/0B HasStoragePath: true StatusCode: OK StarletPort: 9071 WorkerId: 2001 WarehouseName: default_warehouse TabletNum: 216 *************************** 1. row *************************** Id: 0 Name: default_warehouse State: AVAILABLE NodeCount: 0 CurrentClusterCount: 1 MaxClusterCount: 1 StartedClusters: 1 RunningSql: 0 QueuedSql: 0 CreatedOn: ResumedOn: UpdatedOn: Property: Comment: An internal warehouse init after FE is ready -------------- CREATE WAREHOUSE wh_proof -------------- ERROR 1064 (HY000) at line 6: Multi-Warehouse is not implemented

Based on your output and the error message, here is the clear breakdown of why this is happening and what your options are. 1. Why you see "Multi-Warehouse is not implemented" Although you are running in shared-data mode (verified by your

DataCacheMetrics

and the existence of

default_warehouse

), the specific SQL command

CREATE WAREHOUSE

is currently not available in the standard Open Source (Apache 2.0) build of StarRocks. In the community version, the system is designed to use a single

default_warehouse

that contains all your Compute Nodes (CNs). The ability to logically group nodes into multiple, separate warehouses via SQL is a feature reserved for StarRocks Enterprise or specific managed cloud services (like CelerData, PhoenixAI, or Alibaba Cloud EMR). 2. Verification of your current environment Your

SHOW COMPUTE NODES

output confirms: * Mode: Shared-data (indicated by

DataCacheMetrics

and

WarehouseName

). * Warehouse: Your CN is currently locked to the

default_warehouse

. * Constraint: The "Not implemented" error confirms that your current binary does not support the multi-warehouse DDL. 3. How to achieve isolation in Open Source Since you cannot create a second warehouse to isolate tenants at the physical node/cache level in the open-source version, you have two alternative paths: Option A: Resource Groups (Compute Isolation) You can use Resource Groups to isolate CPU and Memory within your existing CN nodes. This ensures one tenant's heavy queries don't starve another tenant's CPU.

sql
CREATE RESOURCE GROUP tenant_a_rg
PROPERTIES (
    "cpu_core_limit" = "2",
    "mem_limit" = "20%"
);

-- Bind a user to this group
ALTER USER 'tenant_a_user' SET [PROPERTY] 'resource_group' = 'tenant_a_rg';

* Limitation: This provides compute isolation but not cache isolation. Both tenants will still share the same local disk cache on the CN nodes. Option B: Multiple Clusters (Physical Isolation) In the open-source ecosystem, the standard way to get 100% cache and compute isolation between two tenants is to deploy two separate StarRocks clusters pointing to the same object storage (S3/HDFS). * Because StarRocks is shared-data, both clusters can read the same underlying data. * Each cluster will have its own FEs and CNs, meaning they will have completely independent local disk caches. Summary * Can you have CNs linked with 2 warehouse tags? No (nodes belong to exactly one warehouse). * Is

CREATE WAREHOUSE

in Open Source? No, it is currently a commercial/enterprise feature. * Recommended for Open Source: Use Resource Groups for compute isolation, or deploy separate clusters against the same storage for full cache isolation. References • administration/management/FE_configuration.md

@Rocky in open source version, how to not let one tenant impact caching of other tenants then?

In the Open Source version, since the Multi-Warehouse (logical cache isolation) feature is not available, you cannot create separate "cache pools" within a single cluster. All tenants share the same local disk cache on your Compute Nodes (CNs). To prevent one tenant's queries from evicting another's hot data, you have three primary strategies: 1. Hard Isolation: Multiple Clusters (Recommended) Because you are in shared-data mode, your data is already stored in a central object store (S3, MinIO, HDFS). You can deploy two or more independent StarRocks clusters (each with its own FEs and CNs) that point to the same storage volume. * Tenant A uses Cluster 1. * Tenant B uses Cluster 2. * Result: They both see the same data, but Cluster 1's cache is physically separate from Cluster 2's. One tenant's heavy scanning will never evict the other's cache. 2. Table-Level Cache Control If you want to stay within a single cluster, you can use table properties to control which data is allowed to "pollute" the cache. * Disable Cache for Large, Cold Scans: If one tenant performs large scans on "cold" historical data that doesn't need to be fast, disable the cache for those specific tables or partitions:

sql
    ALTER TABLE large_cold_table SET ("datacache.enable" = "false");

* Restrict Cache Duration (TTL): Use

datacache.partition_duration

to ensure only the most recent data stays in the cache. This prevents old data from filling up the cache and evicting other tenants' hot data:

sql
    ALTER TABLE tenant_b_table SET ("datacache.partition_duration" = "1 MONTH");

3. Query-Level Cache Bypass If a specific tenant or query is known to be a "cache-destroyer" (e.g., a one-time full table scan for a report), you can bypass the cache at the session level so their data isn't written to the local disk at all:

sql
SET enable_scan_datacache = false;
-- Run the heavy query here

This ensures the query reads from remote storage directly and leaves the existing local cache untouched. Summary Comparison for Open Source: Strategy | Isolation Level | Complexity | Best For Multiple Clusters | Physical (Hard) | High (extra FEs) | Strict SLAs between tenants. Table Properties | Policy-based | Low | Protecting specific "hot" tables. Session Bypass | Ad-hoc | Low | Batch jobs or one-off large reports. References • deployment/shared_data/feature-support-shared-data.md • deployment/shared_data/s3.md • sql-reference/System_variable.md • deployment/shared_data/minio.md References • deployment/shared_data/feature-support-shared-data.md • deployment/shared_data/hdfs.md • deployment/shared_data/s3.md • introduction/Architecture.md