## 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](https://www.youtube.com/watch?v=RfXO5GOnbW4&ab_channel=CelerData), Join [StarRocks Summit 2025](https://summit.starrocks.io/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](https://docs.starrocks.io/docs/quick_start/)| How-tos and Tutorials. | | [Deploy](https://docs.starrocks.io/docs/deployment/deployment_overview/) | Learn how to run and configure StarRocks.| | [Docs](https://docs.starrocks.io/)| Full documentation. | | [Blogs](https://www.starrocks.io/blog) | StarRocks deep dive and user stories. | ### ❓ Get support [](https://try.starrocks.com/join-starrocks-on-slack) - [Slack community: ](https://try.starrocks.com/join-starrocks-on-slack) join technical discussions, ask questions, and meet other users! - [YouTube channel:](https://www.youtube.com/channel/UC38wR-ogamk4naaWNQ45y7Q/featured) subscribe to the latest video tutorials and webcasts. - [GitHub issues:](https://github.com/StarRocks/starrocks/issues) report an issue with StarRocks. ## 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](https://github.com/StarRocks/starrocks/blob/main/CONTRIBUTING.md) to get started. 2. Set up StarRocks development environment: * [IDE Setup](https://docs.starrocks.io/docs/developers/development-environment/ide-setup/) * [Compile StarRocks with Docker](https://docs.starrocks.io/docs/developers/build-starrocks/Build_in_docker/) * [Deploy StarRocks manually](https://docs.starrocks.io/docs/deployment/deploy_manually/) 3. Understand our [GitHub workflow](https://github.com/StarRocks/community/blob/main/Contributors/guide/workflow.md) for opening a pull request; use this [PR Template](https://github.com/StarRocks/starrocks/blob/main/.github/PULL_REQUEST_TEMPLATE.md) when submitting a pull request. 4. Pick a [good first issue](https://github.com/StarRocks/starrocks/labels/good%20first%20issue) and start contributing. **📝 License:** StarRocks is licensed under [Apache License 2.0](https://www.apache.org/licenses/LICENSE-2.0). **👥 Community Membership:** Learn more about different [contributor roles](community/membership.md) in StarRocks community. **💬 Developer Group：** Please join our [Google Groups](https://groups.google.com/g/starrocks-dev) 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: - [Airbnb](https://www.youtube.com/watch?v=AzDxEZuMBwM&ab_channel=StarRocks_labs) - [Airtable](https://medium.com/airtable-eng/live-shard-data-archive-export-and-ingestion-to-starrocks-for-validation-6af555e8b3fe) - [Alibaba](https://www.youtube.com/watch?v=7N34q65mthk) - [Amazon](https://aws.amazon.com/blogs/containers/scaling-starrocks-on-amazon-eks-with-keda-and-karpenter-for-enterprise-olap-workloads/) - [Celonis](https://www.youtube.com/watch?v=Jm-D0xvOtek) - [Cisco](https://www.starrocks.io/blog/how-cisco-webex-unified-real-time-analytics-with-starrocks) - [Coinbase](https://www.youtube.com/watch?v=3Z9jSCaHnYg&list=PL0eWwaesODdhBhKSnvpfIEAB9sgk8rKmy) - [CTW](https://www.phoenixdata.ai/case-studies/case-study-ctw.html) - [Demandbase](https://starrocks.medium.com/demandbase-ditches-denormalization-by-switching-off-clickhouse-44195d795a83) - [Didi](https://www.starrocks.io/blog/reduced-80-cost-didis-journey-from-multiple-olap-engines-to-starrocks) - [Eightfold.ai](https://www.youtube.com/watch?v=qNk_-QTZk3E) - [Fanatics](https://www.youtube.com/watch?v=hbXovqR6tOc) - [Fresha](https://medium.com/fresha-data-engineering/how-we-accidentally-became-one-of-uks-first-starrocks-production-pioneers-7db249f10010) - [Grab](https://engineering.grab.com/building-a-spark-observability) - [Haezoom](https://www.starrocks.io/blog/haezoom-and-cloudshift-overcome-apache-druids-limits-with-starrocks) - [HerdWatch](https://medium.com/p/a7916a7e87bf) - [Intuit](https://www.youtube.com/watch?v=tUC3FS3ki10) - [iQiyi](https://medium.com/starrocks-engineering/real-time-analytics-at-scale-why-we-use-starrocks-0aa3c859cbeb) - [Naver](https://starrocks.medium.com/how-join-changed-how-we-approach-data-infra-at-naver-3a5bb1dac49f) - [Pinterest](https://medium.com/pinterest-engineering/delivering-faster-analytics-at-pinterest-a639cdfad374) - [PlaySimple Games](https://medium.com/@sukkhjot/querying-billions-of-user-events-in-seconds-our-journey-with-starrocks-ecc29ac6c756) - [Shopee](https://celerdata.com/blog/how-shopee-3xed-their-query-performance-with-starrocks) - [Smartnews](https://medium.com/smartnews-inc/evaluating-a-unified-query-engine-to-consolidate-trino-and-clickhouse-672848c7d55d) - [Splitmetrics](https://celerdata.com/blog/how-splitmetrics-replaced-postgresql-with-starrocks-for-customer-facing-analytics) - [Tencent(Games)](https://www.starrocks.io/blog/tencent-unifies-their-gaming-analytics-with-starrocks) - [Tencent(LLM)](https://www.youtube.com/watch?v=WVHXFks9EQk) - [Trip.com](https://starrocks.medium.com/trip-com-starrocks-efficiently-supports-high-concurrent-queries-dramatically-reduces-labor-and-1e1921dd6bf8) - [TRM Labs](https://www.trmlabs.com/post/from-bigquery-to-lakehouse-how-we-built-a-petabyte-scale-data-analytics-platform-part-1) - [Verisoul](https://celerdata.com/blog/verisoul-enables-real-time-analytics-by-transitioning-off-bigquery) - [Vivo](https://medium.com/starrocks-engineering/vivos-journey-to-a-high-performance-lakehouse-with-starrocks-56a502a0fde8) - [Xiaohongshu/RedNote](https://www.youtube.com/watch?v=2cvIZY4EDak&list=PL0eWwaesODdiJ0aXLzSTyNfkjjIFYpOTf) - [Yuno](https://celerdata.com/blog/from-hours-to-seconds-how-yuno-accelerated-customer-facing-analytics-by-switching-off-snowflake-and-athena) - [Zepto](https://blog.zeptonow.com/data-that-delivers-real-time-insights-for-brand-success-in-quick-commerce-b8b9e994d20b) --- ## 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](https://github.com/StarRocks/starrocks), 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 - [SQL function template](../docs/en/sql-reference/How_to_Write_Functions_Documentation.md) - [SQL command template](../docs/en/sql-reference//SQL_command_template.md) - [FE/BE config and variable template](../docs/en/sql-reference/template_for_config.md) - [Loading data template](../docs/en/loading/Loading_data_template.md) ## 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](https://docs.docker.com/get-docker/) (includes Compose) - Python 3 and [`uv`](https://docs.astral.sh/uv/) - [`gh`](https://cli.github.com/), 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](https://docs.claude.com/en/docs/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 ` ### 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-`, 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-/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](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](../.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 ```