Hello I see that StarRocks Download page only shows Download in compressed format. even though StarRocks images are available on dockerhub as well as also mentioned in quick start. Is it not recommended to use containers in production? @Rocky

Hi! I'm Rocky. That's a great question! It is absolutely recommended and supported to use containers and Kubernetes for StarRocks in production. In fact, many of our users prefer this for cloud-native environments. Here is why you see the compressed formats (tarballs) on the download page and how it relates to production use: 1. Deployment Flexibility The download page primarily highlights the binary packages because they are the foundation for manual deployments on Bare Metal or Virtual Machines. However, StarRocks is designed to be environment-agnostic. In the official Deployment Overview, StarRocks explicitly lists three primary production paths for a "Shared-nothing" cluster: * Manual Deployment: Using the tarball/compressed packages (common for traditional on-prem/VMs). * Kubernetes with Operator: (Recommended for K8s) Using the StarRocks Operator. * Kubernetes with Helm: Using Helm Charts. 2. When to Use Containers in Production If you are moving to production with containers, we strongly recommend using Kubernetes managed by the StarRocks Operator. The Operator handles complex tasks like: * Automating deployment and upgrades. * Managing High Availability (electing FE leaders). * Scaling BE/CN nodes up and down safely. 3. Production Best Practices for Containers If you decide to use containers (Docker or Kubernetes) for production, keep these points in mind to ensure performance: * Resource Allocation: StarRocks is a high-performance engine. Ensure your containers have enough resources. A common production recommendation for a BE (Backend) node is 16 vCPU and 64GB RAM. * Persistence: You must use Persistent Volumes (PVs) for both FE (for metadata) and BE (for data storage). Do not rely on the container's ephemeral storage. * Host Network: For maximum performance and to avoid port mapping overhead, many production users run the pods in

hostNetwork: true

mode. * Architecture: If you are using ARM-based CPUs, the documentation actually recommends using the Docker images as the primary way to get the necessary deployment files. Summary: The tarball is just one way to get the software. If your infrastructure is container-based, using the StarRocks Operator on Kubernetes is a first-class, production-ready choice! Let me know if you'd like more details on setting up the Operator! References • faq/Deploy_faq.md • deployment/deployment_overview.md • deployment/plan_cluster.md • quick_start/shared-nothing.md • deployment/deployment_prerequisites.md • deployment/prepare_deployment_files.md

We'll be using AWS Is 3 r8g.2xlarge works as FE? for BE (actually CN nodes) we'll using is4gen.8xlarge CN counts will start from 2 and maybe increaese it 8 to 10 as our dataand usage may grow @Rocky

That sounds like a solid plan for an AWS deployment. Here is a breakdown of how those instance types align with StarRocks' recommendations: 1. FE Nodes (3x r8g.2xlarge) * Suitability: Excellent. * Specs: 8 vCPUs (8 physical cores on Graviton) and 64 GB RAM. * Analysis: StarRocks recommends at least 8 cores and 16 GB RAM for FE nodes. Your choice of 64 GB RAM is very generous and will provide a large buffer for metadata management and complex query planning, especially as your cluster scales to 10+ nodes. * High Availability: Having 3 nodes is the standard for a production environment to ensure a Leader election can always occur via the Raft protocol. 2. CN Nodes (is4gen.8xlarge) * Suitability: Excellent for Shared-Data Architecture. * Specs: 32 vCPUs, 192 GB RAM, and ~3.75 TB of local NVMe SSD storage. * Analysis: * CPU/RAM: This is well above the recommended minimum (16 cores/64 GB). It provides plenty of compute power for massive parallel processing (MPP). * Storage (Cache): The

is4gen

family is particularly good because of the local NVMe SSDs. In a shared-data (CN) architecture, StarRocks uses local storage for Data Caching. Having fast local NVMe will significantly speed up queries by reducing the need to fetch data from S3 repeatedly. * Scaling: Starting with 2 nodes is fine for development/small scale, but keep in mind that for High Availability, StarRocks usually recommends at least 3 nodes in a backend cluster. Scaling to 8-10 nodes as you grow is a native capability of the CN architecture. 3. Important Considerations for AWS/ARM * Architecture (ARM64): Both

