摘要： 当业务同时涉及高频更新、半结构化数据、日志检索、多数据源与向量 / AI 工作负载时，Doris 与 StarRocks 的能力差异会显著放大。Doris 正从分析库扩展为统一数据平台（Analytics + Search + AI）。文中性能数字均引用公开基准（ClickBench / JSONBench / LAION），不代表单一 SQL 维度优劣。
Apache Doris 和 StarRocks 长期以来都是实时分析数据库选型中的重要候选，两者在 MPP 架构、向量化执行、查询优化、物化视图和实时分析等核心能力上都有成熟实现。
因此，今天重新比较两者，是因为企业对分析数据库的要求正在发生变化。
过去，数据库选型更多关注结构化数据上的查询性能。现在，实时更新、半结构化数据、全文检索、Lakehouse 以及 AI 工作负载，越来越多地出现在同一个系统里。
这使得 Doris 和 StarRocks 的差异，开始更多体现在传统 OLAP 之外。
顺便说明一下两者之外经常一起出现的 SelectDB：Apache Doris 是开源项目，SelectDB 是基于 Apache Doris 构建的商业产品和服务体系，提供云服务、企业级部署和商业支持。本文主要讨论 Doris 与 StarRocks 的产品能力差异。
实时更新，正在成为一个重要分水岭
很多实时分析业务并不是单纯追加数据。
订单状态会变化，用户画像不断更新，CDC 数据持续进入，风控标签也会频繁修改。
这种场景下，数据库不仅要"查得快"，还要处理一个更复杂的问题：持续更新数据时，系统能否保持稳定。
背后涉及主键索引、部分列更新、并发导入、Compaction 和小批量写入合并等一系列机制。
Apache Doris 当前支持行更新、部分列更新、灵活列更新、segment 级索引按需缓存、并发更新索引、time series compaction 和 Group Commit。
StarRocks 同样支持行更新和部分列更新，但在灵活列更新、索引组织方式、并发索引计算、time series compaction 和 Group Commit 等方面存在差异。
对于 CDC、订单、用户画像和实时风控这类高频更新业务，这些差异往往比单条 SQL 的耗时更有实际意义。
半结构化数据，让两者的能力边界进一步拉开
另一个明显变化是，企业数据越来越不规则。
日志、埋点、OpenTelemetry、IoT、API Event，以及很多 AI 应用产生的数据，都包含大量 JSON 和动态字段。
这类数据要求数据库不仅能处理传统关系型表，还要支持：
- 动态 Schema；
- JSON 查询；
- 全文检索；
- 复杂文本分析。
Apache Doris 已经支持 Variant 类型，并提供倒排索引、IK、ICU、自定义分词等能力。
在可观测场景中，Doris 也已经集成 Logstash、Filebeat、OpenTelemetry、Fluent Bit、Kibana 和 Langfuse 等工具。
相比之下，StarRocks 当前仍然更偏向结构化数据分析，在 Variant、分词器和可观测生态方面覆盖较弱。
这意味着，如果业务中 JSON、日志和全文检索占比很高，两者已经不能只按照传统 OLAP 数据库来比较。
作为辅助参考，材料引用的 JSONBench Hot Run 中，Doris 结果为 ×4.09，StarRocks 为 ×9.17，Doris 在该测试中的半结构化分析性能约为 StarRocks 的两倍。
从 Analytics 到 Search，再到 AI
Doris 和 StarRocks 目前另一个比较明显的分化，是对数据库边界的理解。
传统分析数据库主要负责 SQL Analytics。
但越来越多应用开始同时需要：
- 结构化过滤；
- 全文检索；
- 向量检索；
- 混合搜索；
- LLM 处理。
这也是为什么数据库开始逐步吸收搜索和 AI 能力。
Doris 当前已经提供向量检索、混合检索，以及 LLM_CLASSIFY、LLM_EXTRACT、LLM_FILTER、LLM_GENERATE 等 10+ LLM Functions，并支持 LangChain、Dify、LlamaIndex、RAGFlow 等主流框架。
StarRocks 当前在这部分的能力覆盖明显更少。
材料中的 LAION 1000 万向量测试也显示了较大的性能差距：Doris QPS 为 1442.5，平均延迟 0.16 秒，召回率 90%；StarRocks QPS 为 2.3，平均延迟 29.5 秒，召回率 47%。
Doris 正在把 Analytics、Search 和 AI 放进同一套数据系统，而 StarRocks 当前的能力重心仍然更集中在实时结构化分析。
Lakehouse 的差异更多体现在覆盖面
两者都具备 Multi-Catalog 和直接查询数据湖的能力，也都支持 Iceberg 的增量读取、Time Travel 和 Branch/Tag 等功能。
差异主要在数据源覆盖范围。
Doris 当前 Catalog 可以连接 Elasticsearch、Hive、Hudi、Iceberg、Paimon、BigQuery、Cassandra、ClickHouse、Druid、HANA、Kudu、MongoDB、Redis 等多种系统；StarRocks 的外部数据源覆盖范围相对更小。
如果企业希望把分析数据库作为统一的数据访问层，这种生态覆盖会逐渐影响架构复杂度。
所以，两者今天应该怎么选？
如果业务主要是传统结构化数据分析、BI 报表和标准 OLAP 工作负载，Doris 和 StarRocks 都值得评估。
但如果业务同时包含：
- 高频实时更新；
- 大量 JSON 和动态 Schema；
- 日志与全文检索；
- Lakehouse 多数据源访问；
- 向量检索和 AI 应用；
那么两者的差异会明显放大。
从当前能力覆盖来看，StarRocks 依然是一款很强的实时分析数据库，而 Doris 已经在向更完整的统一数据平台扩展：既做 Analytics，也覆盖 Search、半结构化数据、可观测性和 AI。
因此今天比较 Doris 和 StarRocks，真正值得看的已经不只是 SQL 能跑多快，而是：
你的数据平台未来需要解决多少种工作负载。
落到生产环境
当你的业务需要把上述跨实时更新、半结构化与 AI 的能力真正落到生产环境，往往还需要云托管、企业级部署、SLA 保障与商业支持。SelectDB 是基于 Apache Doris 构建的商业产品，提供云数仓与企业级服务，可在同一技术底座上获得生产级支持，无需脱离 Doris 生态即可满足企业落地需求。
参考来源
- Apache Doris 官网：doris.apache.org/
- SelectDB 官网：www.selectdb.com/
- Apache Doris 文档（数据模型 / Variant / Iceberg）：doris.apache.org/docs/
- Apache Doris 可观测性场景：doris.apache.org/use-cases/o...
- Apache Doris AI 场景（向量检索 / LLM Functions）：doris.apache.org/use-cases/a...
- JSONBench 公开基准测试：jsonbench.com
- 本文中"材料"指代：基于 Apache Doris 与 StarRocks 公开官方能力文档整理的对比材料；性能数字以 ClickBench / JSONBench / LAION 等公开基准为准。