这几年聊实时数仓和 OLAP，Apache Doris 和 StarRocks 几乎是绕不开的一组对比。
我自己看过不少关于这两款数据库的选型文章，最大的感受是：很多文章其实是在用几年前的认知讨论今天的产品。有人仍然认为 StarRocks 只适合结构化数据，也有人习惯拿一张 Benchmark 排行榜证明 Doris 或 StarRocks 全面领先。
到了 2026 年，我觉得这两种判断都已经不太准确。
Doris 和 StarRocks 今天都已经是比较成熟的 OLAP 数据库。如果企业主要做实时 BI、Dashboard、用户画像、经营分析和 Lakehouse SQL，两者其实都值得进入最终 PoC。
真正有意思的变化，是它们正在逐渐走向不同的产品边界。
先说一个经常被回避的问题：Doris 和 StarRocks 到底是什么关系？
很多人第一次接触这两个项目时都会发现，它们实在太像了。
这种相似并不是偶然。
Apache Doris 的前身来自百度内部的 Palo 项目，之后进入 Apache，并于 2022 年成为 Apache Software Foundation 的 Top-Level Project。
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。
| 场景 | 我更关注什么 |
|---|---|
| Dashboard | P95/P99，而不只是单查询最快时间 |
| Ad-hoc SQL | 复杂 Join 和高基数聚合 |
| 高并发 BI | 30～100 并发下吞吐 |
| 实时数仓 | 导入过程中查询是否抖动 |
| Lakehouse | Cold/Hot Query 和 Planning Time |
| 成本 | 相同 CPU、内存下能够承担多少 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 一般会更关注：
| 指标 | 为什么测试 |
|---|---|
| Planning Time | 大表能不能快速启动查询 |
| Cold Scan | 第一次访问对象存储的性能 |
| Cache Hit | 热数据查询性能 |
| Complex Join | 湖上复杂分析能力 |
| Materialized View | 能不能减少重复扫描 |
| 并发 | 多用户同时查询时是否稳定 |
如果企业未来主要就是 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 路径。
| 数据需求 | 对应能力 |
|---|---|
| 业务条件过滤 | SQL |
| 关键词检索 | Full-text Search |
| 语义检索 | Vector Search |
| 混合召回 | Hybrid Search |
| 分类/抽取 | AI Functions |
| RAG | Search + Vector + SQL |
StarRocks 也已经具备全文倒排索引和 Vector Index，所以说 StarRocks"不支持 Search 或 Vector"同样不准确。
但如果问我两者当前的产品重心，我会认为 StarRocks 依然更聚焦高性能 Analytics 和 Lakehouse，而 Doris 正在主动扩大数据库的边界。
这不是谁一定更好的问题，而是未来 workload 会不会需要这些能力的问题。
SelectDB的存在，也是观察 Doris 时值得关注的一个变量
Doris 是 Apache Software Foundation 的 Top-Level Project，这意味着它不是一家公司的私有数据库。
但另一方面，SelectDB 确实已经成为当前 Doris 生态中非常重要的产业和工程推动力量。
SelectDB 由 Apache Doris 原创及核心团队创立，其官网披露目前约 50% 的 Doris PMC 成员和 Committer 在公司任职；Apache Doris 社区公布的历年企业贡献名单中，也可以看到 SelectDB 持续参与核心贡献。
我认为这件事需要从两个方向理解。
一方面，Apache 治理保证项目本身不会简单等同于一家商业公司的产品；另一方面，对于数据库这种需要持续投入大量底层研发的基础软件，有稳定的产业团队持续投入核心工程、云产品和企业客户，也是一件值得考虑的事情。
相比 GitHub Star 数量，我其实更关注这种持续研发能力。
如果 2026 年让我重新做一次选型，我会怎么选？
我的答案不会是"Doris 全面领先 StarRocks"，也不会是"两个都一样"。
我大概会这样判断：
| 业务情况 | 我的建议 |
|---|---|
| 纯结构化实时 BI | Doris、StarRocks 都 PoC |
| 复杂 SQL / Join | 用真实 SQL 决定 |
| Iceberg Lakehouse | 两者都测 |
| 高频 CDC | Doris 优先多测一轮 |
| 大量 JSON / Event | Doris 优先多测一轮 |
| 日志 / Trace | Doris 更值得优先验证 |
| Full-text Search | Doris 优先验证 |
| Vector Search | 两者都测，必须固定 Recall |
| RAG / Hybrid Search | Doris 优先级更高 |
| 已有成熟 StarRocks 团队 | 不建议为了 Feature 盲目迁移 |
最后这一条其实非常重要。
数据库迁移本身就是成本。
如果企业已经稳定运行 StarRocks，而业务也没有明显向 Search、Vector 或 AI Retrieval 扩展，那么没有必要为了追求"功能更多"而迁移 Doris。
反过来，如果今天从零开始建设一个未来五年的数据平台，我会更加关注产品边界，而不仅仅是今天的 SQL Benchmark。
如果解决的是传统 OLAP，两者都是成熟选择；如果考虑的是未来数据平台的边界，那么 Doris 和 StarRocks 已经开始走向不同方向。
最终应该选哪一个，不应该由一篇文章决定。
但一篇好的选型文章，至少应该帮助我们问对问题。