Hello, I'd like to find out: • can BE do all that CN can do (querying iceberg lake house and federated queries)? • is it possible to run both CN and BE on bare-metal (only saw an example using the k8s operator)?

@Rocky can you respond to the query in this thread?

I'd be happy to help! However, I don't see any context or a specific question from the thread in your message. Please paste the query or details you're referring to, and I'll do my best to provide an answer based on the StarRocks documentation and community resources.

@Rocky • can BE do all that CN can do (querying iceberg lake house and federated queries)? • is it possible to run both CN and BE on bare-metal (only saw an example using the k8s operator)?

Yes, you can certainly run both on bare-metal, and BE can handle everything a CN can. Here are the details: 1. Can BE do all that CN can do? Yes. In StarRocks, a BE (Backend) node is the superset of a CN (Compute Node). • BEs are the standard nodes used in Shared-nothing architectures. They handle both data storage (for internal StarRocks tables) and query execution. This includes querying external Iceberg lakehouses and performing federated queries across different data sources. • CNs are essentially "stateless" BEs. They have the same MPP (Massively Parallel Processing) compute engine but do not manage local storage for StarRocks tables. They were introduced to facilitate easy scaling (especially in cloud/K8s environments) and are the primary compute units for the Shared-data architecture. In short: Any query a CN can run (Iceberg, Hive, Federated), a BE can also run. In a shared-nothing cluster, your BEs will handle all your Iceberg/federated workloads by default. 2. Can you run both CN and BE on bare-metal? Yes. While many examples highlight the Kubernetes Operator, both node types are fully supported on bare-metal. * Deployment: You use the same binary package for both. The difference lies in the configuration file and the startup script. * To start a BE: Use

conf/be.conf

and run

./bin/start_be.sh

. * To start a CN: Use

conf/cn.conf

and run

./bin/start_cn.sh

. * Mixing Nodes: * In a Shared-nothing cluster (standard), you primarily use BEs. You can add CNs to a shared-nothing cluster to provide extra "compute-only" resources for external queries (like Iceberg) without needing to rebalance local data replicas. * In a Shared-data cluster (where data lives on S3/HDFS), you only use CNs. Summary Comparison Feature | BE (Backend) | CN (Compute Node) Compute Engine | Full MPP Engine | Full MPP Engine External/Federated Queries | Supported | Supported Local Data Storage | Yes (Internal Tables) | No (Stateless) Primary Use Case | Shared-nothing / Performance | Shared-data / Elastic Scaling Bare-metal Support | Yes (

start_be.sh

) | Yes (

start_cn.sh

) For a bare-metal setup, if you are not using the Shared-data architecture (S3/OSS as primary storage), you will likely just deploy BE nodes. If you want a pool of nodes dedicated to external Iceberg queries that you can power on/off easily without affecting data safety, you can add CNs to that same bare-metal cluster. References • data_source/catalog/unified_catalog.md • data_source/catalog/iceberg/iceberg_catalog.md • data_source/External_table.md • data_source/feature-support-data-lake-analytics.md • quick_start/iceberg.md