@Rocky I have a table with daily data, but the data is small. Queries would benefit from partition pruning, but once in a partition the tablets/buckets are a maximum of 12 Mb and only if I use a single bucket. Will this cause performance issues?

Having tablets as small as 12 MB is generally considered sub-optimal in StarRocks, but whether it will cause immediate performance issues depends on the total number of tablets across your entire cluster. Here is a breakdown of the trade-offs and recommendations for your scenario: 1. The Risk: Metadata and I/O Overhead StarRocks is designed to handle large-scale data. The recommended size for a tablet is typically between 100 MB and 10 GB (with 1 GB being a common sweet spot). If your tablets are only 12 MB: * FE Overhead: Every tablet has metadata that the Frontend (FE) must manage. If you have thousands of these small partitions across many tables, the FE memory usage and scheduling logic will become a bottleneck. * BE Overhead: During a query, the Backend (BE) creates a thread/task to scan each tablet. While StarRocks is efficient, scheduling a thread to read only 12 MB is less efficient than reading a larger, contiguous block of data. * Compaction Issues: Smaller, frequent data loads into tiny partitions can lead to a "too many small files" problem, increasing background I/O for compaction. 2. Is Partition Pruning Worth It Here? Partition pruning is powerful, but it's most effective when you are skipping large amounts of irrelevant data. _ If a full table scan only involves a few hundred megabytes, the cost of the scan is already so low that the overhead of managing many partitions might actually make the query _slower* than scanning a single larger bucket. * If your query usually targets only the "last 1 day," daily partitioning is logically sound, but you are hitting the "small tablet" trap. 3. Recommended Strategies A. Coarsen Your Partitioning Instead of partitioning by day, consider partitioning by week or month. * Why: This increases the amount of data per partition (and thus per tablet), getting you closer to the recommended size. * Pruning: You still get pruning! For example, if you partition by month and query for a specific day, StarRocks will prune all other months and then quickly filter the daily data within that month's tablet. B. Use Random Bucketing with 1 Bucket You mentioned you are already using a single bucket. Ensure you are using

DISTRIBUTED BY RANDOM BUCKETS 1

if you don't have a natural high-cardinality key for hashing. This ensures all data for that partition stays in exactly one tablet. C. Monitor Your Total Tablet Count If this is your only table and you only have 365 partitions (one year of data), 365 tablets is perfectly fine. The "performance issues" usually start when: * Total tablets per BE exceed 10,000–50,000 (depending on your BE RAM). * The FE starts struggling with a massive metadata catalog (hundreds of thousands of tablets). Summary Recommendation If your total data volume per day is only ~12 MB: 1. Switch to Monthly Partitioning: This will result in ~360 MB tablets, which is much healthier for the system. 2. Enable Parallel Scanning: Ensure

enable_tablet_internal_parallel = true

is set (it is by default in recent versions). This allows StarRocks to use multiple threads on a single tablet if the query needs more speed. 3. Keep an eye on the "Compaction Score": If you see high latency, check if you have too many small versions/segments within those tablets. Rocky's Tip: In StarRocks, it is usually better to have fewer, larger tablets than many tiny ones. Don't be afraid to group your small daily data into monthly partitions! References • faq/Deploy_faq.md • faq/table_design_faq.md • table_design/data_distribution/Data_distribution.md • faq/operation_maintenance_faq.md • faq/shared_data_faq.md

👍