@Rocky Can the same group of FEs connect to both shared data and shared nothing modes?

No, the same group of FEs (Front-ends) cannot connect to or manage both shared-data and shared-nothing modes simultaneously. According to the StarRocks documentation: * Run Mode is Mutual Exclusive: A StarRocks cluster must operate in either

shared_data

or

shared_nothing

mode. This is determined by the

run_mode

parameter in the FE configuration (

fe.conf

). * No Mixed Deployment: You cannot adopt both modes for a single cluster. Mixed deployment is explicitly unsupported. * Immutable Configuration: Once a cluster is deployed, you should not change the

run_mode

. Changing it after deployment will cause the cluster to fail to restart, as the transformation between these modes is not supported. If you need both architectures, you would need to maintain two separate clusters—each with its own group of FEs and BEs/CNs. References • administration/management/FE_configuration.md • quick_start/shared-data.md • deployment/shared_data/azure.md

@Rocky this is true even when using starrocks k8s operator?

Yes, this is still true when using the StarRocks Kubernetes Operator. The operator manages clusters based on the same underlying architecture and configuration rules. Even in a Kubernetes environment: 1. Single Mode per Cluster: A single

StarRocksCluster

Custom Resource (CR) represents one cluster, which must be either

shared_data

or

shared_nothing

. You cannot define both modes within the same FE group or CR. 2. Explicit Limitations: The documentation for shared-data clusters on Kubernetes specifically states that "Mixed deployment of shared-nothing and shared-data mode is not supported" for both VM and Operator-based deployments. 3. Run Mode Immutability: Just like manual deployments, the

run_mode

is set in the FE configuration via the operator. Once set, it cannot be changed, and the operator does not support managing a "hybrid" metadata state where some data is shared and some is local. If you need both modes, you must deploy two separate

StarRocksCluster

resources (two distinct clusters), each with its own dedicated group of FEs. References • deployment/shared_data/feature-support-shared-data.md • administration/management/FE_configuration.md References • administration/management/FE_configuration.md • deployment/shared_data/feature-support-shared-data.md • deployment/shared_data/minio.md • deployment/shared_data/s3.md

@Rocky but i found an article saying - "StarRocks offers Shared-Nothing (BE nodes with local storage and compute) and Shared-Data (stateless CN nodes backed by object storage with local caching) architectures. StarRocks Kubernetes Operator’s StarRocksCluster CRD supports both using starRocksBeSpec and starRocksCnSpec, enabling hybrid deployments in a single cluster. Our production deployment combines both modes within the same cluster: CN nodes provide elastic, stateless compute for fact table scans against data in Amazon S3 using AWS Glue Catalog, while BE nodes store indexed dimension tables on persistent EBS volumes for accelerated join performance. CN nodes scale freely for burst demand with no data movement; BE nodes remove S3 round trips for the dimension lookups that dominate our join-heavy financial queries. The StarRocks query planner routes each workload to the appropriate tier automatically." how true is this ?

The quote you found is accurate in its description of a specific, powerful deployment pattern, but it uses the terms "Shared-Data" and "Shared-Nothing" to describe node roles and storage access rather than the cluster-wide

run_mode

configuration. Here is the technical breakdown of how this works: 1. The "Hybrid" Architecture While a StarRocks cluster has a single global

run_mode

(typically set to

shared_nothing

in this scenario), the StarRocks Kubernetes Operator allows you to define both

starRocksBeSpec

and

starRocksCnSpec

within the same

StarRocksCluster

Custom Resource (CR). * BE Nodes (Shared-Nothing Role): These nodes manage local persistent storage (like EBS volumes). They are used to host "internal" StarRocks tables (sharded and replicated across BEs). This is ideal for dimension tables or high-performance hot data where you want to eliminate network overhead and use local indexing. * CN Nodes (Shared-Data Role): These are stateless compute nodes. They do not store internal StarRocks data shards. Instead, they are used to query external data (Data Lakes like S3/HDFS via Hive, Iceberg, or Glue Catalogs). Because they are stateless, they can be auto-scaled (e.g., using KEDA) to handle bursty "fact table" scans from S3 without requiring data rebalancing. 2. Is it "One Mode" or "Two"? Technically, this is a Shared-Nothing cluster that includes Compute Nodes (CN). * In a pure Shared-Data cluster (

run_mode = shared_data

), all internal tables are stored in object storage, and there are no BEs, only CNs. * In the Hybrid/Shared-Nothing cluster described in your quote, the FE group manages a unified metadata space where some tables (internal) live on BEs and others (external) are accessed from S3. The FE query planner automatically routes the "compute-heavy" parts of a join (the fact table scan) to the CN nodes and the "storage-heavy" parts (the dimension lookup) to the BE nodes. 3. StarRocks Kubernetes Operator Support The StarRocks Operator is designed to manage this specific topology. You can indeed deploy a single CR that looks like this:

