starrocks Documentation

The world's fastest open query engine for sub-second analytics both on and off the data lakehouse. With the flexibility to support nearly any scenario,...

11,977 stars Java Java 1 file Β· ~4,721 tokens #analytics#big-data#cloudnative#database#datalake#delta-lake#distributed-database#hudi
RAW Doc

Docker & Self-Hosted Deployment Verified OCI

Deploy starrocks on any server, homelab, or cloud container platform.

1-Click Terminal Command
bash (docker run) 
docker run -d --name starrocks --restart always ${STARROCKS_DEV_ENV_IMAGE:-starrocks/dev-env-ubuntu:latest}
Configured Services & Ports
βš™οΈ starrocks-dev
image: ${STARROCKS_DEV_ENV_IMAGE:-starrocks/dev-env-ubuntu:latest}
βš™οΈ build-fe
image: build locally
βš™οΈ build-be
image: build locally
βš™οΈ test-fe
image: build locally
βš™οΈ test-be
image: build locally
docker-compose.yml
yaml (docker-compose.yml) 
version: '3.8'

services:
  starrocks-dev:
    image: ${STARROCKS_DEV_ENV_IMAGE:-starrocks/dev-env-ubuntu:latest}
    container_name: starrocks-dev-env
    volumes:
      - .:/workspace
      - ~/.m2:/tmp/.m2
      - starrocks-maven-cache:/root/.m2
      - starrocks-build-cache:/workspace/output
    working_dir: /workspace
    environment:
      - STARROCKS_HOME=/workspace
      - HOME=/tmp
    user: "${UID:-1000}:${GID:-1000}"
    stdin_open: true
    tty: true
    command: /bin/bash
    networks:
      - starrocks-dev

  # Service for building Frontend
  build-fe:
    extends: starrocks-dev
    container_name: starrocks-build-fe
    command: ./build.sh --fe

  # Service for building Backend
  build-be:
    extends: starrocks-dev
    container_name: starrocks-build-be
    command: ./build.sh --be

  # Service for running tests
  test-fe:
    extends: starrocks-dev
    container_name: starrocks-test-fe
    command: ./run-fe-ut.sh

  test-be:
    extends: starrocks-dev
    container_name: starrocks-test-be
    command: ./run-be-ut.sh

volumes:
  starrocks-maven-cache:
    driver: local
  starrocks-build-cache:
    driver: local

networks:
  starrocks-dev:
    driver: bridge

File: README.md

StarRocks is the world's fastest open query engine for sub-second, ad-hoc analytics both on and off the data lakehouse. With average query performance 3x faster than other popular alternatives, StarRocks is a query engine that eliminates the need for denormalization and adapts to your use cases, without having to move your data or rewrite SQL. A Linux Foundation project.

Learn more πŸ‘‰πŸ» What Is StarRocks: Features and Use Cases,
Join StarRocks Summit 2025!

Features

  • πŸš€ Native vectorized SQL engine: StarRocks adopts vectorization technology to make full use of the parallel computing power of CPU, achieving sub-second query returns in multi-dimensional analyses, which is 5 to 10 times faster than previous systems.
  • πŸ“Š Standard SQL: StarRocks supports ANSI SQL syntax (fully supported TPC-H and TPC-DS). It is also compatible with the MySQL protocol. Various clients and BI software can be used to access StarRocks.
  • πŸ’‘ Smart query optimization: StarRocks can optimize complex queries through CBO (Cost Based Optimizer). With a better execution plan, the data analysis efficiency will be greatly improved.
  • ⚑ Real-time update: The updated model of StarRocks can perform upsert/delete operations according to the primary key, and achieve efficient query while concurrent updates.
  • πŸͺŸ Intelligent materialized view: The materialized view of StarRocks can be automatically updated during the data import and automatically selected when the query is executed.
  • ✨ Querying data in data lakes directly: StarRocks allows direct access to data from Apache Hiveβ„’, Apache Icebergβ„’, Delta Lakeβ„’ and Apache Hudiβ„’ without importing.
  • πŸŽ›οΈ Resource management: This feature allows StarRocks to limit resource consumption for queries and implement isolation and efficient use of resources among tenants in the same cluster.
  • πŸ’  Easy to maintain: Simple architecture makes StarRocks easy to deploy, maintain and scale out. StarRocks tunes its query plan agilely, balances the resources when the cluster is scaled in or out, and recovers the data replica under node failure automatically.

Architecture Overview

StarRocks’s streamlined architecture is mainly composed of two modules: Frontend (FE) and Backend (BE). The entire system eliminates single points of failure through seamless and horizontal scaling of FE and BE, as well as replication of metadata and data.

Starting from version 3.0, StarRocks supports a new shared-data architecture, which can provide better scalability and lower costs.

Resources

πŸ“š Read the docs

