@Rocky I have deployed starrocks 4.1.4 using operator helm with 4 FE (c6g.2xlarge), 3 BE (m6gd.xlarge) and auto-scalable CN (mg6d.4xlarge) replicas. I am primarily using starrocks for external glue iceberg and hive catalogs. As per my understanding my queries will run on CN nodes and not on BE nodes, hence I have also set

datacache_enable = false

on BE config but

datacache_enable = true

on CN nodes. Can you give me the usecase of BE pods here, for what all purposes my BE pods will be used and can I use

m6g.xlarge

instead of

m6gd.xlarge

for BE since I have

datacache_enable = false

In StarRocks 4.1.x, even when your primary workload is directed at external catalogs (Iceberg/Hive) and you use auto-scaling Compute Nodes (CN), Backend (BE) pods still perform several critical functions. 1. Use Cases for BE Pods in your setup While CN nodes are designed to be stateless and elastic for Data Lake queries, your BE pods serve as the "anchor" for the following: * Internal Catalog and System Metadata: Every StarRocks cluster has a

default_catalog

. This stores system databases like

information_schema

and, most importantly, the

_statistics_

database. * CBO Statistics Storage: To provide high-performance query planning, the Cost-Based Optimizer (CBO) gathers and stores statistics (min/max, histograms) for your Iceberg and Hive tables. These statistics are stored as tablets on your BE nodes. Without BEs, there is no persistent storage for this metadata in a standard deployment. * Query Execution (MPP Engine): By default, StarRocks utilizes all available backends (both BEs and CNs) to execute query fragments. Unless you have explicitly configured resource groups or scheduling constraints to isolate compute to CNs, your 3 BEs will still participate in scanning and processing external data. * Materialized Views and Ingestion: If you decide to create asynchronous Materialized Views (MVs) to accelerate slow lakehouse queries, the resulting data is stored in the internal catalog on your BEs. * Query Spilling: If a query fragment running on a BE exceeds its memory limit, the BE will "spill" intermediate results to local disk. 2. Can you use

m6g.xlarge

instead of

m6gd.xlarge

? Yes. If you have set

datacache_enable = false

on the BE nodes, you can safely switch to

m6g.xlarge

(EBS-only). * Why

m6gd

was chosen: The

d

suffix indicates local NVMe SSDs. These are highly recommended for StarRocks' Data Cache (Block/Page Cache) because they provide the low-latency, high-IOPS performance required for caching remote lakehouse data. * Switching to `m6g`: Since you have disabled the cache on BEs, you are not utilizing the local NVMe for its primary purpose. Your BEs will instead use EBS (e.g., gp3) for logs and the small amount of system metadata. * Performance Trade-off: The only risk is during Query Spilling. If your queries are extremely heavy and force spilling to disk, the

m6g

(EBS) will be significantly slower than the

m6gd

(Local NVMe). However, since your CN nodes (

mg6d.4xlarge

) are much larger and have local disks, they should handle the bulk of the heavy lifting and any necessary caching. Recommendations 1. Restrict Compute to CNs: If you want to ensure your BEs remain idle and don't consume CPU/Memory for queries (effectively making them "Metadata/Stats Nodes"), you can use Resource Groups to bind your external catalog workloads specifically to the CN nodes. 2. Keep

datacache_enable = true

on CNs: You have correctly enabled this. Ensure your

mg6d.4xlarge

instances have their local NVMe disks mounted to the StarRocks storage path to get the best performance for your Iceberg/Hive queries. 3. FE Count: You mentioned 4 FEs. While valid, StarRocks uses the Raft protocol for metadata consensus, which works best with odd numbers (e.g., 3 or 5). A 4-node cluster has the same fault tolerance as a 3-node cluster (it can only survive 1 node failure), so 3 FEs is usually preferred to save costs unless you need the extra read-concurrency of a 4th observer. References • administration/management/logs.md • table_design/table_design.md • introduction/Architecture.md