yaml
apiVersion: <http://starrocks.com/v1|starrocks.com/v1>
kind: StarRocksCluster
metadata:
  name: starrocks-hybrid
spec:
  starRocksFeSpec:
    replicas: 3
  starRocksBeSpec:    # For indexed dimension tables on local storage
    replicas: 3
    storageVolumes:
      - name: be-storage
        storageClassName: gp3
        storageSize: 100Gi
  starRocksCnSpec:    # For elastic S3 fact table scans
    replicas: 5
    autoScalingPolicy: # Often used with KEDA for bursty workloads
      ...

Summary The article you found is correct: you can have one group of FEs managing both BEs and CNs in a single cluster. * BEs provide the "Shared-Nothing" benefits (local performance, indexing). * CNs provide the "Shared-Data" benefits (elasticity, object storage access). * The Operator makes this "hybrid" deployment easy to manage in a single Kubernetes resource. References • introduction/Architecture.md • deployment/deploy_manually.md • Scaling StarRocks on Amazon EKS with KEDA and Karpenter for enterprise OLAP workloads (External Source) References • quick_start/shared-data.md • introduction/Architecture.md • deployment/shared_data/feature-support-shared-data.md • deployment/deploy_manually.md

@Rocky so here shared data is used not to query native starrocks table but external catalogs?

That article describes a conceptual hybrid architecture rather than a mix of the two technical "Run Modes." In StarRocks, there is a technical distinction between the Run Mode (a cluster-wide setting) and the Node Roles (BE vs. CN). Here is how that "hybrid" deployment actually works: 1. The Cluster is technically in "Shared-Nothing" Mode To support BE nodes (which store data on local disks), the cluster's

run_mode

must be set to

shared_nothing

. In this mode: * Internal Tables: Data is sharded and stored on the local disks of BE nodes. * External Tables: You can query data in S3/Data Lakes (Iceberg, Hive, etc.) via External Catalogs. 2. "Shared-Data" is used for the Data Lake (External Catalog) In the scenario you quoted, the term "Shared-Data" is being used to describe the Lakehouse part of the architecture: * CN Nodes (Compute Nodes) are stateless. They don't store internal StarRocks data. * They are used to scan the Fact Tables sitting in S3 (the "Shared Data"). * Because they are stateless, you can use the Kubernetes Operator to scale them up and down instantly (using KEDA) based on how much S3 data you need to query. 3. Why it is called "Hybrid" The deployment is "hybrid" because it uses both node types to get the best of both worlds in a single cluster: * BE Nodes (Local Storage): Used for Internal Tables (like dimension tables). This provides the fastest possible performance for joins because the data is indexed and stored locally on the BEs. * CN Nodes (Elastic Compute): Used for External Catalogs (like S3 fact tables). This provides massive, elastic scale for huge datasets without needing to "load" that data into StarRocks or manage local disk space for it. Summary: Native vs. External To answer your specific question: Yes, in that specific hybrid architecture, the "shared-data" approach is primarily used to query External Catalogs (Data Lakes). If you wanted to store native StarRocks tables in a shared-data way (where the primary copy of the StarRocks table itself lives in S3), you would have to set the cluster to

run_mode = shared_data

. However, in that mode, you cannot have BE nodes with local storage for your dimension tables. The "Hybrid" approach in the article is the most popular way to achieve high performance (local BEs) and high elasticity (stateless CNs for S3) at the same time. References • introduction/Architecture.md • data_source/catalog/catalog_overview.md • deployment/shared_data/feature-support-shared-data.md • Scaling StarRocks on Amazon EKS with KEDA and Karpenter for enterprise OLAP workloads (External Source) References • deployment/deploy_manually.md • deployment/plan_cluster.md • administration/stargo.md