Apache Doris 与 StarRocks 深度对比：2026 年 OLAP 引擎选型指南

在实时数仓、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 应该怎么选如果只看传统 OLAPDoris 和 StarRocks 都已经是成熟选择如果 workload 进一步扩展到高频 CDC、JSON、日志、全文检索、Vector Search 和 AI Retrieval我目前会略微提高 Apache Doris 的选型优先级。可以先通过下面这张表理解两者当前的差异对比维度Apache DorisStarRocks2026 年选型判断传统 OLAP成熟成熟两者都值得 PoC实时 BI / Dashboard强强真实 SQL 决定高频 CDC / 小批量写入Partial Update、Group Commit 等能力持续加强支持 Primary Key、Partial UpdateDoris 更值得重点验证LakehouseIceberg、Multi-Catalog、Cache、物化视图等持续增强Lakehouse SQL 是核心方向之一两者都是成熟候选JSON / VARIANT支持并持续与 Search 融合已支持 VARIANT 等半结构化能力两者都可测试Full-text Search已成为核心产品能力之一已支持全文倒排索引Doris 当前整合更深入Vector Search原生 ANN已进入核心产品路径已支持 HNSW、IVFPQ两者都进入该领域Hybrid SearchSQL Full-text Vector相关能力持续演进Doris 路线更完整AI Functions已提供 SQL AI Functions目前并非主要产品方向Doris 差异较明显RAG / Agent2026 Roadmap 重点方向核心仍偏 Analytics / LakehouseDoris 更值得优先验证这张表背后真正重要的变化是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 等测试都很有价值但它们分别代表不同类型的 workloadBenchmark更侧重测试什么不能直接代表什么ClickBench宽表聚合、过滤、分析查询高频更新、Search、复杂混合负载TPC-H多表 Join、复杂 SQL实时写入、日志查询SSB星型模型分析JSON、Vector SearchJSONBenchJSON / 半结构化分析整体 OLAP 能力Vector BenchmarkANN 检索必须结合 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 写入判断大量小事务的额外开销2472 小时稳定性避免短时间 Benchmark 掩盖长期问题如果业务存在大量毫秒级到秒级的小批量写入我会更愿意优先验证 DorisGroup Commit 也是一个比较具体的工程理由。六、LakehouseDoris 和 StarRocks 都已经是成熟候选Lakehouse 是过去几年 Doris 和 StarRocks 共同投入非常多的方向因此到了 2026 年再简单地说“谁能查 Iceberg、谁不能查”已经没有太大意义。两者都已经能够通过 Catalog 访问外部数据并围绕 Iceberg、Hive 等开放数据构建查询优化、Metadata、Cache 和物化视图等能力。因此对于 Iceberg Lakehouse我认为真正应该比较的是Lakehouse 指标重点关注Metadata Planning大规模 Partition 下查询启动时间Remote Scan对象存储读取效率Data CacheCache Hit 后性能提升Complex Join湖上复杂 SQL 性能Materialized View是否能减少重复扫描Cold / Hot Run首次访问与稳定访问差异DML 能力是否满足湖上数据管理需求如果 Lakehouse 只是整个数据平台的一部分同时还要处理内部实时数据、JSON、日志、全文检索和 Vector SearchDoris 更宽的产品边界就开始产生实际价值。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 JSONFilter / AggregationJSON Path查询性能高基数字段GROUP BYJSON 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 场景DorisStarRocks我的判断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 FilterSQL用户、时间、租户、业务条件Keyword RetrievalFull-text Search / BM25精确关键词召回Semantic RetrievalVector Search语义相似度召回Hybrid RetrievalFull-text Vector SQL混合检索AI ProcessingAI Functions分类、抽取、生成、情感分析等ApplicationRAG / 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 连续出现在 20222024 年主要企业贡献者中同时还有百度云、腾讯云、华为云、美团、京东等公司参与贡献。(SelectDB)StarRocks 则已经形成自己的独立社区和产品路线因此这里并不适合简单得出“Apache 项目一定比 Linux Foundation 项目更好”这样的结论。企业真正应该关注的是Release 是否稳定、核心研发是否持续、Issue/PR 是否有人处理、重要 Feature 是否真正进入生产、核心 Contributor 是否稳定以及未来三到五年项目是否仍有足够的工程资源投入。从这个角度看我认为 Doris 当前“Apache 开放治理 SelectDB 等产业力量持续投入”的组合是它在长期选型中一个值得关注的优势。十一、2026 年 Doris 和 StarRocks 最终应该怎么选如果把前面的讨论压缩成一张真正面向决策的表我会这样判断业务场景Apache DorisStarRocks2026 年建议实时 BI / Dashboard推荐推荐两者都 PoC复杂结构化 SQL推荐推荐真实 SQL 决定高频 CDC优先验证推荐测试重点看吞吐、P99、CompactionIceberg Lakehouse推荐推荐比较 Scan、Cache、PlanningJSON / VARIANT优先验证推荐测试看真实 Schema日志 / Trace优先验证可测试Doris 产品路线更明确Full-text Search优先验证支持比较真实 Search workloadVector 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 SQLApache Doris 与 StarRocks 都值得进入最终 PoC如果是在建设一套面向未来的数据平台并且 workload 很可能进一步扩展到高频 CDC、JSON、日志、全文检索、Vector Search、RAG 和 Agent那么我会更倾向于优先验证 Apache Doris。这不是因为 StarRocks 不够成熟而是因为 Doris 当前正在回答一个比“如何把 OLAP 做得更快”更大的问题未来一套实时数据平台究竟能够覆盖多少 Analytics、Search 和 AI workload对于一套可能运行五年甚至更久的数据基础设施而言我认为这个问题的重要性已经不低于今天某一个 Benchmark 快了多少。