Cloud Parts

StarRocks

An open-source MPP analytical database with a vectorized engine that serves fast joins and real-time updates on its own tables, and also queries Iceberg, Hudi, Delta Lake and Hive tables in place.

What it is
Real-time analytics databases,Query engines
Type
Open source
Made by
StarRocks Project (Linux Foundation), led by CelerData, now PhoenixAI
License
Apache 2.0 (Elastic License 2.0 until December 2022)
Facts checked
6 October 2026
Website Source code

What it is

A StarRocks cluster has only two kinds of node. Frontends (FEs, written in Java) hold the metadata, accept MySQL-protocol connections and plan queries; one leader writes metadata and replicates it to followers, which elect a new leader if it fails. Backends (BEs, written in C++) store data in columns and run the plans. It is a massively parallel processing (MPP) engine: a query is split into fragments that run on every backend at once, and for big joins or GROUP BY on high-cardinality columns the rows are shuffled between nodes so the merge work is shared, instead of gathering everything on one node. Operators are vectorized: they process columns in batches with SIMD instructions, and a cost-based optimizer written from scratch picks join orders and distributed join strategies. Primary Key tables apply updates as delete-and-insert with a primary key index, so upserts from a database or a Kafka topic are queryable within seconds.

Since version 3.0 (April 2023) you choose between two layouts. In shared-nothing mode each BE keeps part of the data on local disk, with replicas, for the lowest latency. In shared-data mode the BEs are replaced by stateless compute nodes (CNs): tables live in S3, Google Cloud Storage, Azure Blob Storage, MinIO or HDFS, each CN caches hot data in memory and on local disk, and CNs can be added or removed in seconds without moving data. On a cache hit, queries run about as fast as in shared-nothing mode; on a miss, data is fetched from object storage first.

StarRocks also works as a lake query engine. External catalogs point it at Hive, Iceberg, Hudi, Delta Lake and Paimon tables (plus JDBC databases and Elasticsearch) through their metastores, such as Hive Metastore, AWS Glue or an Iceberg REST catalog, and every node scans the files in parallel. It can also write back to Iceberg and Hive tables with INSERT INTO, and asynchronous materialized views can be built over lake tables, with queries rewritten to use them automatically. Kafka topics stream in through Routine Load with exactly-once delivery, and a Flink connector loads data in batches through Stream Load. StarRocks is Apache 2.0 licensed and hosted by the Linux Foundation. CelerData, which rebranded as PhoenixAI in 2026, created it, still leads development and sells managed and self-managed versions with extra security and support. Version 4.1 came out in April 2026.

Why teams pick it

  • Built for joins: MPP shuffles plus a cost-based optimizer let it query star and snowflake schemas without first flattening them into wide tables
  • Fresh, updatable data: Primary Key tables take upserts and deletes, and Routine Load ingests Kafka topics exactly once
  • One engine for its own tables and for Iceberg, Hudi, Delta Lake and Hive tables, with materialized views to speed up slow lake queries
  • Simple to run for a distributed database: only FE and BE or CN processes, no ZooKeeper or other external services, and any MySQL client or BI tool can connect

Watch out for

  • Shared-data mode still lags shared-nothing: backup and restore is not available there (cluster snapshots instead), and row store, vector indexes and column-mode partial updates are not yet supported
  • Lake support is uneven: it writes back only to Iceberg and Hive tables, not to Hudi, Delta Lake or Paimon, and the Paimon catalog is still a beta
  • Materialized views over lake tables aren’t guaranteed consistent: StarRocks can’t see changes made to external tables, so a rewritten query may read stale results
  • One company does much of the development, and the similarly named Apache Doris is a separate fork that has diverged, so features, docs and advice don’t carry over between the two

Alternatives

