Ben Kimpel
04/03/2026, 2:21 PMRocky
04/03/2026, 2:22 PMdefault_catalog). The physical data (tablets) is distributed across the Backend (BE) nodes based on your partitioning and bucketing strategy, regardless of which database the table belongs to.
* When you run a query, the Frontend (FE) planner looks up the metadata for the tables involved. Whether those tables are in one database or ten, the planning process and the resulting execution plan on the BEs remain the same.
2. High-Performance Joins (Colocate Join)
Even the most optimized join type—the *Colocate Join*—is supported across different databases.
* Colocate Join allows StarRocks to perform joins locally on the BE nodes without any network shuffle, provided the data is distributed on the same keys.
* Starting from version 2.5.4, you can specify the same colocate_with property for tables in different databases. This ensures they are physically distributed in the same way, allowing for "local-only" join performance even across database boundaries.
3. Join Strategies are Identical
If your tables are not collocated, StarRocks will use standard distributed join strategies:
* Shuffle Join: Both tables are redistributed across the network.
* Broadcast Join: One table is sent to all nodes.
The cost of these operations is determined by the size of the data and the network bandwidth, not by the database names. A shuffle join between db1.tableA and db2.tableB is identical in performance to a shuffle join between db1.tableA and db1.tableB.
Summary
Feature | Same Database | Different Databases
Metadata Lookup | Negligible | Negligible
Execution Plan | Same logic | Same logic
Shuffle/Broadcast Join | Supported | Supported
Colocate Join | Supported | Supported (v2.5.4+)
Conclusion: You can organize your data into different databases for logical or security reasons without worrying about performance hits during joins or cross-database queries.
References
• using_starrocks/Colocate_join.md