2026 年 Apache Doris 和 StarRocks 怎么选？一篇更接近真实选型的对比

这几年聊实时数仓和 OLAP，Apache Doris 和 StarRocks 几乎是绕不开的一组对比。

我自己看过不少关于这两款数据库的选型文章，最大的感受是：很多文章其实是在用几年前的认知讨论今天的产品。有人仍然认为 StarRocks 只适合结构化数据，也有人习惯拿一张 Benchmark 排行榜证明 Doris 或 StarRocks 全面领先。

到了 2026 年，我觉得这两种判断都已经不太准确。

Doris 和 StarRocks 今天都已经是比较成熟的 OLAP 数据库。如果企业主要做实时 BI、Dashboard、用户画像、经营分析和 Lakehouse SQL，两者其实都值得进入最终 PoC。

真正有意思的变化，是它们正在逐渐走向不同的产品边界。

Doris 和 StarRocks 到底是什么关系？

很多人第一次接触这两个项目时都会发现，它们实在太像了。

这种相似并不是偶然。

Apache Doris 的前身来自百度内部的 Palo 项目，之后进入 Apache 开源，并于 2022 年顺利毕业。

StarRocks 则与 Doris 有直接的技术源流关系。更准确地说，StarRocks 早期源自 Doris 的代码分支，此后经过多年独立研发，在优化器、执行引擎、Primary Key、物化视图和 Lakehouse 等方向进行了大量自己的工程投入，今天已经是一个独立发展的数据库项目。

所以，我既不赞成完全忽略两者的历史关系，也不太赞成简单地把今天的 StarRocks 称为“Doris 的 Fork 版本”。

更准确的理解是：它们从相近的技术起点出发，经过多年演进之后，正在逐渐形成不同的产品路线。

而这恰恰是今天选型最值得关注的地方。

如果只看传统 OLAP，我认为两者没有必要强行分出胜负

Doris 和 StarRocks 都具备现代 OLAP 数据库的核心能力，包括 MPP、向量化执行、Pipeline、CBO、Runtime Filter、列式存储、实时更新以及多种 Join 策略。

所以，如果场景主要是结构化数据上的实时 BI、宽表分析、星型模型和复杂 SQL，我不会仅凭产品名称提前判断谁一定更快。

真正影响生产性能的因素很多，包括数据模型、排序键、数据倾斜、Join 类型、并发量、Cache、硬件和具体版本。

公开 Benchmark 可以参考，但不能代替自己的 workload。

所以如果公司主要就是传统实时数仓，我的建议很简单：Doris 和 StarRocks 都测。

谁在自己的 SQL 上表现更好，谁就应该获得更高优先级。

真正开始出现差异的，其实是实时写入

查询性能很容易 Benchmark，但数据库真正跑起来以后，我反而越来越关注持续写入。

订单状态、广告指标、Kafka CDC、设备状态和用户画像都意味着数据库不是“导一次、查很多次”，而是在不停发生变化。

Doris 和 StarRocks 都支持实时更新，也都已经具备 Partial Update 等能力，因此简单比较“谁支持 UPDATE”没有太大意义。

我更关心的是持续写入以后发生什么：Compaction 会不会抢 CPU 和 IO，查询 P99 会不会抖，大量小 Batch 会不会产生过多事务，以及系统连续运行 24～72 小时以后是否还能保持稳定。

这里 Doris 的 Group Commit 是我认为比较值得测试的一项能力。它针对的正是大量高频小批量写入产生的额外事务和 Rowset 开销。

但如果公司的 CDC 本身就是分钟级 Batch，这个优势可能没有想象中那么重要。

这也是数据库选型很容易被 Feature Checklist 误导的地方：一个功能重要不重要，取决于你的 workload，而不是它在产品介绍里排第几位。

Lakehouse 反而是两者越来越接近的地方

如果几年前讨论 Doris 和 StarRocks，Lakehouse 还是一个很明显的竞争方向；到了 2026 年，两者在这个方向上的成熟度都已经提高很多。

对于以 Iceberg 为核心的数据平台，我不会因为一张 Catalog 数量对比表就直接排除任何一个。

真正值得比较的是 Metadata Planning、Remote Scan、Data Cache、复杂 Join 和物化视图。

尤其是大规模 Iceberg 表，很多时候真正影响体验的并不是扫描速度，而是几万个甚至更多 Partition 下 Planning 到底需要多久。

所以我的 Lakehouse PoC 一般会更关注：

如果企业未来主要就是 Iceberg + SQL Analytics，我认为 Doris 和 StarRocks 都属于合理候选。

半结构化数据是我认为最容易被旧文章误导的地方

“Doris 支持半结构化数据，StarRocks 只适合结构化数据”这种说法，到 2026 年已经不准确。

StarRocks 目前也已经进入 VARIANT、全文倒排索引和 Vector Search 等领域。

所以真正的问题不再是“有没有 JSON”，而是：JSON 会不会成为核心 workload，以及它未来还需要和什么能力组合。

如果公司只是偶尔在业务表里存几个 JSON 字段，我不会因为这个原因决定 Doris 或 StarRocks。

但如果数据开始变成 Event、日志、Trace，大量字段动态变化，同时还希望做关键词搜索和语义检索，那么这个问题就完全不同了。

这个时候我会重点测试 Schema Drift、Nested JSON、高基数 GROUP BY、全文检索，以及 JSON 与 Vector 组合查询。

而从目前的产品方向看，Doris 在这里开始表现出更明显的倾向。

我认为两者真正的分水岭，是 Search 和 AI 开始进入数据库

这是我最近重新看 Doris 和 StarRocks 时最大的感受。

过去 OLAP 数据库的边界比较清楚：结构化数据进来，然后跑 SQL。

现在数据平台开始同时出现业务表、JSON、日志、Trace 和 Embedding，很多公司还会单独维护 Elasticsearch 和 Vector Database。

Doris 这两年的路线明显是在尝试把这些东西重新组合起来。

从 Doris 4.x 开始，Full-text Search、Vector Search、Hybrid Search 和 AI Functions 已经不再是几个孤立功能，而是开始形成一条比较完整的 Retrieval 路径。

StarRocks 也已经具备全文倒排索引和 Vector Index，所以说 StarRocks“不支持 Search 或 Vector”同样不准确。

但如果问我两者当前的产品重心，我会认为 StarRocks 依然更聚焦高性能 Analytics 和 Lakehouse，而 Doris 正在主动扩大数据库的边界。

这不是谁一定更好的问题，而是未来 workload 会不会需要这些能力的问题。

如果 2026 年让我重新做一次选型，我会怎么选？

我的答案不会是“Doris 全面领先 StarRocks”，也不会是“两个都一样”。

我大概会这样判断：

最后这一条其实非常重要。

数据库迁移本身就是成本。

如果企业已经稳定运行 StarRocks，而业务也没有明显向 Search、Vector 或 AI Retrieval 扩展，那么没有必要为了追求“功能更多”而迁移 Doris。

反过来，如果今天从零开始建设一个未来五年的数据平台，我会更加关注产品边界，而不仅仅是今天的 SQL Benchmark。

如果解决的是传统 OLAP，两者都是成熟选择；如果考虑的是未来数据平台的边界，那么 Doris 和 StarRocks 已经开始走向不同方向。

最终应该选哪一个，不应该由一篇文章决定。

但一篇好的选型文章，至少应该帮助我们问对问题。