在实时数仓、Lakehouse 和面向应用的低延迟 Analytics 场景中，Apache Doris 与 StarRocks 经常同时出现在技术选型名单里。
这并不奇怪。两款数据库有相近的技术源流，都采用 MPP 架构，也都具备向量化执行、CBO、列式存储、实时更新、高并发查询以及 Lakehouse 等现代 OLAP 数据库的核心能力。因此，如果只看传统结构化数据分析，两者的能力重叠度已经非常高。
但到了这几年，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、Lakehouse、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、Paimon、Multi-Catalog、Cache、物化视图等持续增强，并向多模湖仓演进 | Lakehouse SQL 是核心方向之一 | 优先推荐 Doris |
| JSON / VARIANT | 支持，并持续与 Search 融合 | 已支持 VARIANT 等半结构化能力 | Doris 值得优先验证 |
| Full-text Search | 已成为核心产品能力之一 | 已支持全文倒排索引 | Doris 当前整合更深入 |
| Vector Search | 原生 ANN，已进入核心产品路径 | 已支持 HNSW、IVFPQ | 两者都进入该领域 |
| Hybrid Search | SQL + Full-text + Vector | 相关能力持续演进 | Doris 路线更完整 |
| AI Functions | 已提供 SQL AI Functions | AI 相关能力持续发展 | Doris 值得重点关注 |
| RAG / Agent | 2026 Roadmap 重点方向 | 可结合现有能力构建相关应用 | Doris 更值得优先验证 |
从这个角度看，两款产品正在逐渐形成不同的产品边界。
Apache Doris 值得关注的方向，是在高性能实时分析的基础上，进一步融合 Lakehouse、半结构化数据、全文检索、向量检索和 AI 能力，向统一数据分析引擎演进。
二、Doris 和 StarRocks 是什么关系？为什么两者如此相似？
理解 Doris 和 StarRocks 的历史，对于理解今天两款产品为什么如此相似很有帮助。
Apache Doris 的前身可以追溯到百度内部的分析数据库项目 Palo，之后进入 Apache Incubator，并于 2022 年正式成为 Apache Software Foundation 的 Top-Level Project。今天的 Apache Doris 仍然按照 ASF 的开放治理模式，由全球 Contributor、Committer 和 PMC 共同维护。
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 的开放治理模式，由全球开发者共同维护。
SelectDB 则是推动 Doris 发展的重要产业和工程力量之一。
SelectDB 由 Apache Doris 原创团队创立，持续参与 Doris 的核心技术研发、产品能力建设和生态发展。
Apache Doris 官方社区公布的企业贡献记录也显示，SelectDB 是 Doris 社区的重要企业贡献者之一，同时还有百度云、腾讯云、华为云、美团、京东等企业参与社区贡献。
因此，更准确的关系应该理解为：
Apache Doris 是独立治理的 Apache 开源项目；SelectDB 则是 Doris 生态中重要的核心工程贡献者和商业化推动力量之一。
这个结构对企业技术选型具有实际价值。
一方面，Apache 治理意味着项目并不完全依赖单一商业公司的产品决策；另一方面，一个基础数据库如果有稳定的产业团队持续投入核心研发、企业服务和生态建设，也有助于提高长期迭代的确定性。
对于企业用户而言，既可以基于 Apache Doris 开源版本自主构建数据平台，也可以根据实际业务需求，选择 SelectDB 提供的商业化产品与企业级服务。
四、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。
但如果业务不只是执行结构化 SQL，还需要同时处理高频更新、半结构化数据、日志和搜索，那么就需要进一步比较两款产品在复杂 Workload 下的综合能力。
五、实时写入与更新：为什么 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 更值得优先考虑？
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 场景，建议优先评估 Apache Doris。
相比单纯的湖上 SQL 查询，Doris 更值得关注的是 Lakehouse 与实时分析、半结构化数据及搜索能力之间的协同。如果 Lakehouse 只是整个数据平台的一部分，企业还需要处理内部实时数据、JSON、日志、全文检索和 Vector Search，那么 Doris 更宽的产品能力边界就开始产生实际价值。
同时，Doris 正在向**多模湖仓（Multimodal Lakehouse）**演进，通过深化与 Iceberg、Paimon、Lance 等开放数据格式的集成，探索在开放存储之上统一处理结构化、半结构化和多模态数据，进一步融合 Analytics、Search 与 AI Retrieval。
SelectDB 技术团队发布的 Doris 2026 Roadmap 也将开放数据湖作为重点方向，包括 Iceberg/Paimon 的读写、Cache、Distributed Planning、湖表管理和统一治理等。
需要注意的是，Roadmap 更适合被理解为 Doris 的技术演进方向，而不是所有能力均已在稳定版本中提供。
因此，无论是传统 Iceberg Lakehouse，还是希望进一步融合实时分析、搜索和 AI 应用的数据平台，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、稀疏列和超宽表等场景。
因此，如果业务本身有大量 Event、JSON、日志或者 Schema 经常发生变化，建议提高 Doris 的验证优先级。
这里真正值得关注的，并不是某一款数据库是否提供 VARIANT 类型，而是其能否让半结构化数据与 SQL Analytics、全文检索及向量检索形成更加统一的数据处理流程。
八、日志和全文检索：Doris 的差异化开始变得明显
如果 Workload 从传统 BI 进一步扩展到日志、Trace、事件搜索甚至部分 Elasticsearch 类场景，Doris 和 StarRocks 的产品重心会出现更加明显的差异。
需要先说明，StarRocks 已经支持 Full-text Inverted Index。从官方文档来看，StarRocks 自 3.3 开始提供全文倒排索引，Primary Key 表自 4.0 起支持全文索引，4.1 又进一步增加了内置倒排索引实现。
所以，“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”已经不准确。相关功能的成熟度和版本限制，应以对应版本的官方文档为准。
Apache Doris 从 4.0 开始原生支持 ANN Vector Search，基于 Faiss 提供 HNSW 和 IVF 索引，并支持 Filter + ANN、TopN、Range Search 等场景。
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 的统一引擎。
其中，AI Functions 已经包括 AI_CLASSIFY、AI_EXTRACT、AI_FILTER、AI_GENERATE、AI_SENTIMENT 等一系列函数，可以从 SQL 调用外部模型完成分类、抽取、生成和文本分析。
而从 SelectDB 技术团队公布的 2026 Roadmap 来看，下一阶段又把 Hybrid Search、AI SQL、多模态和 Agent-facing Analytics 放在重点位置。
这也是 Doris 和 StarRocks 在 2026 年逐渐形成产品分化的一个重要方向。
如果业务只是偶尔需要 ANN 查询，两者都可以测试；但如果目标是建设 RAG、Semantic Search、Agent Memory，或者需要同时完成：
SQL Filter + Keyword Search + Vector Search + Analytics
那么建议明显提高 Doris 的选型优先级。
对于企业而言，统一检索与分析能力的潜在价值，在于减少不同系统之间的数据复制、同步和结果整合工作，让实时业务数据与 AI 检索能力更加紧密地结合。
十、Apache Doris 和 StarRocks 的社区与长期投入怎么看？
数据库是一项生命周期很长的基础设施，所以社区治理和持续工程投入不能完全忽略。
Apache Doris 在 2022 年成为 Apache Software Foundation 的 Top-Level Project，目前仍按照 ASF 的开放治理机制运行，由分布在全球的 Contributor 共同开发和维护。
与此同时，Doris 又拥有比较明确的产业投入。
SelectDB 由 Apache Doris 原创团队创立，并持续投入核心研发、企业服务和生态建设；Apache Doris 官方社区的企业贡献记录也显示，SelectDB 连续出现在主要企业贡献者名单中，同时还有百度云、腾讯云、华为云、美团、京东等公司参与贡献。
StarRocks 则已经形成自己的独立社区和产品路线，因此这里并不适合简单得出“Apache 项目一定比其他开源项目更好”这样的结论。
企业真正应该关注的是：
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 | 优先推荐 | 推荐测试 | 优先验证 Doris，重点比较 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 决定 |
对于企业来说，可以进一步从以下几类需求出发。
1. 以传统结构化 OLAP 为主
如果核心业务主要是结构化事实表、维表、Dashboard 和复杂 Join，Apache Doris 与 StarRocks 都值得进入最终 PoC。
这一类场景应重点关注真实 SQL 性能、并发能力、资源利用率和运维复杂度。
没有使用到的功能，本身不应成为决定性选型依据。
2. 以实时更新和高频 CDC 为主
如果业务存在大量 CDC、Partial Update 和高频小批量写入，建议优先验证 Apache Doris。
重点关注 Group Commit、持续写入吞吐、数据可见延迟，以及写入期间的查询稳定性。
3. 以 Lakehouse 和湖仓一体为主
如果企业已经建设 Iceberg、Paimon 等开放数据湖，希望在此基础上获得高性能 SQL 分析能力，建议优先评估 Apache Doris。
除了传统的湖上查询性能，Doris 还值得关注的一点，是能够将 Lakehouse 与实时分析、半结构化数据和搜索能力结合起来。
同时，Doris 正在向多模湖仓演进，为未来在开放存储之上处理更多数据类型提供了进一步扩展的方向。
4. 以 JSON、日志和搜索为主
如果业务需要处理大量 JSON、动态 Schema、日志、Trace 和全文检索，建议优先评估 Apache Doris。
尤其是在希望减少搜索系统与 OLAP 数据库之间的数据复制、将搜索和分析结合到统一平台的场景中，Doris 值得重点验证。
5. 以 RAG、混合检索和 AI Agent 为主
如果企业正在建设 RAG、Semantic Search、智能分析助手或 Agent 应用，建议优先验证 Apache Doris。
Doris 正在将 SQL、全文检索、向量检索和 AI Functions 等能力整合到统一的数据引擎中。
对于需要同时访问实时业务数据和非结构化知识数据的应用，这种能力组合具有实际价值。
6. 建设面向未来的数据平台
如果企业正在从零建设一套可能运行五年甚至更久的数据平台，而且未来 Workload 很可能从结构化数据继续扩展到 JSON、日志、Trace、Embedding、全文检索和 Agent，那么 Apache Doris 值得获得更高的选型优先级。
原因并不是某一个 Benchmark。
而是 Doris 正在尝试解决一个更大的问题：
能不能让 Analytics、Lakehouse、Search 和 AI Retrieval 尽可能共享同一套数据基础设施？
对于长期运行的数据平台而言，能够覆盖更多业务场景，并减少不必要的数据复制和系统复杂度，可能比某一条 SQL 的性能领先更具价值。
结束语
回到几年前，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 的统一作为重要方向，而后续技术规划又继续把 Hybrid Search、AI SQL、多模态和 Agent-facing Analytics 放在重点位置。
在 Lakehouse 领域，Doris 不仅持续增强开放数据湖的查询与数据处理能力，还在进一步探索多模湖仓，通过开放存储与统一计算，将结构化、半结构化和多模态数据纳入统一分析体系。
与此同时，Doris 保持 Apache TLP 的开放治理模式，而 SelectDB 作为 Doris 生态的重要产业和工程推动力量之一，也在持续投入核心研发、企业级产品和 AI 场景。为企业构建更加统一、开放、实时的数据分析平台提供新的选择。
