Database guides

StarRocks

Updated 2026-08-11 · 2 min read

A columnar OLAP database whose front end speaks the MySQL wire protocol. AddisDB connects with its MySQL driver on port 9030 and opens the Big Data Console.

StarRocks is a columnar analytical database built for sub-second queries over large tables, with a vectorised execution engine and a cost-based optimiser. Its front-end nodes speak the MySQL wire protocol, so AddisDB connects with its MySQL driver — on port 9030, the front end’s query port, rather than 3306.

Who it is for

StarRocks suits real-time analytics: dashboards over freshly-ingested data, user-facing analytics where a multi-second query is too slow, and joins across large tables that a pre-aggregated cube would have to flatten. It can query data in place through external catalogs — Iceberg, Hudi, Delta Lake, Hive — as well as its own native tables.

The design decision that shapes every table is the key model. A duplicate-key table stores every row as written; an aggregate-key table rolls rows up on ingest; a primary-key table supports real updates and deletes. You choose at CREATE TABLE time, and the choice governs what the table can do afterwards.

Set up the cluster

  1. Note a front-end (FE) host. Any FE accepts queries; the back-end nodes are internal.
  2. Use the query port, 9030. The FE’s HTTP port 8030 is for the web console and is not what AddisDB connects to.
  3. The default account is root with an empty password on a fresh cluster — set one before exposing it.
  4. Note the database, or use default_catalog to browse the native catalog.
# The FE query port speaks MySQL
mysql -h starrocks-fe.example.com -P 9030 -u root -e 'SHOW DATABASES;'

Connect from AddisDB

  1. New Connection → StarRocks. Port prefills to 9030 and username to root.
  2. Enter the FE host and credentials.
  3. Set SSL mode to require if the cluster terminates TLS; leave it at prefer otherwise.
  4. Test, then Save.

What AddisDB gives you

The Big Data Console, because StarRocks is catalogued as a warehouse engine — so queries, the results grid, exports and saved queries all work the way they do for the other analytical engines.

The schema tree reads information_schema, which StarRocks implements, so databases, tables and columns load normally.

Query plans use StarRocks’s own EXPLAIN, which returns a text plan, so the plan viewer renders it as text rather than as a tree. There are no per-node measurements in it — it is the planner’s estimate.