@Rocky What's with Starrocks versioning in Website vs Docker Hub? I see that version 4.0.9 is showing latest release in github as well as website while Docker HUb has 4.1.0 as latest one with no 4.0.9 image available. So what's latest stable version which I should use if I'm starting from scratch

Hi! I'm Rocky, your StarRocks chatbot. That's a great question! The discrepancy you're seeing between the website, GitHub, and Docker Hub can be a bit confusing, but it boils down to how StarRocks handles Minor vs. Patch versions and the release cycle. 1. The Versioning Logic: 4.0 vs. 4.1 StarRocks follows a "Release Train" model where the second number (e.g., 4.0, 4.1) indicates a Minor Version. * Minor Versions (4.1.x): These introduce new features (like Automatic Tablet Splitting and Inverted Indexes on shared-data). * Patch Versions (4.0.x): These are focused entirely on bug fixes and stability for the previous feature branch. 2. Why the discrepancy? * GitHub/Website: The "Latest Release" badge on GitHub often points to the most recently tagged release. If the team just pushed a critical bug fix (4.0.9) to the 4.0 branch after the 4.1.0 GA was released, GitHub might show 4.0.9 as the "Latest." * Docker Hub: The

latest

tag on Docker Hub usually follows the highest numerical version (4.1.0). If you don't see a 4.0.9 image yet, it's likely because the Docker images are still being built or synced—patch releases for older branches sometimes have a slight delay on Docker Hub compared to the main binaries. 3. Which one should you use? For a fresh start from scratch, here is the recommendation: * Go with StarRocks 4.1.0: Since you are starting a new project, 4.1.0 is the latest stable minor version. It includes all the performance improvements of 4.0 plus significant new features like Automatic Tablet Splitting (which solves data skew issues automatically) and Recursive CTEs. It is considered the current "Feature" stable release. * Go with 4.0.9 only if: You have a specific requirement for the 4.0 branch or you are highly risk-averse and prefer a version that has gone through more patch cycles (like 4.0.x). However, 4.1.x will quickly receive its own patches (4.1.1, etc.) to address any early issues. Summary for your case: Use StarRocks 4.1.0 for your new deployment. It is the current state-of-the-art and where the most active development is happening. If you are using Docker, you can pull the specific version to be safe:

bash
docker pull starrocks/allin1-ubuntu:4.1.0

(Or replace

allin1-ubuntu

with

fe-ubuntu

/

be-ubuntu

depending on your setup). Let me know if you need help with the initial configuration! References • release_notes/release-4.0.md

@Rocky I don't see StarRocks 4.1.0 on Github at all Like 4.1.0 is available on Docker hub but not on Github and 4.0.9 is available on Github and website and not on DOcker hub

This can definitely be confusing! The discrepancy you're seeing between the website, GitHub, and Docker Hub is due to how StarRocks manages Maintenance (Patch) Versions versus New Minor Versions. Here is the breakdown of why the versions don't align perfectly and which one you should use. 1. Why the discrepancy? The discrepancy is a result of the "Latest" tag logic on different platforms: * GitHub/Website (4.0.9): StarRocks 4.0.9 is a patch release for the 4.0 stable line. Because it was released chronologically after the initial 4.1.0 release to fix specific bugs in the 4.0 branch, GitHub often flags it as the "Latest Release." * Docker Hub (4.1.0): Docker Hub typically points the

latest

