@Rocky What is recommended number of tablets per partition? Are there significant downsides to “smaller” tablets in 2-5Gb range compared to 10Gb? Would that help compaction? What matters most - number of partitions, number of tablets per partition or overall number of tablets?

Based on the StarRocks documentation and best practices, here are the recommendations for tablet sizing and counts: 1. Recommended Tablets per Partition * Typical Range: 10 to 120 tablets per partition is the standard recommendation. * Minimum: You should ensure there are at least as many tablets as there are Backend (BE) nodes to ensure every node can participate in a query. * Maximum: Avoid exceeding a few hundred tablets per partition, as this increases the metadata overhead for the Frontend (FE) during query planning and partition management. 2. Tablet Size: 2–5 GB vs. 10 GB Both ranges are considered acceptable, but they favor different performance aspects: * 10 GB (Raw Data): This is the modern "sweet spot" for StarRocks (v2.4+). Since StarRocks supports Internal Tablet Parallelism (

enable_tablet_internal_parallel = true

), a single large tablet can be scanned by multiple threads. This allows you to have fewer, larger tablets, which reduces metadata pressure without sacrificing query speed. * 2–5 GB (Smaller Tablets): These are perfectly fine and often safer if your data distribution is slightly skewed. * Downsides of "Too Small" (< 1 GB): If you have thousands of 100MB-500MB tablets, you will hit metadata limits faster, and the overhead of managing small files during ingestion will increase. * Downsides of "Too Large" (> 10 GB): Tablets exceeding 10 GB can become "heavy." If a compaction task fails or is interrupted on a 50 GB tablet, it has to restart a much larger job than on a 10 GB tablet. 3. Does it help compaction? Yes, smaller tablets generally help compaction keep up, but with a caveat: * The Benefit: Compaction is performed at the tablet level. Smaller tablets mean the "unit of work" for a single compaction thread is smaller. This makes it easier for the system to merge data versions quickly and release disk space. * The Limit: If you have too many tablets per partition (e.g., thousands), the FE/BE spends more time scheduling tasks and managing the "Compaction Score" for each one, which can actually degrade performance. * The "Red Flag": If a tablet grows significantly beyond 10 GB, compaction can become a bottleneck because the merge process becomes resource-intensive and takes longer to complete. 4. What matters most? (The Hierarchy of Limits) When designing your distribution, prioritize your constraints in this order: 1. Total Tablets per BE: This is the most critical "hard" limit. You should generally keep the total number of tablets per BE node under 200,000. Exceeding this causes high memory usage and slow restarts. 2. Total Partitions per Table: Keep this under 100,000 to avoid FE memory pressure and slow query planning. 3. Tablet Size: Aim for 1 GB to 10 GB (of raw data). 4. Tablets per Partition: Aim for a number that is a multiple of your BE count (e.g., if you have 3 BEs, use 6, 12, or 24 buckets) to ensure even load balancing. Summary Recommendation: If your partition is ~100 GB, use 10–20 buckets (reaching the ~10 GB/tablet target). If your partition is smaller (e.g., 10 GB), still use at least 3-6 buckets (depending on your BE count) even if it results in "smaller" 2 GB tablets, to ensure query parallelism across your nodes. References • best_practices/bucketing.md • table_design/data_distribution/Data_distribution.md • faq/Deploy_faq.md • best_practices/partitioning.md • knowledge/usage/best-practice.md