To any teams that are self-hosting on AWS, I'm curious to hear about any learnings you've had getting up and running? How easy/difficult is managing the clusters? Are there any surprises with AWS usage? Where does it fall on the spectrum of set it and forget it vs continuous maintenance/tuning?

No production analytical database runs itself — StarRocks is no exception. MPP systems break down over time: data skew, tablet imbalance, compaction lag, and config drift all add up. Skip proper monitoring, and things degrade quietly until something breaks. You've seen this with other MPP engines. StarRocks needs less babysitting than most — especially in shared-data mode — but it still needs attention from day one. AWS: What to know before you deploy Start with Graviton. c7g/r7g instances are the right default for StarRocks on AWS. Benchmarks show 40–50% better price-for-performance than x86. Test against your own workload, but start here. Shared-Data architecture choices that matter: • Run at least 3 FE nodes. Losing quorum means a full outage. • Local NVMe on Compute Nodes is not optional for hot workloads. StarRocks caches in three tiers: memory, local disk, and S3. Skip local NVMe and repeated queries hit S3 every time. • Tune Block Cache to your actual working set. The defaults are too conservative. • Keep FE and CN on separate nodes in production. Co-locating them causes resource contention under load, making it hard to diagnose. S3 costs will surprise you: • High request rates and LIST calls add up fast. Good partition pruning and bucket/prefix design control both performance and cost. • Read the Fresha post-mortem on a sudden 10× S3 bill: How we accidentally became one of UK's first StarRocks production pioneers. Read it before you go live. • Turn on S3 request metrics in CloudWatch now, not after something goes wrong. What you need running from day one: • Prometheus + Grafana on StarRocks metrics — tablet health, compaction queue, cache hit rate, and CPU/memory are your early warning signs. • Profile queries regularly. EXPLAIN ANALYZE, and the Query Detail page catches skew and bad plans before they become incidents. • Watch VersionCount per tablet. Too many versions from heavy ingestion is a real failure mode. • Wire up CN auto-scaling before you need it. Shared-data elasticity only helps if it's already set up when load spikes. Treat StarRocks like a production system from week one. The entropy is real — it just arrives more slowly than with most MPP alternatives. Build your monitoring first, then build trust in the system. Not affiliated with Fresha — just re-sharing their solid write-up.