更多生产环境的部署正在重塑 GreptimeDB 的发展路线图。我们正投入更多精力来提升稳定性、性能和安全性。

在经历了三次正式版发布后： • v1.0 (四月)：结束了 Beta1 → Beta2 → RC1 → RC2 的迭代。这标志着路线图发生了转向。 • v1.1 (六月)：实现在线重分区 —— 可在表已提供服务的情况下更改其数据分布。 • v1.2 (九月)：JSON2，一种专为日志和事件流代理产生的大量数据而设计的 JSON 类型，支持通过 SQL 路径访问嵌套字段。

Vector Index、AI Functions 和 Pandas DataFrame SQL 已被移除。发布节奏从每月一版改为每个正式版前发布两个 Beta 版。

本文将回顾已发布的内容、优先级调整的原因，以及 2026 年剩余时间的修订计划：

GreptimeDB 2026 路线图年中回顾：已发布内容与变更

来源：https://greptime.com/blogs/2026-09-18-greptimedb-roadmap-2026-midyear-review

概览 (https://greptime.com/blogs/2026-09-18-greptimedb-roadmap-2026-midyear-review#overview)

我们于今年二月发布了 GreptimeDB 路线图 2026。七个月过去了，截至九月中旬，现状如下：

我们已发布 v1.0 GA、v1.1 和 v1.2，新增了在线重分区、JSON2 类型、Import/Export v2、表的实验性语义层，以及多项查询和写入优化。原计划中的两项内容——自适应资源管理，以及将远程压缩/索引从原型推进至生产——已推迟到 v1.4 和 v1.5。

里程碑 (https://greptime.com/blogs/2026-09-18-greptimedb-roadmap-2026-midyear-review#milestones)

计划变更原因 (https://greptime.com/blogs/2026-09-18-greptimedb-roadmap-2026-midyear-review#why-the-plan-changed)

制定路线图时，计划是每月或每两个月发布一次，我们在上半年一直遵循此节奏。但每次发布后都伴随着一到两次修复发布。月度发布，再加上诸如平面格式、JSON2 类型、原生直方图等重大变更，意味着一些兼容性问题直到用户遇到时才暴露出来。从 v1.2 开始，我们先发布两个 Beta 版，待两者均未出现严重问题后再发布 GA。

与用户和社区的交流，以及概念验证中提出的需求，促使我们重新排列了优先级。查询和写入优化、安全加固、语义层被提上日程。Vector Index、AI Functions 和 Pandas DataFrame SQL 被移除，为遥测数据的查询和存储释放了资源。

主要计划外交付 (https://greptime.com/blogs/2026-09-18-greptimedb-roadmap-2026-midyear-review#major-unplanned-deliveries)

这七个月来耗费最多精力的工作并不在二月的路线图中。

• 语义层 (进行中，实验性)：在数据旁保留来自 OTLP 的语义信息，如类型、单位和时间性。在 v1.1 中引入；v1.3 新增了来自 Prometheus Remote Write v2 的指标类型和单位。在此基础上，v1.3 将提供一个实验性的实体关系图，该图直接从遥测数据中推导服务间的调用关系、调用量、错误率和延迟，而无需维护单独的服务目录（#8609）。MCP Server 已使用这些信息为 AI 助手提供上下文。
• 查询性能：在 v1.1 基准测试中，平均 PromQL 查询延迟降低了 20% 至 40%，TSBS cpu-max-all-8 查询运行速度快了 4.5 倍。此轮优化包括对 rate 和 increase 等范围函数的改进，以及通过页面索引减少 SST 读取。后续版本继续进行了过滤条件下推（v1.1.3）和序列键的字典编码（v1.2）。这些是基准测试结果；实际收益取决于数据和工作负载。
• 写入性能：v1.0 增加了 Prometheus Remote Write 的批处理。v1.2 为每个 Region 赋予独立的写入缓冲区限制，使得一个 Region 的写入压力不再影响其他 Region。正在为 v1.3 开发的跨协议批量写入，将把这种批处理扩展到 HTTP 写入端点。
• 查询引擎：DataFusion 从 v1.0 的 52 版本升级至 v1.3 的 55 版本，带来了上游的规划与执行改进。
• 存储格式：平面 SST 成为默认格式（v1.0，可回退）；稀疏主键编码成为默认选项（v1.2）。
• 控制台：v1.1 中的 Perses 面板展示了追踪列表和单个追踪的甘特图视图；v1.2 新增了查询快照、命令面板和全屏结果视图。
• 生态与协议：Splunk HEC 数据摄入、gRPC-Web、MySQL 作为对象存储后端，以及 COPY FROM 对跳过错误行和无头 CSV 的支持。

各领域进展 (https://greptime.com/blogs/2026-09-18-greptimedb-roadmap-2026-midyear-review#progress-by-area)

本节遵循二月路线图的分类。

高可用与可靠性 (https://greptime.com/blogs/2026-09-18-greptimedb-roadmap-2026-midyear-review#high-availability-and-reliability)

• 远程压缩/索引投入生产：推迟至 v1.5。
• 热配置重载：尚未开始。
• 计划外：对象存储 WAL（进行中，实验性）。WAL 直接写入对象存储，消除了集群对 Kafka 的依赖。尚未在正式版本中发布。

数据库可操作性 (https://greptime.com/blogs/2026-09-18-greptimedb-roadmap-2026-midyear-review#database-operability)

• Import/Export 工具 v2 (文档)：已交付。始于 v1.0；v1.2 新增了并行分块和可续传传输。
• Major Compaction：推迟至 v1.4。
• 还实现了多项计划外运维能力。在线重分区在 v1.1 中完成，现在可以直接对未分区的表进行拆分。v1.2 添加了 ADMIN discard_unflushed (文档)：当错误数据阻塞刷盘时，可以仅丢弃内存中的数据，保留已落盘的数据。事件记录和 SHOW FLOW STATUS (文档) 使得 DDL、集群和 Flow 问题更易排查。流式 EXPLAIN ANALYZE 在 v1.3 中从实验性功能转为常规功能。
• 安全：哈希密码存储（v1.1）；SQL 本地文件访问沙箱 (文档)、表级权限、Postgres SCRAM 认证 (文档) 和独立的 API 端口（v1.2）；HTTP Bearer Token 认证（v1.3）。本地文件访问沙箱是一个破坏性变更；来自旧版本的本地导入/导出路径需要根据发布说明进行调整。

自适应资源管理 (https://greptime.com/blogs/2026-09-18-greptimedb-roadmap-2026-midyear-review#adaptive-resource-management)

两个交付阶段从 v1.2/v1.3 推迟到 v1.4/v1.5，因为优先级发生了变化：查询和写入优化、安全性和语义层被优先处理。当前工作负载下，现有的针对写入、查询和压缩的分组件限制已经足够，因此统一的自适应管理并非最紧迫的需求。内存限制和调度已完成部分工作但尚未统一，且部分组件仍是默认关闭的实验性功能。

• 细粒度内存跟踪与控制：进行中。写入、查询和压缩各有自己的内存限制，每个 Region 也有自己的写入缓冲区限制。统一内存管理尚未完成（#7094）。
• 基于成本的自适应调度：进行中。扫描已按输出字节数计量。查询和写入间的加权调度仍是一个默认关闭的实验性功能，且压缩和刷盘尚未连接（#8736）。
• 零调优自适应溢出：进行中。目前有一个实验性的溢出配置，用于设置临时文件路径、空间限制和压缩方式，并且可以禁用（#8884）。
• 负载感知压缩调度：进行中。任务拾取线程数和阻塞线程池大小现已受限，任务拾取策略也根据 #8575 进行了调整。
• 自适应缓存管理、资源配额与准入控制：尚未开始。

Metric Engine 优化 (https://greptime.com/blogs/2026-09-18-greptimedb-roadmap-2026-midyear-review#metric-engine-optimization)

• 写入优化：用于 OSS 的批量摄入：已交付（v1.0）。
• 压缩优化：部分完成；剩余部分纳入 v1.3。
• Prometheus Remote Write 2.0 (文档)：v1.2 支持新协议，以及原生直方图的摄入、验证和存储（摄入功能默认关闭）。v1.3 alpha 新增查询支持：数据可通过 Prometheus 查询 API 进行聚合和读取，并可在同一查询内分别为经典和原生直方图计算分位数，例如 95% 的请求完成所需时间（P95）。它还接受 OpenTelemetry 的累积分布统计（累积指数直方图）。
• 元数据管理优化（高基数场景）和自动多值优化：尚未开始。
• 计划外：序列索引（进行中）。查询首先通过标签找到匹配的时间序列，然后使用 SST 上的范围索引来定位相应数据，减少对无关数据的扫描。两阶段序列扫描还可将这些序列分布到多个输出分区中进行并行读取。

Flow Engine (https://greptime.com/blogs/2026-09-18-greptimedb-roadmap-2026-midyear-review#flow-engine)

• 扩展时间窗口和聚合函数：进行中。用于增量聚合的 Delta merge 已合并；其余部分计划在 v1.4 完成。
• 计划外：v1.1 添加了实验性的增量读取。此前每次计算都会重新扫描所有源数据；现在只读取自上次运行以来新增的数据。

日志与追踪 (https://greptime.com/blogs/2026-09-18-greptimedb-roadmap-2026-midyear-review#logs-and-traces)

• JSON2 (文档)：v1.2 交付了新的 JSON 类型，GA 版本中启用了新的存储布局。它会在配置的限制内展开 JSON 路径；超过限制的部分仍会保留，并且可以在查询时重建完整 JSON。字段级索引尚未开始。使用旧 JSON 类型的表在升级到 v1.2 时存在已知兼容性问题；请参阅发布说明了解迁移路径。v1.2.1 还修复了压缩期间的 JSON2 数据丢失问题，因此我们建议直接升级到 v1.2.1。
• 日志上下文搜索：推迟至 v1.5。
• 计划外：在追踪方面，v1.1 支持追踪表的自定义分区规则和追踪类型允许列表。v1.3 正在开发追踪 v2 摄入，属性将以 JSON2 形式存储。

新特性 (https://greptime.com/blogs/2026-09-18-greptimedb-roadmap-2026-midyear-review#new-features)

• Vector Index 和 AI Functions：已移除。v1.4 计划移除现有的 Vector Index 实现。
• Auto Rollup：推迟至 v1.4。
• Pandas DataFrame SQL：已移除。将代之以基于成本的优化器（CBO）等查询优化工作。
• 开放表格式兼容性（Iceberg/DeltaLake）：Iceberg 已在企业版中实现；DeltaLake 的实现被推迟。

下一步 (https://greptime.com/blogs/2026-09-18-greptimedb-roadmap-2026-midyear-review#what-s-next)

v1.2 发布后，重点转向 v1.3：更多的 PromQL 和压缩优化。自适应资源管理持续推进，将分布在 v1.4 和 v1.5 中。

• v1.4 和 v1.5 均计划在 Q4；实际上，部分功能可能会在同一个版本中发布。
• 发布日期是预估的，将根据实际进展进行调整。
• 请参阅路线图 issue #7685 进行讨论。

参与其中 (https://greptime.com/blogs/2026-09-18-greptimedb-roadmap-2026-midyear-review#get-involved)

带有跟踪 issue 的项目可以直接在该 issue 中讨论。其他任何事项，请在路线图 issue 上评论，发起 GitHub Discussion，或加入 GreptimeDB Slack。