Section Description
Quick Starts How-tos and Tutorials.
Deploy Learn how to run and configure StarRocks.
Docs Full documentation.
Blogs StarRocks deep dive and user stories.

❓ Get support

Contributing to StarRocks

We welcome all kinds of contributions from the community, individuals and partners. We owe our success to your active involvement.

  1. See Contributing.md to get started.
  2. Set up StarRocks development environment:
  1. Understand our GitHub workflow for opening a pull request; use this PR Template when submitting a pull request.
  2. Pick a good first issue and start contributing.

πŸ“ License: StarRocks is licensed under Apache License 2.0.

πŸ‘₯ Community Membership: Learn more about different contributor roles in StarRocks community.

πŸ’¬ Developer Group： Please join our Google Groups to discuss StarRocks features, project directions, issues, pull requests, or share suggestions.

Used By

This project is used by the following companies. Learn more about their use cases:

File: docs/README.md

StarRocks documentation

How to contribute documentation

Thank you very much for contributing to StarRocks documentation! Your help is important to help improve the docs!

Before contributing, please read this article carefully to quickly understand the tips, writing process, and documentation templates.

Tips

  1. Language: Please use at least one language, Chinese, English, or Japanese. Adding/Updating all three language files is highly preferred.
  2. Index: When you add a topic, you also need to add an entry for the topic in the sidebars.json file of the docs/docusaurus folder. The path to your topic must be a relative path from the docs folder. This sidebars.json file will eventually be rendered as the side navigation bar for documentation on our official website. If you are not sure how to edit this file, you can leave this work to the documentation team.
  3. Images: Images must first be put into the assets folder. When inserting images into the documentation, please use the relative path, such as ``.
  4. Links: For internal links (links to documentation on our official website), please use the relative path of the document, such as [test md](./data_source/catalog/hive_catalog.md). For external links, the format must be [link text](link URL).
  5. Code blocks: You must add a language identifier for code blocks, for example, sql.
  6. Currently, special symbols are not supported.

Writing Process

  1. Writing phase: Write the topic (in Markdown) according to templates, and add the topic's index to the sidebars.json file if the topic is newly added.

    • Because the documentation is written in Markdown, we recommend that you use markdown-lint to check whether the documentation conforms to the Markdown syntax.
    • When adding the topic index, please pay attention to its category in the sidebars.json file. For example, the Stream Load topic belongs to the Loading chapter.

  2. Submission phase: Create a pull request to submit the documentation changes to our documentation repository on GitHub, English documentation is in the docs/en folder of the StarRocks repository, Chinese documentation is in the docs/zh folder, and Japanese is in docs/ja folder.

    Note

    All commits in your PR should be signed. To sign a commit you can add the -s argument. For example:

    commit -s -m "Update the MV doc"

  3. Lists of settings

    Long lists of settings like this do not index well in search, and the reader will not find the information even when they type in the exact name of a setting:

    markdown
    - `setting_name_foo`

  Details for foo

- `setting_name_bar`
  Details for bar
