When StarRocks shared-nothing or shared-data fits your team
Choose shared-nothing when queries depend on fast, predictable local disk I/O and your data volume and team size are stable enough that you are comfortable scaling backend (BE) nodes together with storage. Choose shared-data when you want compute and storage to scale independently, keep the data on object storage such as S3, GCS, Azure Blob Storage, MinIO or HDFS, and can accept that cold data is pulled into a local cache on first access. The main trade-off is simple: shared-nothing keeps data next to compute, which favors latency and simplicity, while shared-data moves data to durable object storage, which favors elasticity and cheaper retention at the cost of cache behavior you must plan around. Shared-data is documented from StarRocks version 3.0 onward, so any shared-data design should start from a 3.x or later release line, and the current 4.1.3 release, published September 17, 2026, is the reference to confirm against before you commit.
Shared-nothing fits teams whose workloads are steady and latency sensitive, such as dashboards that must return in a consistent time, and whose operators already run stateful hosts well. Every BE holds data on local disks, so adding capacity means adding nodes with their storage, and recovery depends on replicas across BEs. Shared-data fits teams with bursty query load, large historical tables that are queried rarely, or a need to add query capacity without rebalancing data. Compute nodes (CNs) are stateless and can be replaced or scaled out, but a cold query that reads from object storage will be slower than the same query against warm local data. Ask your team to measure the working set size against the cache capacity of the CNs before choosing, because a cache that is too small turns shared-data into a remote-read workload.
Whichever model you pick, decide how frontend (FE) nodes will be placed and recovered, since FE handles metadata, query planning and scheduling in both modes. If you plan to run on Kubernetes, the StarRocks operator maintained in the StarRocks Kubernetes operator repository is the deployment path to review, and you should confirm which operator release supports your chosen StarRocks version and Kubernetes version. Kubernetes releases roughly three times a year, so plan an upgrade path for both layers. Confirm with your storage vendor how object storage latency, egress and durability are billed and configured, and write down a recovery test for each model: a BE loss for shared-nothing, and a cache flush plus object storage read for shared-data. Those tests will show you more than the architecture diagram does.
Which workloads suit each deployment model
Shared-nothing deployment fits teams whose data volume and query load are predictable and who are comfortable with storage and compute living together on backend (BE) nodes. In this model, BE nodes both store data and run queries, so the cluster is sized as one unit. The architecture facts do not give sizing numbers, so the reader must measure their own data growth and concurrency before choosing.
- Co-located storage and compute: BE nodes hold data on local disks and do the computation, which keeps the data path short and avoids a remote storage hop for every scan.
- Predictable capacity planning: When growth is steady, adding BE capacity on a known schedule is easier to plan than separating two scaling axes.
- Fewer moving parts: There is no separate object storage tier or cache policy to tune, which can reduce the operating surface for a small platform team.
- Frontend coordination: FE nodes handle metadata, query planning and scheduling, so the team still needs to plan for leader, follower and observer roles.
- Recovery planning: Local disks mean the team owns backup and node replacement procedures for BE data.
Confirm with StarRocks and in your own environment whether your largest tables and peak concurrency fit a fixed BE footprint, and test node loss and rebuild time on representative data.
Shared-data deployment fits teams whose query load rises and falls sharply, such as month-end reporting or seasonal peaks. Stateless compute nodes (CNs) run queries and cache data, while the data itself sits in object storage. Compute can therefore be added or removed without moving the full data set, which is the main reason to choose this model for bursty demand. The supplied facts do not provide scaling thresholds or timings, so those must be tested.
- Separated scaling: CNs can be added for peaks and reduced afterward because they hold no authoritative copy of the data.
- Tiered cache behavior: Hot data is read from memory or local disk cache, and cold data is loaded from object storage into the local cache, so the first query after a scale-out may be slower.
- Kubernetes fit: Teams that already run the StarRocks operator on Kubernetes can express compute changes as cluster changes, subject to the operator's own documentation.
- Cache sizing: Cache capacity determines how often queries reach remote storage, so cache sizing is a performance decision as much as a cost one.
- Cost shape: Object storage charges and cache hardware are separate line items, so the total depends on how often data is read cold.
Confirm the cold-query latency your dashboards can tolerate, and run a burst test that measures the first query after scale-out against your own data.
Teams that already operate S3, GCS, Azure Blob Storage, MinIO or HDFS may find shared-data mode a natural extension of existing storage. The supplied facts say data can live in these systems with compute nodes reading them through the cache. The team's existing storage contracts, durability settings and access controls then become part of the StarRocks design, so the decision is partly an infrastructure decision.
- Reuse of existing storage: Data stays in the object store or HDFS cluster the organization already governs, which can simplify ownership and retention.
- Lakehouse access: StarRocks can query Hive, Iceberg, Delta Lake and Hudi data directly, which matters when those formats already hold the data.
- Storage access configuration: Credentials, endpoints and network paths to the object store must be designed and tested for each environment.
- Recovery boundary: Durability then depends on the storage layer as well as StarRocks, so restore tests must cover both.
- Shared-nothing alternative: If the data is already in a lakehouse and only queried occasionally, a shared-nothing cluster may duplicate storage without adding value.
Confirm with your storage team the supported versions of your object store or HDFS, the latency between compute and storage, and how credentials are rotated and audited.
Shared-data mode suits teams that need several compute pools to read one data set, for example separate reporting, customer-facing and data science workloads. Because the data lives in object storage rather than on any one backend, multiple compute groups can be sized to their own demand. The README also describes resource management for isolating tenants in one cluster, which is relevant when pools must not starve each other. The reader should confirm how isolation behaves in their chosen topology.
- One copy of the data: Compute pools read the same object storage data, avoiding separate copies per team.
- Workload isolation: Resource management in StarRocks can separate tenants, but the boundaries must be tested under peak load.
- Shared cache effects: Pools that touch the same cold data warm caches for each other only if they share cache locality, so cache behavior should be measured per pool.
- Governance of shared access: A single data set raises the stakes of access control and audit, so plan roles and logging early.
- Shared-nothing limit: When every backend owns part of the data, pools cannot share one stored copy in the same way.
Confirm the isolation guarantees your workloads need, and test concurrent pools against the same tables before committing to a topology.
What each architecture is made of
StarRocks splits work across frontend nodes, which hold metadata and plan queries, and either backend nodes or compute nodes, which do the heavy lifting. The cards below cover each component and the external sources a shared-data cluster depends on, so you can check what you will operate before choosing a mode.
FE leader, follower and observer
Frontend nodes manage metadata, accept client connections, plan queries and schedule them. Each FE runs as a leader, follower or observer, and the role determines which nodes vote and which only serve reads. Confirm how many FE nodes you need for quorum and failover in your environment, and plan where they sit relative to your BE or CN pool, since both architectures depend on them.
BE storage and compute together
In shared-nothing deployments, backend nodes both store data on local disks and compute query results. Capacity and compute scale together, so adding throughput usually means adding nodes that also carry data. Recovery depends on replicas held across BE nodes, so check replica counts, disk failure handling and rebalancing time with your own data volumes before go-live.
CN statelessness and local cache
In shared-data deployments, compute nodes run queries and cache data, but they do not own the authoritative copy. Data lives in object storage, so a compute node can be replaced without moving data, while its cache is rebuilt from remote storage. Ask how long cache warm-up takes for your hot tables, since the first queries after a restart read cold data from object storage.
Supported storage backends
Shared-data mode keeps data in AWS S3, Google GCS, Azure Blob Storage, MinIO or HDFS. Your choice sets network paths, egress costs and the access model, so confirm which backend your platform team operates and how it handles credentials, bucket policies and encryption. The same storage tier is the single place where data durability and retention are enforced.
Tiered cache across memory and disk
Shared-data mode caches hot data across memory, local disk and remote storage. Queries read hot data from cache and load cold data from object storage into local cache. Size the local disk and memory tiers against your working set, and measure cold-query latency on realistic workloads instead of assuming cache hit rates.
External lake access for Hive, Iceberg, Delta and Hudi
StarRocks can query Hive, Iceberg, Delta Lake and Hudi tables in place without importing them, so these sources sit alongside native tables in either architecture. This access does not remove the need to place catalogs and storage correctly. Confirm which catalog services and credentials your lakehouse uses, and test that access works from the compute tier you plan to run.
How latency, scaling and cost differ between the two models
The main difference in latency is whether a query reads from local disks or from object storage. In shared-nothing mode, backend (BE) nodes store data on their own disks, so every scan is served from local storage. In shared-data mode, the data lives in object storage such as S3, GCS, Azure Blob Storage, MinIO or HDFS, and stateless compute nodes (CNs) read it through a tiered cache across memory, local disk and remote storage. Queries that hit the cache perform close to local reads. Cold reads, where data must be loaded from object storage into the local cache, are where latency varies. The practical question is your cache hit rate on a representative workload: how much of the hot working set fits in the CN memory and local disk, and how often a dashboard or batch job touches data that has been evicted. The StarRocks architecture documentation at StarRocks docs: Architecture describes the cache tiers; confirm cache sizing and eviction settings against the version you plan to run.
Scaling works differently in the two models. In shared-nothing mode, adding capacity usually means adding BE nodes with disks, and data may need to be rebalanced across them, which takes time and I/O while the cluster serves queries. In shared-data mode, you can add or remove CNs to change query concurrency without moving the stored data, since the data sits in object storage. Storage capacity grows separately, through the bucket. Test this in your environment: measure how long it takes for new CNs to warm their cache and how query latency behaves during that warm-up, because a fresh node serves cold reads until its cache fills. Cost lands in different places. Shared-nothing costs are dominated by instances and attached disks, paid continuously whether or not queries run. Shared-data costs split between compute instances, cache capacity on local disk, and object storage capacity plus request charges, which rise with the number of cold reads and writes. Ask for a quote that separates instance, disk, object storage and request costs, states the assumed cache size, and names who operates the buckets, the Kubernetes cluster and the operator. Any figures should come from your own measured workload, not from a generic estimate.
Shared-nothing and shared-data side by side
This table compares how StarRocks stores data and scales in shared-nothing mode with BE nodes against shared-data mode with stateless CNs over object storage. Read each row as a question to answer for your own workload, and treat the items marked for confirmation as open until the StarRocks documentation or the vendor confirms them for your version.
| Dimension | Shared-nothing (BE nodes with local disks) | Shared-data (stateless CNs over object storage) |
|---|---|---|
| Data location | Data is stored on local disks of backend (BE) nodes, which also compute queries. | Data lives in object storage such as S3, GCS, Azure Blob, MinIO or HDFS, and CNs hold only cache. |
| Compute and storage coupling | Compute and storage are tied together, so adding capacity usually means adding nodes that hold data. | Compute is decoupled from storage, so CNs can be added or removed without moving the stored data. |
| Scaling path | Scale by adding BE nodes with disks and rebalancing data across them. | Scale compute by adding or removing CNs, while storage grows in the object store. Confirm the scaling procedure for your version. |
| Cache behavior | Hot data is already on local disk, so there is no separate remote read path for stored tables. | A tiered cache across memory, local disk and remote storage serves hot data, and cold data loads from object storage into local cache. Confirm cache sizing and warm-up behavior. |
| Recovery and durability dependence | Durability depends on the BE node disks and the replication settings you configure. Confirm replica and recovery procedures in the StarRocks documentation. | Durability depends on the object store and its redundancy settings, and CNs can be replaced because they hold only cache. Confirm how metadata and cache are rebuilt after a CN loss. |
| Kubernetes operator fit | The StarRocks operator in the StarRocks/starrocks-kubernetes-operator repository manages the cluster, but stateful BE pods need persistent volumes and careful storage planning. | CNs are stateless compute pods, which fits Kubernetes scheduling more naturally, while object storage access and credentials need explicit configuration. Confirm operator support for your chosen mode. |
| Operating skills needed | Teams need skills in disk capacity, node replacement and data rebalancing, plus Kubernetes storage if the cluster runs there. | Teams need object storage administration, cache tuning and credential management, in addition to the StarRocks and Kubernetes skills. |
| Cost drivers | Local disk capacity, node count and replication factor drive cost, and they grow together with data volume. | Object storage volume and request charges, CN compute size and cache capacity drive cost. Ask the vendor or your cloud provider for current storage pricing. |
Recovery and running on Kubernetes with the StarRocks operator
The main recovery difference is where the data lives. In a shared-nothing deployment, each backend (BE) node holds its own data on local disks, so losing a BE means the data it held must be restored from replicas or backups before queries over that data run at full capacity. In shared-data mode, the authoritative data sits in object storage such as S3, GCS, Azure Blob Storage, MinIO or HDFS, and a lost stateless compute node (CN) mainly costs you its warm cache. Replacing the CN is faster, but the cache must refill from object storage, so the first queries after recovery can be slower. Confirm with StarRocks, for your version, how replica count, cache warm-up and the metadata held by the frontend (FE) nodes interact during a node loss, and test that sequence before you rely on it.
The StarRocks Kubernetes operator, which is Apache-2.0 licensed and maintained in the StarRocks/starrocks-kubernetes-operator repository, moves the placement and restart work of FE, BE and CN pods into Kubernetes. It does not remove the stateful pieces you still have to protect. The FE metadata, the object storage credentials and the cluster configuration remain your responsibility. Kubernetes runs its own state in etcd, and the kubeadm high availability guide describes stacked or external etcd topologies with at least three control plane nodes behind a TCP load balancer on port 6443. Kubernetes documentation expects an etcd backup plan using etcdctl snapshot save and restores with etcdutl. Secrets for object storage keys are stored unencrypted in etcd by default, so configure encryption at rest, restrict list and watch access with RBAC, and review the Kubernetes Secrets good practices guidance before you store those keys in the cluster.
Before go-live, confirm with StarRocks which operator release supports your StarRocks version, such as the 4.1.3 line published on September 17, 2026, and which Kubernetes versions that operator release supports. Ask for the documented upgrade order for FE, BE and CN pods, and whether a rolling upgrade keeps queries available in shared-data mode. Check which Kubernetes minor version you will run, since the project maintains the three most recent minor releases, and plan upgrades one minor version at a time. Also confirm the etcd backup and restore procedure your platform team will run, who holds the object storage credentials, and how a restore is tested. These items decide whether the operator reduces your recovery effort or only moves it into the cluster.
Upgrades, backups, monitoring and skills for each model
This table compares how each StarRocks deployment model handles upgrade sequencing, backup responsibility, cache and node monitoring, and the team skills it needs. Read each row against your own platform and staffing, since several operational details depend on your environment and StarRocks release. The main takeaway is that shared-data moves data durability to object storage but adds cache behavior and Kubernetes operations to your daily work.
| Operational area | Shared-nothing (BE nodes with local disks) | Shared-data (stateless CNs over object storage) |
|---|---|---|
| Upgrade sequencing | FE and BE nodes are upgraded as a coupled set, so the upgrade plan must cover both node types and their data on local disks. Confirm the rolling upgrade order for your release in the StarRocks release notes. | Compute nodes are stateless, so they can be replaced or restarted with less data movement, but FE and object storage access settings still need a planned order. Confirm the supported upgrade path for your release in the StarRocks documentation. |
| Backup responsibility | Your team owns backups of data on BE local disks, including the schedule, retention and restore testing. Confirm the backup and restore tooling supported for your StarRocks version. | Durable data lives in your object storage bucket, so bucket versioning, replication and lifecycle policies become core controls. Confirm with your storage team how restores of the StarRocks data layout are tested. |
| Restore and recovery testing | A restore rebuilds data on the same class of local disks, so capacity and node replacement planning are central to recovery drills. Test a full restore on a non-production cluster before go-live. | Data survives compute node loss, but cache is rebuilt from object storage, so recovery time depends on cache warm-up and storage throughput. Measure warm-up on your own data before relying on it. |
| Cache monitoring | Little or no tiered cache to monitor, so attention goes to disk usage, tablet health and compaction on each BE. | Monitor cache hit behavior across memory, local disk and remote storage, since cold data loads from object storage into local cache. Confirm which cache metrics your StarRocks version exposes. |
| Node and cluster health | Watch disk health, BE liveness and data balance across nodes, since losing a node affects the data it holds. | Watch CN liveness, FE leader status and object storage latency and errors, since a slow bucket slows queries across every compute node. |
| Kubernetes operations | Running on Kubernetes adds the StarRocks operator and persistent volume handling for BE disks. Confirm operator version compatibility with your cluster. | Running on Kubernetes adds the operator plus credentials for object storage, which must be handled as Kubernetes Secrets. Kubernetes stores Secrets unencrypted in etcd by default, so confirm encryption at rest is configured. |
| Team skills required | Strong skills in disk capacity planning, node replacement and data rebalancing, plus MySQL protocol administration. | Skills in object storage administration, cache tuning, Kubernetes operations and least-privilege IAM, plus MySQL protocol administration. |
How to decide before go-live
This sequence turns the shared-nothing versus shared-data question into evidence you can take to a sign-off meeting. Each step produces a written artifact, so the architecture choice rests on your workload, storage path and tested cache behavior rather than on a general preference.
Profile the workload before choosing an architecture
The data team and the workload owners list the query patterns, concurrency, data volumes, freshness requirements and whether queries mostly hit recent or historical data. Shared-nothing deployments keep data on backend nodes with local disks, while shared-data deployments read cold data from object storage through a cache, so the cache hit pattern matters as much as raw volume. The step is done when you have a written profile that names the top queries, the peak concurrency and the tolerance for slower first reads.
Confirm the storage platform and network path
The platform engineering and network teams confirm which object store or HDFS cluster will hold the data (S3, GCS, Azure Blob Storage, MinIO or HDFS), where it sits relative to the compute nodes, and what the route, bandwidth and egress rules look like between them. Ask the storage owner for the throughput and latency they can guarantee on that path, and confirm how credentials will be issued and rotated. The step is done when a signed-off diagram shows the path and the access model, and the owner accepts the expected cache miss traffic.
Pilot on representative data
Load a representative slice of production data into a test environment in both candidate layouts if your team can run them, or in the layout you prefer if you can only run one. Run the real query set, including the joins, aggregations and any materialized views you plan to rely on, and record latency, resource use and failure behavior. The step is done when the team has a comparison table from the pilot and a list of queries that behaved differently than expected.
Test cache behavior under realistic access
For shared-data deployments, test the tiered cache across memory, local disk and remote storage with cold starts, a shifting hot set and compute node restarts. Confirm that hot data is served from cache and that cold data is loaded into the local cache as the architecture documents describe, and measure how long queries take while the cache warms. The step is done when the team can explain, with pilot numbers, what the cache does to latency for the workload profile from step one, and which cache sizing questions remain open.
Check Kubernetes operator support for the target version
If the cluster will run on Kubernetes, the platform team checks the StarRocks Kubernetes operator release notes against the StarRocks version you plan to deploy and against the Kubernetes minor version your clusters run or will run. Compare the Kubernetes support window with the expected life of the platform, and confirm how the operator handles stateful components, storage classes and upgrades. The step is done when a compatibility matrix is written down, with each version pair marked supported, unsupported or unverified, and the unverified items have an owner.
Request a written scope and quote
Send the workload profile, the storage and network diagram, the pilot results, the cache findings and the operator matrix to the implementation partner and ask for a written scope. The scope should list the architecture chosen, the environments, the hardening and backup work, the handover documentation and the support model, with deliverables and timelines agreed in writing before work starts. The step is done when you hold a quote that follows from that scope and you can trace each line item back to a decision made in this sequence.
Questions buyers ask before choosing a StarRocks deployment
Should we start with shared-data or shared-nothing StarRocks?
Start with shared-data if your data already lives in object storage or HDFS and you expect storage to grow faster than query load. Shared-nothing suits teams that want compute and storage bound to the same backend nodes and that can accept scaling both together. Shared-data needs the stateless compute nodes, the object store and the tiered cache sized and monitored as separate parts. The StarRocks README states shared-data is supported from version 3.0, so confirm the exact version you plan to run against the StarRocks architecture documentation before you commit.
What drives StarRocks running costs up or down?
Costs split into infrastructure you pay the cloud or data center provider for, and effort you pay your own staff or a services partner for. Infrastructure cost depends on how much data sits in object storage, how large the local cache must be to keep hot data fast, and how many compute nodes run concurrent queries. Shared-nothing costs rise with storage because every backend node carries disks. Effort costs rise with the number of clusters, the upgrade cadence and the amount of monitoring you build. Ask any quote to itemize compute, storage, cache, backup and operator time separately.
How much effort does migrating between the two models take?
Moving from shared-nothing to shared-data is a data migration project, not a configuration change, because table data moves from backend disks into object storage. Plan for schema and load-path validation, a cutover window, and a rollback path that keeps the old cluster readable until queries match. The effort grows with table count, materialized view dependencies and the number of BI tools pointed at the cluster. Ask your implementation partner to inventory those dependencies in writing before agreeing a fixed scope and timeline.
Can our team run StarRocks without outside help?
A team with experience running a distributed database, Linux administration and object storage can operate StarRocks, but the workload is continuous rather than one-off. You will own frontend and backend or compute node upgrades, backup and restore, capacity planning and access control for the MySQL-protocol endpoint. Teams without that depth often use a fixed-scope implementation for the first build and a retainer for upgrades and testing. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure, and it does not operate your production systems as a managed service unless a retainer says so.
How long does a StarRocks pilot run and what does it need from us?
The length of a pilot depends on the number of source systems, the data volume you load, and how many query patterns you must prove. No duration figure is supplied for this topic, so ask for a timeline in the written scope rather than a generic number. Expect to provide a non-production environment with object storage or HDFS access, representative data, sample dashboards or SQL, named reviewers for performance results, and an agreed list of success criteria such as target query latency and recovery tests. The pilot should answer the architecture question with your workload, not with benchmark averages.
Do we need Kubernetes to run StarRocks in shared-data mode?
Kubernetes is optional. StarRocks can run on virtual machines or bare metal, but if you already operate Kubernetes, the StarRocks operator is maintained as an Apache-2.0 project in its GitHub repository. Running it on Kubernetes adds a control plane you must keep healthy, including etcd backups, certificate handling and upgrades within the version skew limits. Secrets for object storage credentials are stored unencrypted in etcd by default, so encryption at rest and least-privilege RBAC must be part of the design. Confirm operator support for your StarRocks version before choosing this path.
What should we verify about recovery before go-live?
Verify recovery for each layer separately. In shared-nothing mode, backend node loss and disk failure are the main concerns, and you need tested backups and rebuild steps. In shared-data mode, object storage durability, cache rebuild after compute node replacement and metadata backup on the frontend nodes matter most. Ask for a recovery test that restores into a clean environment and measures how long queries take to return to expected results. Restore timings should come from your own test, not from a vendor claim.
How DeployOpen scopes and supports StarRocks deployments
DeployOpen plans, implements, hardens, backs up, upgrades and supports self-hosted platforms inside your own infrastructure, and StarRocks is handled the same way whichever architecture you choose. The work runs in your cloud accounts, data centers or air-gapped network, so the choice between backend nodes with local disks and stateless compute nodes over object storage is made against your real network, storage and identity boundaries. Engagements are typically fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing upgrades, support and continuous testing are available as retainers.
For a StarRocks build, the written scope should name the architecture explicitly: the number of frontend (FE) and backend (BE) nodes or the compute node (CN) pool, the object storage target (S3, GCS, Azure Blob, MinIO or HDFS), the tiered cache sizing, the Kubernetes footprint if the StarRocks operator is used, and the upgrade path across StarRocks releases. Ask your implementation partner to list which of these are in scope, which are your responsibility, and which require a separate change request. Confirm the StarRocks version you plan to run against the project's current release notes before the scope is signed.
DeployOpen does not publish a price list. A quote follows from the written scope, so the inputs that move cost are the ones above plus the hardening and backup requirements, the number of environments, and the retainer level after go-live. Ask for the quote to separate one-time work (design, build, migration, initial hardening) from recurring work (upgrades, monitoring, backup testing, on-call support), and ask who pays for cloud compute, storage and object-store egress, since those charges sit outside any DeployOpen fee.
