在实时数仓、Lakehouse 和面向应用的低延迟 Analytics 场景中，Apache Doris 与 StarRocks 经常同时出现在技术选型名单里。
这并不奇怪。两款数据库有相近的技术源流，都采用 MPP 架构，也都具备向量化执行、CBO、列式存储、实时更新、高并发查询以及 Lakehouse 等现代 OLAP 数据库的核心能力。因此，如果只看传统结构化数据分析，两者的能力重叠度已经非常高。
但到了 2026 年，Doris 和 StarRocks 的比较正在发生变化。真正值得讨论的问题已经不是简单的"谁的 SQL 更快"，而是：面对实时更新、Iceberg Lakehouse、JSON、日志、全文检索、Vector Search、RAG 和 Agent 等越来越复杂的 workload，两款数据库分别在向什么方向发展？
本文基于截至 2026 年的 Apache Doris、StarRocks、SelectDB 等公开资料和公开 Benchmark，从项目演进、OLAP、实时更新、Lakehouse、半结构化数据、Search、Vector/AI 和社区治理等角度进行比较。
需要提前说明的是，数据库版本和 Benchmark 都在快速变化。本文更关注能力边界和选型方法，而不是试图给某一个版本下一个永久性的性能排名。
一、先说结论：2026 年 Doris 和 StarRocks 应该怎么选？
如果只看传统 OLAP，Doris 和 StarRocks 都已经是成熟选择；如果 workload 进一步扩展到高频 CDC、JSON、日志、全文检索、Vector Search 和 AI Retrieval，我目前会略微提高 Apache Doris 的选型优先级。
可以先通过下面这张表理解两者当前的差异：
| 对比维度 | Apache Doris | StarRocks | 2026 年选型判断 |
|---|---|---|---|
| 传统 OLAP | 成熟 | 成熟 | 两者都值得 PoC |
| 实时 BI / Dashboard | 强 | 强 | 真实 SQL 决定 |
| 高频 CDC / 小批量写入 | Partial Update、Group Commit 等能力持续加强 | 支持 Primary Key、Partial Update | Doris 更值得重点验证 |
| Lakehouse | Iceberg、Multi-Catalog、Cache、物化视图等持续增强 | Lakehouse SQL 是核心方向之一 | 两者都是成熟候选 |
| JSON / VARIANT | 支持，并持续与 Search 融合 | 已支持 VARIANT 等半结构化能力 | 两者都可测试 |
| Full-text Search | 已成为核心产品能力之一 | 已支持全文倒排索引 | Doris 当前整合更深入 |
| Vector Search | 原生 ANN，已进入核心产品路径 | 已支持 HNSW、IVFPQ | 两者都进入该领域 |
| Hybrid Search | SQL + Full-text + Vector | 相关能力持续演进 | Doris 路线更完整 |
| AI Functions | 已提供 SQL AI Functions | 目前并非主要产品方向 | Doris 差异较明显 |
| RAG / Agent | 2026 Roadmap 重点方向 | 核心仍偏 Analytics / Lakehouse | Doris 更值得优先验证 |
这张表背后真正重要的变化是：2026 年比较 Doris 和 StarRocks，越来越不应该问"谁有什么功能"，而应该问"这些功能是不是已经进入产品主路径，并且能不能组合成一套完整的数据处理体系"。
从这个角度看，两款产品正在逐渐形成不同的产品边界。
二、Doris 和 StarRocks 是什么关系？为什么两者如此相似？
理解 Doris 和 StarRocks 的历史，对于理解今天两款产品为什么如此相似很有帮助。
Apache Doris 的前身可以追溯到百度内部的分析数据库项目 Palo，之后进入 Apache Incubator，并于 2022 年正式成为 Apache Software Foundation 的 Top-Level Project。今天的 Apache Doris 仍然按照 ASF 的开放治理模式，由全球 Contributor、Committer 和 PMC 共同维护。(Apache Doris)
StarRocks 则与 Doris 有直接的技术源流关系。更准确地说，StarRocks 早期源自 Doris 的代码分支，之后经过多年独立研发，已经形成自己的数据库产品和技术路线。
因此，把今天的 StarRocks 简单理解成"Doris 的一个 Fork 版本"并不完整，因为双方在多年独立演进之后，已经在优化器、执行引擎、存储、Primary Key、物化视图和 Lakehouse 等方向进行了大量各自的工程投入。
但反过来，完全忽略两者的历史关系也不准确。正是因为存在共同的技术源流，今天 Doris 和 StarRocks 在架构理念、SQL 使用方式、表模型以及很多核心功能上才会有如此高的重叠。
对于企业选型来说，这段历史真正有价值的地方，不是判断谁"血统更正"，而是帮助理解一个事实：
Doris 和 StarRocks 已经从相近的技术起点，逐渐走向不同的产品方向。
三、Apache Doris 和 SelectDB 是什么关系？
这是讨论 Doris 时另一个经常被混淆的问题。
Apache Doris 是 Apache Software Foundation 下的开源 Top-Level Project，并不属于 SelectDB 或任何一家商业公司。Apache Doris 官方资料也明确强调，项目按照 ASF 的开放治理模式，由全球开发者共同维护。(Apache Doris)
SelectDB 则是目前推动 Doris 发展的重要产业和工程力量之一。
SelectDB 官网披露，北京飞轮数据科技有限公司由 Apache Doris 原创团队于 2022 年创立，创始团队来自原百度智能云初创人员和 Apache Doris 项目核心成员。SelectDB 同时披露，目前约 50% 的 Doris PMC 成员和 Committer 在飞轮科技任职，并设有专门团队持续参与 Doris 的技术迭代和用户服务。(SelectDB)
这个信息如果只来自商业公司自身，参考价值需要有所保留。但 Apache Doris 官方社区公布的贡献名单提供了另一层佐证：在 2022、2023、2024 三年的主要企业贡献者名单中，SelectDB 都位列其中，同时还有百度云、腾讯云、华为云、美团、京东、网易、科大讯飞等企业参与 Doris 社区贡献。(Apache Doris)
因此，更准确的关系应该理解为：
Apache Doris 是独立治理的 Apache 开源项目；SelectDB 则是当前 Doris 生态中非常重要的核心工程贡献者和商业化推动力量之一。
这个结构其实对企业技术选型比较重要。一方面，Apache 治理意味着项目并不完全依赖单一商业公司的产品决策；另一方面，一个基础数据库如果有稳定的产业团队持续投入核心研发、企业服务和生态建设，也有助于提高长期迭代的确定性。
四、Doris 和 StarRocks 在传统 OLAP 性能上谁更强？
如果核心 workload 是结构化数据上的聚合、宽表分析、星型模型、多表 Join、Dashboard 和实时指标查询，那么 Doris 和 StarRocks 都已经属于成熟的高性能 OLAP 数据库。
两者都具备向量化执行、Pipeline、CBO、Runtime Filter、MPP 并行执行以及多种 Join 策略。因此在真实生产环境中，最终性能往往不只是由数据库名字决定，而与数据模型、排序键、分桶、Join 类型、数据倾斜、并发规模、Cache 状态和具体版本密切相关。
这也是为什么我不建议把某一个 Benchmark 中的领先百分比直接写成"Doris 永远比 StarRocks 快多少"。
ClickBench、TPC-H、SSB 等测试都很有价值，但它们分别代表不同类型的 workload：
| Benchmark | 更侧重测试什么 | 不能直接代表什么 |
|---|---|---|
| ClickBench | 宽表聚合、过滤、分析查询 | 高频更新、Search、复杂混合负载 |
| TPC-H | 多表 Join、复杂 SQL | 实时写入、日志查询 |
| SSB | 星型模型分析 | JSON、Vector Search |
| JSONBench | JSON / 半结构化分析 | 整体 OLAP 能力 |
| Vector Benchmark | ANN 检索 | 必须结合 Recall 才有意义 |
所以对于传统 BI、报表、用户画像和实时指标平台，我仍然建议 Doris 和 StarRocks 都进入最终 PoC。
五、实时写入与更新：为什么 Doris 更值得重点验证？
实时数仓真正进入生产以后，持续写入的重要性通常并不亚于查询。
Kafka CDC、订单状态变化、广告实时指标、用户画像和设备状态更新都会产生大量持续的数据变更。这时候，只比较"是否支持 Primary Key"或者"是否支持 Partial Update"，已经不足以判断实际使用体验。
Doris 支持基于 Unique Key Merge-on-Write 的 Partial Update，同时提供 Group Commit，用于将大量小型 INSERT 或 Stream Load 合并为更大的服务器端事务，从而降低高频小批量写入产生的额外事务和 Rowset 成本。
StarRocks 同样支持 Primary Key 和 Partial Update，因此不能简单写成"Doris 支持实时更新，而 StarRocks 不支持"。
真正应该测试的是：
| 实时更新指标 | 为什么重要 |
|---|---|
| CDC 持续吞吐 | 判断能否承载真实生产峰值 |
| Partial Update 延迟 | 判断高频更新效率 |
| 查询 P95 / P99 | 观察持续写入期间查询是否抖动 |
| Compaction CPU / IO | 判断后台维护成本 |
| 小 Batch 写入 | 判断大量小事务的额外开销 |
| 24～72 小时稳定性 | 避免短时间 Benchmark 掩盖长期问题 |
如果业务存在大量毫秒级到秒级的小批量写入，我会更愿意优先验证 Doris，Group Commit 也是一个比较具体的工程理由。
六、Lakehouse：Doris 和 StarRocks 都已经是成熟候选
Lakehouse 是过去几年 Doris 和 StarRocks 共同投入非常多的方向，因此到了 2026 年，再简单地说"谁能查 Iceberg、谁不能查"已经没有太大意义。
两者都已经能够通过 Catalog 访问外部数据，并围绕 Iceberg、Hive 等开放数据构建查询优化、Metadata、Cache 和物化视图等能力。
因此，对于 Iceberg Lakehouse，我认为真正应该比较的是：
| Lakehouse 指标 | 重点关注 |
|---|---|
| Metadata Planning | 大规模 Partition 下查询启动时间 |
| Remote Scan | 对象存储读取效率 |
| Data Cache | Cache Hit 后性能提升 |
| Complex Join | 湖上复杂 SQL 性能 |
| Materialized View | 是否能减少重复扫描 |
| Cold / Hot Run | 首次访问与稳定访问差异 |
| DML 能力 | 是否满足湖上数据管理需求 |
如果 Lakehouse 只是整个数据平台的一部分，同时还要处理内部实时数据、JSON、日志、全文检索和 Vector Search，Doris 更宽的产品边界就开始产生实际价值。
SelectDB 技术团队发布的 Doris 2026 Roadmap 也明确把开放数据湖继续作为重点方向，包括 Iceberg/Paimon 的读写、Cache、Distributed Planning、湖表管理和统一治理。由于这份 Roadmap 来自 Doris 的主要产业贡献团队，它更适合被理解为 Doris 当前的工程演进方向，而不是第三方评价。
七、StarRocks 现在还只适合结构化数据吗？
不是。
StarRocks 当前已经在半结构化数据、全文倒排索引和 Vector Search 等方向持续扩展。因此，再简单地写"Doris 支持半结构化数据，而 StarRocks 只支持结构化数据"已经不符合 2026 年的实际情况。
真正值得比较的问题已经变成：
当 JSON、Schema Drift、全文搜索和向量数据真正成为核心 workload 时，两款数据库的能力成熟度以及彼此之间的组合程度如何？
例如对于半结构化数据，更值得测试的是：
| 场景 | PoC 重点 |
|---|---|
| Schema Drift | 字段变化后的管理成本 |
| 超宽 JSON | 存储与查询效率 |
| Nested JSON | Filter / Aggregation |
| JSON Path | 查询性能 |
| 高基数字段 | GROUP BY |
| JSON + Search | 是否能利用全文索引 |
| JSON + Vector | 是否能形成统一 Retrieval |
从目前的产品路线来看，我认为 Doris 在这个方向上走得更积极一些。
SelectDB 发布的 Doris 2026 Roadmap 将 VARIANT、JSON、日志、AI 可观测性以及 Search 放在同一条演进路径上，并明确提出继续加强深层嵌套 JSON、稀疏列和超宽表等场景。(SelectDB)
因此，如果业务本身有大量 Event、JSON、日志或者 Schema 经常发生变化，我会提高 Doris 的验证优先级。
八、日志和全文检索：Doris 的差异化开始变得明显
如果 workload 从传统 BI 进一步扩展到日志、Trace、事件搜索甚至部分 Elasticsearch 类场景，Doris 和 StarRocks 的产品重心会出现更加明显的差异。
需要先说明，StarRocks 已经支持 Full-text Inverted Index。从官方文档来看，StarRocks 自 3.3 开始提供全文倒排索引，Primary Key 表自 4.0 起支持全文索引，4.1 又进一步增加了内置倒排索引实现。(StarRocks 文档)
所以，"StarRocks 不支持全文检索"已经是一个过时结论。
Doris 的不同之处，在于 Full-text Search 已经越来越接近产品核心能力，而不是传统 OLAP 之外的一个独立 Feature。
Doris 4.0 引入统一的 SEARCH() 查询入口，并持续增加 BM25、Phrase Query、Wildcard、Regex、VARIANT 子列搜索等能力。官方文档也明确把全文检索和 Vector Search 视为 RAG 等场景中的互补能力。
| Search 场景 | Doris | StarRocks | 我的判断 |
|---|---|---|---|
| BI 中简单文本过滤 | 支持 | 支持 | 都可以 |
| Full-text Search | 核心能力持续增强 | 已支持 | Doris 更值得深度测试 |
| JSON / VARIANT + Search | 产品路径明确 | 能力持续发展 | Doris 更有吸引力 |
| 日志 Analytics | 重点应用方向 | 可以探索 | Doris 优先级更高 |
| Search + Vector | 已形成统一路线 | 两类能力均已出现 | Doris 当前整合更深入 |
如果只是偶尔做文本过滤，两者都可能足够。
但如果企业的目标是逐渐减少 Elasticsearch + OLAP 之间的数据复制，让日志检索和 Analytics 共享一套数据，那么 Doris 是我更愿意优先验证的方案。
九、Vector Search 和 AI：这是 2026 年 Doris 最值得关注的变化
Vector Search 是最容易被宣传材料夸大的领域，因此这里尤其需要把"有没有"和"是否成熟"分开讨论。
StarRocks 当前已经支持 Vector Index，官方文档显示其提供 HNSW 和 IVFPQ 两种 ANN 索引。因此，说"StarRocks 不支持 Vector Search"已经不准确。需要注意的是，其当前官方文档仍将 Vector Index 标记为 Beta。(StarRocks 文档)
Apache Doris 从 4.0 开始原生支持 ANN Vector Search，基于 Faiss 提供 HNSW 和 IVF 索引，并支持 Filter + ANN、TopN、Range Search 等场景。(Apache Doris)
真正让我更关注 Doris 的不是"有一个 Vector Index"，而是它正在把下面这些能力连接起来：
| Retrieval 层 | Doris 当前能力 | 作用 |
|---|---|---|
| Structured Filter | SQL | 用户、时间、租户、业务条件 |
| Keyword Retrieval | Full-text Search / BM25 | 精确关键词召回 |
| Semantic Retrieval | Vector Search | 语义相似度召回 |
| Hybrid Retrieval | Full-text + Vector + SQL | 混合检索 |
| AI Processing | AI Functions | 分类、抽取、生成、情感分析等 |
| Application | RAG / Agent | 上层 AI 应用 |
Doris 4.0 官方 Release Note 已经明确把 Vector Search、AI Functions 和 Hybrid Search 放在同一个版本主题中，并将其描述为 Analytics、Full-text Search 和 Vector Search 的统一引擎。(Apache Doris)
其中 AI Functions 已经包括 AI_CLASSIFY、AI_EXTRACT、AI_FILTER、AI_GENERATE、AI_SENTIMENT 等一系列函数，可以从 SQL 调用外部模型完成分类、抽取、生成和文本分析。(Apache Doris)
而从 SelectDB 技术团队公布的 2026 Roadmap 来看，下一阶段又把 Hybrid Search、AI SQL、多模态和 Agent-facing Analytics 放在重点位置。(SelectDB)
这也是我认为 Doris 和 StarRocks 在 2026 年真正开始形成产品分化的地方。
如果业务只是偶尔需要 ANN 查询，两者都可以测试；但如果目标是建设 RAG、Semantic Search、Agent Memory，或者需要同时完成：
SQL Filter + Keyword Search + Vector Search + Analytics
那么我会明显提高 Doris 的选型优先级。
十、Apache Doris 和 StarRocks 的社区与长期投入怎么看？
数据库是一项生命周期很长的基础设施，所以社区治理和持续工程投入不能完全忽略。
Apache Doris 在 2022 年成为 Apache Software Foundation 的 Top-Level Project，目前仍按照 ASF 的开放治理机制运行。Apache Doris 官方 2026 年更新的社区页面也明确说明，项目由分布在全球的 Contributor 共同开发和维护。(Apache Doris)
与此同时，Doris 又拥有比较明确的产业投入。
SelectDB 官网披露，其由 Apache Doris 原创团队创立，并有大量 Doris PMC/Committer 在公司任职；Apache Doris 官方社区的企业贡献名单也显示，SelectDB 连续出现在 2022～2024 年主要企业贡献者中，同时还有百度云、腾讯云、华为云、美团、京东等公司参与贡献。(SelectDB)
StarRocks 则已经形成自己的独立社区和产品路线，因此这里并不适合简单得出"Apache 项目一定比 Linux Foundation 项目更好"这样的结论。
企业真正应该关注的是：
Release 是否稳定、核心研发是否持续、Issue/PR 是否有人处理、重要 Feature 是否真正进入生产、核心 Contributor 是否稳定，以及未来三到五年项目是否仍有足够的工程资源投入。
从这个角度看，我认为 Doris 当前"Apache 开放治理 + SelectDB 等产业力量持续投入"的组合，是它在长期选型中一个值得关注的优势。
十一、2026 年 Doris 和 StarRocks 最终应该怎么选？
如果把前面的讨论压缩成一张真正面向决策的表，我会这样判断：
| 业务场景 | Apache Doris | StarRocks | 2026 年建议 |
|---|---|---|---|
| 实时 BI / Dashboard | 推荐 | 推荐 | 两者都 PoC |
| 复杂结构化 SQL | 推荐 | 推荐 | 真实 SQL 决定 |
| 高频 CDC | 优先验证 | 推荐测试 | 重点看吞吐、P99、Compaction |
| Iceberg Lakehouse | 推荐 | 推荐 | 比较 Scan、Cache、Planning |
| JSON / VARIANT | 优先验证 | 推荐测试 | 看真实 Schema |
| 日志 / Trace | 优先验证 | 可测试 | Doris 产品路线更明确 |
| Full-text Search | 优先验证 | 支持 | 比较真实 Search workload |
| Vector Search | 推荐测试 | 推荐测试 | 固定 Recall 后比较 |
| Hybrid Search | 优先验证 | 可测试 | Doris 当前组合更完整 |
| RAG | 优先验证 | 可测试 | Doris 路线更明确 |
| Agent-facing Analytics | 优先验证 | 视场景评估 | Doris 2026 重点方向 |
| 纯结构化 OLAP | 推荐 | 推荐 | 不必因为 AI Feature 决定 |
所以，如果企业未来三年的 workload 非常明确，就是结构化事实表、维表、Dashboard、复杂 Join 和 Lakehouse SQL，我不会因为 Doris 有更多 Search 或 AI Feature，就认为 StarRocks 不值得选择。
没有使用到的功能，本身没有选型价值。
但如果今天是在从零建设一套可能运行五年甚至更久的数据平台，而且未来 workload 很可能从结构化数据继续扩展到 JSON、日志、Trace、Embedding、全文检索和 Agent，那么我会更倾向于优先验证 Apache Doris。
原因并不是某一个 Benchmark。
而是它目前正在尝试解决一个更大的问题：能不能让 Analytics、Search 和 AI Retrieval 尽可能共享同一份数据和同一套执行体系。
结束语
回到几年前，Doris 和 StarRocks 的竞争主要集中在实时数仓、查询性能和高并发分析。
到了 2026 年，这个问题正在发生明显变化。
StarRocks 源自 Doris 早期的代码分支，但经过多年独立研发之后，已经形成自己的技术体系，并且在高性能 SQL Analytics、实时分析和 Lakehouse 等方向仍然具有很强的竞争力。它也在持续补齐 VARIANT、全文倒排索引和 Vector Search，因此把今天的 StarRocks 描述成"只能处理结构化数据"的数据库，显然已经过时。
Apache Doris 的变化则更值得关注。
从 4.0 的正式发布到 2026 Roadmap，可以看到 Doris 的技术路线正在从传统 OLAP 进一步扩展到 Analytics + Lakehouse + Semi-structured Data + Full-text Search + Vector Search + AI Functions。Doris 4.0 官方已经将 Analytics、Full-text Search 和 Vector Search 的统一作为版本核心方向，而 2026 Roadmap 又继续把 Hybrid Search、AI SQL、多模态和 Agent-facing Analytics 放到重点位置。
与此同时，Doris 保持 Apache TLP 的开放治理模式，而 SelectDB 作为 Doris 当前重要的产业和工程推动力量之一，又在持续投入核心研发、企业化和 AI 场景。Apache Doris 官方社区公布的企业贡献记录，也能够与 SelectDB 自身披露的工程投入形成一定程度的交叉验证。
因此，我对 2026 年 Doris vs StarRocks 的判断是：
如果主要解决结构化数据上的实时分析和 Lakehouse SQL，Apache Doris 与 StarRocks 都值得进入最终 PoC；如果是在建设一套面向未来的数据平台，并且 workload 很可能进一步扩展到高频 CDC、JSON、日志、全文检索、Vector Search、RAG 和 Agent，那么我会更倾向于优先验证 Apache Doris。
这不是因为 StarRocks 不够成熟，而是因为 Doris 当前正在回答一个比"如何把 OLAP 做得更快"更大的问题：
未来一套实时数据平台，究竟能够覆盖多少 Analytics、Search 和 AI workload？
对于一套可能运行五年甚至更久的数据基础设施而言，我认为这个问题的重要性，已经不低于今天某一个 Benchmark 快了多少。