What all real-time analytics databases have in common →
Alibaba Cloud HologresCommercialAlibaba Cloud’s PostgreSQL-compatible real-time data warehouse, which takes streaming writes, answers analytical queries and serves key lookups from one copy of the data.Apache DorisOpen sourceAn open-source MPP analytical database, born at Baidu as Palo, that serves sub-second queries on fresh, updatable data through the MySQL protocol and also queries Iceberg, Hudi, Paimon and Hive tables in place.Apache DruidOpen sourceAn open-source real-time analytics database that makes Kafka and Kinesis events queryable within seconds and serves fast slice-and-dice queries to dashboards and APIs.FireboltCommercialA cloud data warehouse built for low-latency, high-concurrency queries behind apps and dashboards, also free to self-host as Firebolt Core.PivotOpen sourceA young open-source analytics server in Rust that speaks the PostgreSQL protocol and queries Iceberg and Delta Lake tables straight from object storage.TinybirdCommercialA hosted ClickHouse platform that turns SQL queries into authenticated REST API endpoints, for analytics inside your product.

How it fits with other technologies

Point StarRocks at an Iceberg catalog in AWS Glue, query it, and cache a rollup · sql

CREATE EXTERNAL CATALOG lake
PROPERTIES (
    "type" = "iceberg",
    "iceberg.catalog.type" = "glue",
    "aws.glue.use_instance_profile" = "true",
    "aws.glue.region" = "us-west-2",
    "aws.s3.use_instance_profile" = "true",
    "aws.s3.region" = "us-west-2"
);

SELECT country, count(*) AS orders
FROM lake.sales.orders
WHERE order_date >= '2026-10-01'
GROUP BY country;

CREATE MATERIALIZED VIEW daily_orders
REFRESH ASYNC EVERY (INTERVAL 1 HOUR)
AS SELECT order_date, country, count(*) AS orders
FROM lake.sales.orders
GROUP BY order_date, country;

See it in a real stack

No architecture uses StarRocks yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2020–2026

Apache Doris grew out of code first developed at Baidu and became an Apache incubator project. In 2020 a team took Doris 0.13, released early that year, and built a commercial product on it, first called DorisDB. They kept Doris’s overall framework and columnar storage engine but added the parts they thought it lacked for interactive analytics: a fully vectorized execution engine, a new cost-based optimizer, and a storage engine that could apply real-time updates by primary key. By version 1.19 it was called StarRocks; the code still reads a metadata key named dorisDBVersion that clusters used before 1.19.

The code went up on GitHub in September 2021 under the Elastic License 2.0, a source-available licence that, unlike Apache 2.0, didn’t allow building a hosted StarRocks service; the roughly 40% of code still identical to Doris stayed under Apache 2.0. In December 2022 the project switched entirely to Apache 2.0, saying it wanted a more open, community-driven project, and in February 2023 the company, by then called CelerData, contributed StarRocks to the Linux Foundation.

Later releases pushed it from a fast warehouse toward a lakehouse engine. Version 3.0 (April 2023) separated storage from compute so tables could live in object storage, and later versions added Paimon catalogs, writes to Iceberg and Hive tables, and Iceberg compaction. CelerData rebranded as PhoenixAI in 2026 and still leads development.

Why it’s built this way

Start from Apache Doris, then rewrite the hot paths
Doris already had a working distributed framework and columnar storage, so the team kept those and spent its effort on the vectorized engine, the optimizer and real-time updates. By September 2021 only about 40% of the roughly 700,000 lines were still identical to Doris.
MPP with shuffles instead of scatter-gather
In a scatter-gather design one node merges every partial result, which chokes on large joins and high-cardinality aggregations. Shuffling data between nodes lets every node share the merge work, so a single query keeps getting faster as the cluster grows.
Only frontends and backends, with no external services
Frontends keep a full copy of the metadata themselves, in Berkeley DB Java Edition, and elect a leader among followers. So a cluster needs no ZooKeeper, metadata database or separate deep storage to deploy and keep running.
Add shared-data mode without changing the file format
Shared-data tables use the same segment files and indexes as local tables, with a disk cache in front of object storage. That let users trade a little latency on cold data for cheap storage and elastic compute, without a second engine.

Timeline

  1. 2020

    Built on Apache Doris 0.13 as a commercial product, first called DorisDB

  2. 2021

    Code published on GitHub in September under the Elastic License 2.0

  3. 2022

    Relicensed to Apache 2.0 in December

  4. 2023

    Contributed to the Linux Foundation in February; version 3.0 adds shared-data mode in April

  5. 2025

    Version 4.0 released in October

  6. 2026

    Version 4.1 in April; CelerData rebrands as PhoenixAI

Sources14 · facts checked 6 October 2026

Improve this page on GitHub