...

    Instead, use a section heading (e.g., ###) for the setting name and remove the indent for the text:

    markdown
    ### `setting_name_foo`

Details for foo

### `setting_name_bar`
Details for bar
...
    Search results with a long list: Search results with H3 headings

  4. Review phase

    The review phase includes automatic checks and manual review.

    • Automatic checks: whether the submitter has signed the Contributor License Agreement (CLA) and whether the documentation conforms to the Markdown syntax.
    • Manual review: Committers will read and communicate with you about the documentation. It will be merged into the StarRocks documentation repository and updated on the official website.

Documentation template

Verifying SQL samples

The sql-reference docs contain thousands of runnable SQL examples. This procedure
checks that they still run on every supported StarRocks release and drafts fixes
for the ones that don't.

The one rule still holds β€” each version's docs are tested against a cluster of that
same version β€” but the sql-doc-autofix skill now does this for the whole supported
set in one run, one cluster at a time on 127.0.0.1:9030. This is what makes
backporting safe: a fix reaches a release branch only if it was verified against that
version's own cluster, and each PR checks only the backport boxes it verified.

Prerequisites

  • Docker (includes Compose)
  • Python 3 and uv
  • gh, authenticated β€” used to discover the supported
    versions and to open PRs/issues.
  • A clone of this repo (git clone https://github.com/StarRocks/starrocks.git) β€” a
    normal clone has this tooling and knows every release branch via origin/*, so
    you never switch its branch.
  • Claude Code with the starrocks
    MCP server (from the repo's .mcp.json) β€” used in step 4.

0. Overview

The skill runs the full supported set end to end. You mainly confirm the version set
and review the results; the skill drives the clusters:

  1. Confirm the version set β€” auto-discovered from GitHub (e.g. 4.1 4.0 3.5).
  2. Create/refresh a worktree per version β€” their docs are what's checked.
  3. Run the sql-doc-autofix skill β€” for each version it starts a matching
    cluster on 9030, checks that version's docs, verifies fixes, and stops the cluster
    before the next version.
  4. Review the draft PR(s) of suggested fixes (backport boxes already match the
    verified versions).
  5. Tear down anything left over.

All commands are run from the root of the StarRocks/starrocks repo:
cd <wherever you have the repo checked out>

1. Confirm the version set

The skill discovers the supported versions for you and asks you to confirm or edit
them. To preview or pin the set yourself:

bash
docs/scripts/supported_versions.sh            # e.g. -> "4.1 4.0 3.5"
docs/scripts/supported_versions.sh --max 4.1  # pin the newest, if not the latest

It reads GitHub Releases, keeps the newest distinct major.minor lines (top 3 by
default), and stays correct as new releases ship β€” no edits needed when 4.2 lands.
To skip discovery, export an explicit list: export SR_VERSIONS="4.1 4.0 3.5".

2. Create a worktree per release branch

One command per version (skip any you already have). Each fetches the branch and
checks it out in its own directory on a branch named exactly branch-<version>,
without touching your current branch:

bash
for v in 4.1 4.0 3.5; do
  git fetch origin branch-$v
  git worktree add ../sr-branch-$v -b branch-$v origin/branch-$v
done

Before a later run, refresh each with git -C ../sr-branch-$v pull.

3. Check the examples and draft fixes

In Claude Code (with the starrocks MCP server attached), run the
sql-doc-autofix skill. For each version in the set it:

  • brings up a matching cluster on 127.0.0.1:9030 (user root, no password),
  • runs the checker against all three languages β€”
    ../sr-branch-<v>/docs/{en,zh,ja}/sql-reference β€” against that one cluster, sorting
    every example into PASS, FAIL (candidate doc bug), UNRESOLVED (not
    self-contained), ENV (test-cluster limitation), or SKIP (not runnable by
    design),
  • for the genuinely fixable FAIL items, proposes a corrected statement, verifies
    it on that cluster, and applies it to every language that carries the example β€”
    so a fix never lands in en alone,
  • flags version-gated or illustrative examples instead of "fixing" them, because
    runs on the cluster is not the same as correct documentation,
  • emits a cross-language parity report (docs/scripts/sql_sample_parity.py) β€”
    a separate signal that catches examples present in one language and missing from
    the others, which a rot run can never see,
  • then stops that cluster and moves to the next version.

That is 3 versions Γ— 3 languages = 9 checker passes, so a full run takes a while. The
triage load does not triple: the en/zh/ja copies of one example share a skeleton hash,
so they are classified and cluster-verified once and edited three times.

bash
claude

If a new MCP server is found for StarRocks, enable it:

bash
New MCP server found in this project: starrocks

Then run the skill (optionally passing a version list):

bash
/sql-doc-autofix

For a shared-data (cloud-native) cluster, or manual start/stop and health-check
details, see
docs/docker/doc-verification/README.md.

4. Review the PR(s)

Claude will ask how you want to proceed before opening anything. The skill produces:

  • One or more draft [Doc] PRs, grouped so every fix in a PR was verified on every
    version whose backport box is checked. A fix that passes on all supported versions
    becomes one PR with all boxes; a fix that fails on an older version becomes a separate
    PR with a narrower box set. Each body is filled from the repo's PR template
    (type, behavior-change, verified backport versions) and adds any suppressions
    (a ## Suppressions section, each with its version scope) for examples that
    legitimately can't run β€” version-gated, illustrative, or needing external setup.
    Once merged, those stop being reported every run, so the noise shrinks over time.
    Review the edits and suppressions, then un-draft.
  • A tracking issue holding only the examples that genuinely need a human's judgment,
    so those aren't lost when the run scrolls by. It's updated in place each run (and
    closed when empty). Work through that issue separately.

Full behavior and the report format:
.claude/skills/sql-doc-autofix/README.md.

5. Tear down

The skill stops each cluster as it finishes, but to be sure nothing is left running,
and to remove the worktrees:

bash
docker compose -f docs/docker/doc-verification/docker-compose-shared-nothing.yml down
for v in 4.1 4.0 3.5; do
  git worktree remove ../sr-branch-$v   # optional
done

Explore Related Technologies & Topics

View All 9,111+ Repositories β†’

Discover similar high-velocity repositories, agent skills, and OpenAPI specifications across the ecosystem.

#analytics Browse analytics catalog β†’ #big-data Browse big-data catalog β†’ #cloudnative Browse cloudnative catalog β†’ #database Browse database catalog β†’ #datalake Browse datalake catalog β†’ #delta-lake Browse delta-lake catalog β†’ ⚑ MCP Servers Model Context Protocol β†’ 🧠 Agent Skills Prompt & rule files β†’ πŸ”Œ OpenAPI Specs REST & Swagger schemas β†’