@Rocky the new starrocks driver in dbeaver no longer shows table size, that was helpful for us

The absence of table sizes in the Database Navigator after switching to the native StarRocks driver (introduced in DBeaver 26.0.4) is a known behavior. The new driver is optimized for StarRocks-specific features like multi-catalog support, but it may not yet map table size statistics to the navigator tree in the same way the generic MySQL driver did. Here are a few ways to resolve or work around this: 1. Check DBeaver Navigator Settings Sometimes the "Statistics" view is simply disabled in the UI. * Right-click your StarRocks connection in the Database Navigator. * Select Connection view (or Customize view in newer versions). * Ensure Show statistics info is checked. * If it is checked but the size still doesn't appear, the current version of the native driver likely doesn't support automatic background statistics fetching for StarRocks yet. 2. Use the MySQL Driver as a Fallback If table size visibility in the sidebar is critical for your workflow, you can continue using the MySQL driver instead of the native StarRocks one. The MySQL driver uses standard

SHOW TABLE STATUS

calls which StarRocks supports, and this typically populates the "Size" column in DBeaver. * Create a New Connection. * Select MySQL as the driver. * Use your StarRocks FE host and port (default

9030

). 3. Manual SQL Workarounds You can quickly get precise storage information by running these commands in a SQL editor: * For all tables in the database:

sql
    SHOW DATA;

This returns the

Size

,

ReplicaCount

, and

RowCount

for every table. * For a specific table:

sql
    SHOW DATA FROM <database_name>.<table_name>;

* For column-level breakdown (v3.5+): StarRocks recently introduced

column_compressed_size

to inspect the exact on-disk size of specific columns:

sql
    SELECT column_name, column_compressed_size(column_name)
    FROM table_name [_META_];

Why did this change? The new native driver was designed to support External Catalogs (Hive, Iceberg, etc.), which require a different metadata structure than standard MySQL. This transition can sometimes cause secondary metadata like "table size" (which requires a background query) to be omitted in early versions of the driver implementation. If you are using the latest version of DBeaver and this persists, it is worth reporting it as a feature request on the DBeaver GitHub specifically for the StarRocks extension. References • integrations/IDE_integrations/DBeaver.md • faq/Sql_faq.md • faq/Others.md • sql-reference/System_limit.md • deployment/plan_cluster.md

@Rocky ok, is there a way to have it automatically use

default_catalog

so I don't have to expand that every time?

Yes, you can avoid the manual expansion of the

default_catalog

folder in the DBeaver Navigator by adjusting your connection settings or using a specific filter. 1. Specify the Database in Connection Settings When you configure the StarRocks connection in DBeaver, you can "pin" the connection to a specific database within the internal catalog. This often helps the navigator focus on that specific area. * Edit your connection settings. * In the Database/Schema field, enter the value in this format:

default_catalog.your_database_name

. * This explicitly tells the driver to prioritize that path. 2. Filter the Navigator View If you only ever use the internal catalog and find the

default_catalog

node redundant, you can filter the view to only show that specific catalog: * Right-click the connection in the Database Navigator. * Select Filters -> Configure Connection Filters.... * In the Catalogs tab, you can choose to include only

default_catalog

. * This won't remove the "folder" level, but it hides other external catalogs (like Hive or Iceberg) that you aren't using, making the tree cleaner. 3. Switch back to the MySQL Driver If the multi-level tree (Catalog > Database > Table) is fundamentally slower for your workflow than the old "flat" view, the most effective solution is to switch back to the MySQL driver. * The MySQL driver does not understand StarRocks "Catalogs." It treats StarRocks as a standard MySQL instance, meaning it only sees the

default_catalog

and flattens the view directly to the databases. * Bonus: As mentioned before, the MySQL driver also restores the Table Size visibility in the navigator that you noted was missing. Why it looks different now The new native StarRocks driver was introduced specifically to support Multi-Catalog features (querying Data Lakes like Iceberg/Hive). Because these are top-level entities in StarRocks' architecture, the driver is required to show the

Catalog

level in the hierarchy to allow users to switch between internal and external data. References • integrations/IDE_integrations/DBeaver.md • data_source/catalog/default_catalog.md • sql-reference/sql-statements/Catalog/SET_CATALOG.md References • data_source/catalog/default_catalog.md • data_source/catalog/jdbc_catalog.md • data_source/catalog/hive_catalog.md • data_source/catalog/iceberg/iceberg_catalog.md

@Rocky I can't include a

;

in string concatenation now

*SELECT* ';'

This issue is almost certainly caused by the DBeaver SQL parser in the new native StarRocks driver rather than a change in StarRocks itself. When you run a statement like

SELECT ';'

, DBeaver's script engine sees the

;

and incorrectly assumes it has reached the end of the SQL command, even though the semicolon is inside a string literal. This results in a syntax error because DBeaver sends a truncated or malformed query to the server. Solutions and Workarounds 1. Use the MySQL Driver (Recommended) As noted with the table size issue, the MySQL driver handles StarRocks perfectly for standard SQL tasks. Its parser is mature and correctly ignores semicolons inside quotes. * If you switch your connection back to the MySQL driver, this issue should disappear immediately. 2. Change DBeaver's Statement Delimiter You can tell DBeaver to use a different character to separate statements so it doesn't trip over the

;

in your strings. * In the SQL Editor, look for the "Delimiter" setting (often in the bottom toolbar or right-click -> SQL Editor -> Change Delimiter). * Change it to something like

$$

or

//

. * Your query would then look like:

SELECT ';' $$

3. Use "Execute as Script" Try running the query using Alt + X (Execute Script) instead of Ctrl + Enter (Execute Statement). * Execute Statement relies on DBeaver's internal logic to "guess" where the query ends based on the cursor position and delimiters. * Execute Script treats the entire block (or selection) as a single execution unit, which can sometimes bypass delimiter-splitting bugs. 4. Use the

CHAR()

function If you are strictly performing string concatenation and want to avoid the literal character in your script, you can use the ASCII code for a semicolon (59):

sql
-- Using CONCAT
SELECT CONCAT('Part1', CHAR(59), 'Part2');

-- Using pipe concatenation (requires SET sql_mode = 'PIPES_AS_CONCAT')
SELECT 'Part1' || CHAR(59) || 'Part2';

Summary of the Driver Conflict The new StarRocks driver in DBeaver (introduced in late 2024/early 2025) is still being refined. It appears to have regressions compared to the generic MySQL driver regarding: 1. Metadata visibility (Table sizes). 2. SQL Parsing (Semicolons in strings). If you don't specifically need Multi-Catalog support (querying Hive/Iceberg) right now, staying on the MySQL driver is the most stable path. References • integrations/IDE_integrations/DBeaver.md • sql-reference/sql-functions/string-functions/concat.md • sql-reference/System_variable.md (Search for

sql_mode

) • sql-reference/sql-statements/table_bucket_part_index/SELECT.md References • sql-reference/sql-functions/string-functions/concat.md • sql-reference/sql-functions/string-functions/group_concat.md • release_notes/release-3.1.md • sql-reference/System_variable.md • sql-reference/sql-functions/aggregate-functions/group_concat.md • sql-reference/sql-statements/table_bucket_part_index/SELECT.md