GreptimeDB v1.1.0 已于 2026 年 6 月 14 日正式发布。

这是 v1.0 GA 之后又一次面向生产使用体验的演进版本。相比 v1.0，v1.1 版本围绕几条清晰的主线推进：

• 已有表的数据分布调整能力
• Flow 在增量场景下的执行效率
• 面向 LLM 与 AI Agent 的数据语义层
• Dashboard 对 trace 数据的可观测能力
• 查询、存储、WAL、元数据与协议兼容性等方面的稳定性修复

开发数据概览

本次 v1.1.0 的开发统计如下：

• 215 项变更收录在本次 release note 中
• 21 位贡献者参与了本次发布
• 其中 5 位是第一次为 GreptimeDB 提交代码

主要改进分布：

• 94 项功能增强：已有表在线分区、Flow 增量读取、CSV 导入选项、JSON2、Import/Export v2、Table Semantic Layer、Remote Dynamic Filter、Dashboard trace 可视化等
• 43 项错误修复：Region edit、Flow 增量读取、WAL replay、元数据缓存、MySQL prepare、OTLP JSONB logs 等稳定性问题
• 25 项代码重构：Mito/Mito2、Region edit、compaction、export-v2、pipeline ingestion 等内部路径整理
• 7 项性能优化：PromQL rate、metrics table join、SparseValues decode、WAL entry encoding 等
• 10 项测试增强：Repartition chaos、CSV skip bad records、JSON benchmark、rebuild index 等覆盖补充
• 29 项工程与依赖改进
• 4 项 breaking changes
• 1 项 RFC：Table Semantic Layer

感谢所有参与本次发布的贡献者，也欢迎更多开发者和用户加入 GreptimeDB 社区。

这次发布最值得关注的变化

已有表支持在线分区

v1.1.0 一个重要变化，是支持对原本没有分区规则的表进行分区。

在之前的版本中，只有建表时已经使用 PARTITION ON COLUMNS 的表，才能继续通过 SPLIT PARTITION 和 MERGE PARTITION 调整分区布局。从 v1.1.0 开始，没有分区规则的已有表也可以通过 ALTER TABLE ... PARTITION ON COLUMNS，将原本的单个 region 拆分成多个分区。

例如：

ALTER TABLE sensor_readings PARTITION ON COLUMNS (device_id, area) (
  device_id < 100 AND area < 'South',
  device_id < 100 AND area >= 'South',
  device_id >= 100 AND area <= 'East',
  device_id >= 100 AND area > 'East'
);

这样一来，用户不必在建表阶段就一次性定好未来的数据分布。随着数据量增长、访问模式变化，已有表也可以逐步调整分区布局。

需要注意的是，这项能力要求运行在分布式集群中，并启用共享对象存储和 GC。完成初次分区后，仍然可以继续使用 SPLIT PARTITION 和 MERGE PARTITION 进一步调整布局。

此外，以往重分区只能在原有分区列上调整边界。本次 SPLIT PARTITION 和 REPARTITION 新增了可选的 ON COLUMNS，可以为已有表增加分区列，例如从按 device_id 分区扩展到按 device_id、area 分区；不带 ON COLUMNS 时则沿用当前分区列。

Flow 支持实验性的增量读取

在 batching mode 下，Flow 过去每次执行都会完整重跑一遍对 source 表的查询。对于持续追加、数据量较大的 source 表，这会带来不必要的重复扫描开销。

v1.1.0 引入了实验性的增量读取功能。启用后，Flow 只读取上一次运行之后新追加的数据，从而降低 append-only 场景下的重复计算成本。

该能力默认关闭，可以在 flow node 配置中开启：

[flow.batching_mode]
experimental_enable_incremental_read = true

也可以在单个 Flow 上通过 WITH 选项开启：

WITH (experimental_enable_incremental_read = 'true')

需要注意：source 表必须是 append-only，即设置了 append_mode = 'true'。若不满足该条件，Flow 会回退到 full-snapshot query。

该能力目前仍为实验性功能，启用前建议先在测试环境验证。

语义层（Table Semantic Layer）开始落地