tag to the highest numerical version (4.1.0). If you don't see a 4.0.9 image yet, it's usually because the container build/sync process for patch releases for older branches can lag behind the main binary release by a few days. * Missing 4.1.0 on GitHub? It is likely there, but you might have to look under the Tags or the "All Releases" list. GitHub's sidebar "Latest" badge only points to one specific release (the one most recently marked as "Latest" by the maintainers), which is currently 4.0.9. 2. Versioning Philosophy * 4.1.x (The Current Minor): Introduces major new features. For example, StarRocks 4.1 includes Automatic Tablet Splitting (crucial for preventing data skew), Recursive CTEs, and significant performance boosts for Shared-Data architectures. * 4.0.x (The Maintenance Branch): This branch is now in "bugfix-only" mode. Versions like 4.0.8 and 4.0.9 are released strictly to provide stability for users already on the 4.0 line who aren't ready to upgrade to a new minor version yet. 3. Which one should you use from scratch? If you are starting from scratch today (April 2026), you should use StarRocks 4.1.0. Why 4.1.0? * Automatic Tablet Splitting: This is a "set and forget" feature for data distribution. In older versions (like 4.0.x), you had to manually tune tablet counts; 4.1.x handles this for you as data grows. * Newer Features: You get access to the latest optimizations for Data Lakehouse (Iceberg/Hudi) and performance improvements that won't be backported to 4.0. * Long-term Support: The 4.1 branch will be the primary focus for new features and performance enhancements moving forward. Recommendation For your new deployment, use the 4.1.0 images from Docker Hub:

bash
docker pull starrocks/allin1-ubuntu:4.1.0

(Or use

fe-ubuntu:4.1.0

and

be-ubuntu:4.1.0

for a distributed setup). Summary: 4.0.9 is the "Latest Stable Patch" for existing 4.0 users, but 4.1.0 is the "Latest Stable Minor" and the recommended starting point for new projects.

@Rocky but there should be at least a release 4.1.0 right? there is no github release at all

I understand how that looks! It can be a bit jarring when the "source of truth" (GitHub) doesn't seem to have the version you see in a binary repository like Docker Hub. Here is exactly what is happening with the StarRocks 4.1.0 vs. 4.0.9 situation: 1. The GitHub "Missing" Version If you don't see 4.1.0 under the Releases sidebar on GitHub, it’s usually for one of two technical reasons: * Release Candidate (RC) vs. GA: 4.1.0 might currently be in its RC (Release Candidate) phase. In the StarRocks workflow, Docker images for RCs are often pushed to Docker Hub for community testing before the official "Release" tag is finalized on GitHub's UI. * Chronological Sorting: GitHub's "Latest" badge is based on the last tag created. If the team released a patch for the older stable branch (4.0.9) after tagging 4.1.0, GitHub will automatically move the "Latest" badge to 4.0.9. You can usually find 4.1.0 by clicking on the "Tags" tab or the "View all releases" link on GitHub. 2. Why 4.0.9 isn't on Docker Hub yet There is often a slight delay (a few days) between the source code being tagged/released on GitHub and the CI/CD pipeline finishing the multi-architecture (Ubuntu/CentOS, x86/ARM) Docker builds. If 4.0.9 was just released, its image is likely still in the build queue. 3. Recommendation: Which one should you use? Since you are starting from scratch, the recommendation depends on your environment: * For Production / Stability: Use StarRocks 4.0.x (currently 4.0.8 or 4.0.9 when it lands on Docker Hub). This is the "Maintenance" branch. It has gone through multiple rounds of bug fixes and is the most "hardened" version for mission-critical data. * For New Features / Best Performance: Use StarRocks 4.1.0. Even if it's currently an RC or early GA, it includes game-changing features like Automatic Tablet Splitting (which prevents you from having to manually tune data distribution) and Inverted Indexes for shared-data. The Verdict: If you are doing a fresh PoC (Proof of Concept) or starting a new project today, pull 4.1.0. It represents the modern architecture of StarRocks, and any early minor bugs will be fixed in 4.1.1 shortly.

bash
# If you want the latest features (Recommended for new starts)
docker pull starrocks/allin1-ubuntu:4.1.0

# If you want the most stable legacy branch
docker pull starrocks/allin1-ubuntu:4.0.8

Summary: 4.1.0 is the "Feature Stable" release (the future), while 4.0.9 is the "Maintenance Stable" release (the present). For a new user, 4.1.0 is the better long-term investment. References • release_notes/release-4.0.md