Prometheus 扩展困难？
这是架构层面的问题。
Prometheus 负责抓取，Thanos 负责归档，Mimir 负责分发。你在用三套系统做一件事。 Prometheus 缺乏的多值模型、你一直想要的 SQL 关联能力、指标 + 日志的统一成本模型——这些不是附加功能，而是三支柱模型该结束的理由。
挑战者
拉取式采集 · 仅 PromQL · 扩展需要 5-8 个组件
GreptimeDB
指标 + 日志 + 链路 · SQL + PromQL · 原生对象存储
为什么扩展 Prometheus 往往意味着增加组件，而 GreptimeDB 不需要。
5-8 个组件
remote write
compact + index
query fan-out
long-term
1 DATABASE
存算分离
原生对象存储
| 维度 | GreptimeDB | Prometheus | Thanos / Mimir |
|---|---|---|---|
| 查询语言 | SQL + PromQL（双语原生） | 仅 PromQL | 仅 PromQL |
| 数据模型 | 多值行（Wide Events） | 单值时序 | 单值时序 |
| 数据类型 | 指标 + 日志 + 链路 | 仅指标 | 仅指标 |
| 存储 | 原生对象存储（S3、OSS、GCS） | 本地磁盘 | 通过 Sidecar（Thanos）或原生（Mimir）接入对象存储 |
| 扩展模型 | 存算分离，无状态节点 | 仅联合 | 多组件架构（运维复杂） |
| OpenTelemetry | 原生 OTLP（全信号） | 仅指标（remote write） | 仅指标（Thanos）；支持 OTLP 指标摄入（Mimir） |
| 持续聚合 | 内置 SQL 聚合 + Flow 流计算引擎 | Recording Rules（有限） | Recording Rules（有限） |
| 高可用 | 原生集群与自动故障转移 | 需要手动联合设置 | 多组件 HA 配置 |
| 许可证 | Apache 2.0 | Apache 2.0 | Thanos: Apache 2.0; Mimir: AGPLv3 |
| 迁移成本 | PromQL 兼容，Remote Write 就绪 | — | 需要基础设施重新设计 |
Thanos 和 Mimir 架构不同，此列汇总的是共性模式。
PromQL 兼容、Remote Write 就绪，无需重写查询。
Stay in the loop
获取 Greptime 最新更新，并与其他用户讨论。