r8g

(Graviton 4) and

is4gen

(Graviton 2) use ARM architecture. StarRocks fully supports ARM, but the standard

.tar.gz

downloads on the website are often x86_64. * Tip: You should use the StarRocks Docker images or extract the ARM64 binaries from the

starrocks/artifacts-ubuntu

or

starrocks/artifacts-centos7

Docker images to ensure you have the correct build for Graviton. * Networking: Ensure these instances are in the same Placement Group if possible, or at least in the same Availability Zone/VPC to minimize latency, as StarRocks is a high-performance MPP database that relies on fast node-to-node communication. * S3 Endpoint: Since you are using CN nodes (Shared-Data), ensure you use an S3 Gateway Endpoint in your VPC to avoid data transfer costs and improve performance between your CNs and your data in S3. Overall, your hardware choices are very well-aligned with high-performance StarRocks requirements! References • faq/Deploy_faq.md • deployment/deployment_prerequisites.md • deployment/prepare_deployment_files.md • developers/mac-compile-run-test.md • developers/build-starrocks/Build_in_docker.md • developers/build-starrocks/build_starrocks_on_ubuntu.md

@Rocky should we move to c8g.2xlarge if you think r8g.2xlarge is overprovisioned?

Moving from an r8g.2xlarge to a c8g.2xlarge is a significant jump in terms of memory reduction. While both have 8 vCPUs, you would be dropping from 64 GB of RAM down to 16 GB. Whether this is a good move depends heavily on your specific workload and which StarRocks component (FE or BE) you are running on these instances. 1. Backend (BE) Considerations For a BE node, 16 GB is generally considered the bare minimum for production. * Memory Usage: StarRocks uses memory for the Page Cache (to speed up queries), intermediate result sets for joins/aggregations, and background processes like compaction. * The Risk: If you move to 16 GB and your queries involve large datasets or complex joins, you are much more likely to encounter "Memory Limit Exceeded" errors or see a significant performance drop because the Page Cache will be too small to be effective. * Recommendation: Check your current memory metrics. If your BEs are consistently using less than 10–12 GB of RAM (including the Page Cache), you might be able to downsize. However, a safer "middle ground" would be the m8g.2xlarge (32 GB RAM), which provides a balanced profile. 2. Frontend (FE) Considerations For an FE node, StarRocks officially recommends at least 8 cores and 16 GB of RAM. * Metadata: The FE stores metadata in memory. If you have a very large number of tablets or high query concurrency, 16 GB might become a bottleneck. * Verdict: If your current FE memory usage is very low (e.g., under 8 GB), moving to a

c8g.2xlarge

is feasible, but monitor it closely as your cluster grows. How to verify if you are overprovisioned: Before making the switch, I recommend checking these metrics in your StarRocks dashboard or via the leader FE: 1. Check current memory usage:

sql
    SHOW BACKENDS\G

Look at the

MemUsed

column to see how much is actually being utilized. 2. Monitor Page Cache: If your

page_cache_usage

is high and your performance is good, that memory is not wasted—it's preventing slow disk I/O. 3. Check for Compaction: Ensure that memory isn't spiking during background compaction tasks. Summary * Move to

c8g.2xlarge

(16GB): Only if this is a very small development environment or an FE with very little metadata. * Move to

m8g.2xlarge

(32GB): A much safer choice if you want to save costs but keep enough headroom for production stability. * Stay on

r8g.2xlarge

(64GB): Recommended if you have high-performance requirements, large joins, or high data ingestion rates. Rocky's Tip: In OLAP databases like StarRocks, it is usually better to be slightly overprovisioned on RAM than underprovisioned, as memory pressure is the most common cause of query failures and cluster instability. References • deployment/deployment_prerequisites.md • deployment/plan_cluster.md • deployment/environment_configurations.md • faq/Others.md • faq/Deploy_faq.md