<@U0A71G31CDV> is there any performance penalty qu...
# questions-and-troubleshooting
b
@Rocky is there any performance penalty querying or joining across two or more starrocks databases using starrocks native storage?
1
r
In StarRocks, there is no inherent performance penalty specifically for querying or joining across two or more databases within the same cluster. Here’s why: 1. Logical vs. Physical Separation In StarRocks, a database is a logical namespace (within the
default_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. Referencesusing_starrocks/Colocate_join.md