v1.1.0 开始分阶段落地 Table Semantic Layer（表的语义层）：在表数据之上叠加一层轻量的语义信息，让 LLM、agent 以及可视化、告警等工具更容易理解和使用这些数据。

它复用已有机制，不引入新协议，也不新增 DDL 关键字：表级语义放在 table_options 的 greptime.semantic.* 命名空间下，字段级信息通过标准 SQL 的列 COMMENT 补充，再由 information_schema 中的视图统一发现。在 Prometheus Remote Write 或者 OpenTelemetry 等协议写入时，也会自动标注这些元信息。

本次先落地了语义标识、自动标注、information_schema.table_semantics 视图三块。

CREATE TABLE my_metrics (
  ts TIMESTAMP TIME INDEX,
  val DOUBLE
) WITH (
  'greptime.semantic.signal_type' = 'metric',
  'greptime.semantic.source' = 'custom',
  'greptime.semantic.metric.type' = 'counter',
  'greptime.semantic.metric.unit' = 'By'
);

这些语义信息将通过 MCP Server 和 table_semantics 暴露给各类工具。

配套的 MCP server 升级到 0.5.0

GreptimeDB 配套的 MCP server（让 LLM/agent 通过 Model Context Protocol 访问数据）也在同期发布了 0.5.0。这一版主要带来三项改进：prompt 改用沙箱化的 Jinja 渲染、更完善的 describe table 功能（包括返回样本数据和语义元信息等），以及面向开发测试环境的 allow-write 模式。

内置 Dashboard 的 trace 可视化

内置 Dashboard 支持 trace 的列表视图，以及单条 trace 详情的 Gantt 视图。无需额外配置，一条 SQL 就能完成 trace 下钻。

在 metrics、logs、traces 都接入之后，trace 数据可以直接在这里浏览和定位，不必一开始就额外搭建一套外部可视化链路。这也延续了 GreptimeDB 一直在推进的方向：统一处理 metrics、logs 和 traces，同时尽量接入已有生态。

性能优化

v1.1.0 带来了一系列性能改进：

• PromQL 执行。 rate、increase 等范围函数运行更快，基准测试显示执行时间最高降低 97%；借助基于 TSID 的 join，指标的 join 性能也得到优化。在 PromQL 查询的端到端平均延迟上，v1.1 相比 v1.0 普遍降低 20%~40%。
• 扫描裁剪。 Parquet 预过滤、预过滤结果缓存，以及 datanode 扫描中的远程动态过滤，共同减少了不必要的行读取。启用预过滤后，TSBS cpu-max-all-8 查询速度提升了 4.5 倍。
• 读取效率。 页索引读取和范围缓存复用减少了扫描密集型查询的存储读取开销。在某一工作负载中，页索引读取使获取的 SST 字节数减少了 93.2%。

其他值得关注的改进

除上述几项主要变化外，v1.1.0 还包含一批面向查询、存储、导入导出和语义层的增强。

• 新增 JSON2 类型：支持 insert、flush、query concretization、planner、compaction，以及 field access pushdown to parquet 等能力，请注意，该功能还未就绪
• Import/Export v2 持续完善：包括 import-v2 pipeline、retry、resume、progress mode、progress UI，以及 export-v2 snapshot listing、verification、delete 等能力
• CSV 导入：COPY FROM 新增 SKIP_BAD_RECORDS（跳过解析或类型转换失败的坏行）和 HEADERS = 'false'（导入无 header 的文件，按位置映射列）
• Remote Dynamic Filter 持续推进：包括基础能力、frontend 注册、fan out 更新和 datanode scan 应用
• 查询侧持续优化：包括 PromQL binary op join simplifier、range cache、prefilter cache、nested projection、parquet nested leaf projection 等
• 协议与接口持续补齐：包括 gRPC-Web、pgwire 0.40、prepared statement execution timeout、PostgreSQL parameter parsing range check 等
• 执行与运行时隔离：datanode 拆分查询与写入运行时，避免大查询与写入相互拖累，并支持 remote WAL 逻辑裁剪
• 运维与安全能力增强：包括 password verifier formats、password hash generation command、information_schema statistics table、SST primary key range inspection 等

