@Rocky I'm seeing "bucket_size" = "1073741824" in the ddl for duplicate key tables but we didn't define it, is that expected?

Yes, this is expected behavior in StarRocks versions 3.2 and later. When you create a Duplicate Key table without defining a

DISTRIBUTED BY

clause, StarRocks defaults to Random Bucketing. Starting from version 3.2, StarRocks automatically includes the

"bucket_size" = "1073741824"

property (which is exactly 1 GB in bytes) to enable Automatic/Dynamic Bucketing. Why this happens: * Default Distribution: If no bucketing is specified for a Duplicate Key table, StarRocks uses Random Bucketing by default. * Dynamic Scaling: The

bucket_size

property allows StarRocks to dynamically increase the number of buckets (split tablets) in a partition as more data is loaded. * Default Value: The system-wide default for this feature is 1 GB (1,073,741,824 bytes). By setting this, StarRocks ensures that individual tablets stay at a healthy size for performance and maintenance. Key points to note: * Appears in DDL: Because this is now the default configuration for Duplicate Key tables with random distribution, it will show up in the

SHOW CREATE TABLE

output even if you didn't explicitly type it. * When it's used: This only applies to Duplicate Key tables. Other table types (like Primary Key or Unique Key) still require you to define a hash bucketing key. * Rollback Warning: If you ever need to rollback to a version earlier than 3.2 (where this property isn't recognized), you may need to delete tables using this feature first, as it introduces metadata changes. If you prefer a different size or want to disable it (by setting a fixed number of buckets), you can specify

DISTRIBUTED BY RANDOM BUCKETS <num>

during table creation instead. References • table_design/data_distribution/Data_distribution.md • sql-reference/sql-statements/table_bucket_part_index/CREATE_TABLE.md

@Rocky i assume 1gig is a reasonable default?

Yes, 1 GB (1,073,741,824 bytes) is considered a very reasonable and recommended default for most StarRocks workloads. In StarRocks, this value is chosen to balance two competing performance factors: 1. Why 1 GB is a "Sweet Spot" * Parallelism: Smaller tablets allow StarRocks to distribute a query across more CPU cores and nodes. If tablets are too large (e.g., 50 GB), a single slow disk or core can bottleneck the entire query. * Metadata Overhead: If tablets are too small (e.g., 100 MB), you end up with thousands of tablets. This puts pressure on the FE (Front End) for metadata management and can slow down query planning and tablet reports. * Compaction Efficiency: 1 GB tablets are large enough to be compacted efficiently without constant background IO, but small enough that a single compaction task doesn't take hours. 2. When should you change it? While 1 GB is the standard, you might consider adjusting it in these specific cases: * Increase to 4 GB: If you have massive partitions (e.g., several hundred GBs or TBs per partition). Setting

bucket_size

to

4294967296

(4 GB) helps prevent the "Too Many Tablets" problem, which can degrade cluster stability. * Decrease (Rare): If you have very small nodes (low CPU/RAM) and very small data volumes, but generally, 1 GB is safe even then, as StarRocks won't create extra buckets unless the data actually grows to fill them. Summary For most users, leaving it at 1 GB is the best "set it and forget it" approach. It allows the system to scale the number of buckets automatically as your data grows without requiring you to manually calculate bucket counts for every table. References • table_design/data_distribution/Data_distribution.md • best_practices/bucketing.md References • best_practices/bucketing.md • knowledge/usage/best-practice.md • table_design/data_distribution/Data_distribution.md • administration/management/FE_configuration.md