这些改动单独来看不一定都是大功能，但合在一起，覆盖了查询、写入、导入导出、协议兼容和可观测等多个方向。

重要修复

v1.1.0 也修复了一批稳定性问题，主要集中在以下几个方向。

Region、WAL 与元数据稳定性

本次发布集中修复了分布式长期运行中的几条关键路径：

• Region 变更与 compaction：Region edit 期间对新写入排队，并允许编辑期间 compaction 正常发布，避免状态冲突
• Follower region 关闭：关闭 follower region 时跳过不必要的 flush
• Region 统计：region stats 只统计自身拥有的 SST，数值更准确
• WAL 与元数据：补齐 WAL prune 重试的错误分类、完善 remote WAL replay checkpoint 处理，并在元数据缓存失效后避免读到旧值
• Leader 切换：metasrv leader 退位时及时关闭 heartbeat stream

这些修复主要影响分布式场景下的长期运行稳定性，尤其是 region 变更、元数据刷新、WAL 回放和 leader 切换相关的路径。

Flow 正确性与兼容性

Flow 增量读取在 v1.1.0 里既有新增，也有修复。release note 中包含 incremental read correctness hardening、复杂 SQL full-query Flow 支持、无 time window 的 eval-interval Flow 运行修复等内容。

对于正在评估 Flow 的用户，这些修复与新增能力同样重要。

协议、查询与数据格式修复

v1.1.0 修复了 MySQL prepare 中 LIMIT placeholder 推断、未知 placeholder 保留、nested projection roots、inverted index pruning、OTLP JSONB logs 兼容已有 schema、gRPC max connection age panic 等问题。

这些修复覆盖的是客户端兼容、查询规划、数据格式和运行时稳定性，属于日常使用中更容易遇到的边界问题。

兼容性说明

v1.1.0 包含 4 项 breaking changes，升级前建议重点检查。

1. gRPC CLI option 名称与配置命名对齐

如果脚本、自动化任务或运维文档中直接使用了旧的 gRPC CLI option 名称，升级前需要对照新版本的命名进行检查。

2. information_schema index metadata 输出被修正

本次修正了 information_schema 中 index metadata 的相关问题。依赖旧输出格式或旧字段含义的下游查询、监控或集成逻辑，需要在升级前验证。

3. scoped flow repair snapshot 行为调整

v1.1.0 对 scoped flow repair snapshot 做了 fence，避免跨 scope 误用状态。依赖 Flow repair/recovery 相关路径的场景，需要关注升级后的行为变化。

4. Mito2 移除 PartitionTreeMemtable

这是 Mito2 内部结构相关的重构。普通 SQL 使用通常无需直接感知，但如果有内部扩展、测试或调试逻辑依赖该结构，则需要同步调整。

v1.1.0 适合谁

对已经使用 GreptimeDB 的用户来说，最值得优先评估的场景包括：

• 需要对已有大表重新规划分区
• 任何已经在使用 v1.0 的环境，碰到性能问题或者 Bug 等
• Flow 的 source table 为 append-only，且全量重复扫描成本较高
• 正在用 LLM、agent 访问 GreptimeDB，希望数据更容易被理解和调用
• 希望直接在内置 Dashboard 中查看 trace
• 正在使用分布式集群、WAL、Flow、MySQL/PostgreSQL 协议或 OTLP 写入

如果你的使用场景覆盖以上方向，建议尽快测试和评估 v1.1.0。

结语

完整发行日志请查看 GitHub Release。

感谢每一位提过 issue、提交过 PR、参与讨论，以及在真实环境里跑过 GreptimeDB 的人。尤其要点名本次 5 位第一次为 GreptimeDB 提交代码的新贡献者：

• @QuakeWang（#8233）
• @rogierlommers（#8168）
• @kimjune01（#8092）
• @Detachm（#8067）
• @onepizzateam（#8027）

v1.1.0 延续了 v1.0 GA 之后的方向，继续把生产环境中的可用性和稳定性做扎实。