More production deployments are reshaping GreptimeDB’s roadmap. We’re putting more work into stability, performance, and security.

Three GA releases in: • v1.0 (April): closing out Beta1 → Beta2 → RC1 → RC2. That’s the line where the roadmap changed shape. • v1.1 (June): online repartitioning — change the data distribution of a table that’s already serving traffic. • v1.2 (September): JSON2, a JSON type built for logs and the event volume agents produce, with SQL path access into nested fields.

Vector Index, AI Functions and Pandas DataFrame SQL got dropped along the way. Release cadence went from monthly to two betas before each GA.

Our review covers what shipped, why priorities changed, and the revised plan for the rest of 2026:

GreptimeDB Roadmap 2026 Mid-year Review: What Shipped and What Changed

Source: https://greptime.com/blogs/2026-09-18-greptimedb-roadmap-2026-midyear-review

Overview​

We published theGreptimeDB Roadmap 2026in February. Seven months in, this is where things stand as of mid-September.

We releasedv1.0 GA,v1.1, andv1.2, adding online repartitioning, the JSON2 type, Import/Export v2, an experimental semantic layer for tables, and a number of query and write optimizations. Two items from the original plan, adaptive resource management and moving Remote Compaction/Indexing from prototype to production, have moved to v1.4 and v1.5.

Milestones​

VersionFebruary planCurrent status and revised planv1.0 GAEnd of MarchReleased April 8v1.1Q2: Remote Compaction/Indexing to production, Metric Engine optimization, Vector Index and AI Functions, Import/Export v2, JSON2 typeReleased June 14, v1.1.1 on June 18. Actual contents: online repartitioning, table semantic layer, query performance improvementsv1.2Q3: adaptive resource management phase 1, Auto Rollup, Flow Engine enhancements, Major Compactionbeta.1 on August 1, beta.2 on August 21, GA on September 8,v1.2.1on September 16. Focus shifted to the JSON2 type and Import/Export v2v1.3Q4: adaptive resource management phase 2, Pandas DataFrame SQL, Log Context Search, open table format compatibilityalpha.1on September 3, GA targeted for September. Focus shifted to Metric Engine and compaction optimizationv1.4—Planned for Q4: adaptive resource management phase 1, Auto Rollup, Flow Engine enhancements, Major Compactionv1.5—Planned for late Q4: adaptive resource management phase 2, Remote Compaction/Indexing to production, Log Context Search, open table format compatibility## Why the plan changed​

When we wrote the roadmap, the plan was a release every month or two, and we kept to that through the first half of the year. But every release was followed by one or two fix releases. Monthly releases plus large changes like the flat format, the JSON2 type, and native histograms meant some compatibility issues did not surface until users hit them. Starting with v1.2, we ship two betas first and release the GA once neither shows serious problems.

Conversations with users and the community, plus requirements raised in PoCs, led us to reorder priorities. Query and write optimization, security hardening, and the semantic layer moved in. Vector Index, AI Functions, and Pandas DataFrame SQL were dropped, freeing up effort for querying and storing telemetry data.

Major unplanned deliveries​

The work that took the most effort over these seven months was not on the February roadmap.

• Semantic layer(in progress, experimental): keeps semantic information from OTLP, such as type, unit, and temporality, alongside the data. Introduced in v1.1; v1.3 adds metric type and unit from Prometheus Remote Write v2. On top of this, v1.3 will ship an experimental entity relationship graph that derives service-to-service call relationships, along with call volume, errors, and latency, directly from telemetry data, without maintaining a separate service catalog (#8609). The MCP Server already uses this information to give AI assistants context.
• Query performance: in v1.1 benchmarks, average PromQL query latency dropped 20% to 40%, and the TSBScpu\-max\-all\-8query ran 4.5x faster. This round included optimizations to range functions such asrateandincrease, and fewer SST reads through the page index. Later versions continued with filter pushdown (v1.1.3) and dictionary encoding of series keys (v1.2). These are benchmark results; actual gains depend on data and workload.
• Write performance: v1.0 added batching for Prometheus Remote Write. v1.2 gave each region its own write buffer limit, so write pressure on one region no longer affects the others. Cross-protocol batch writes, in progress for v1.3, will extend this batching to the HTTP write endpoints.
• Query engine: DataFusion was upgraded from 52 in v1.0 to 55 in v1.3, bringing in upstream planning and execution improvements.
• Storage format: flat SST became the default format (v1.0, can be reverted); sparse primary key encoding became the default (v1.2).
• Dashboard: the Perses panels in v1.1 show trace lists and a Gantt view of a single trace; v1.2 added query snapshots, a command palette, and full-screen results.
• Ecosystem and protocols: Splunk HEC ingestion, gRPC-Web, MySQL as an object store backend, andCOPY FROMsupport for skipping bad rows and headerless CSV.

Progress by area​

This section follows the categories of the February roadmap.

High availability and reliability​

• Remote Compaction/Indexing to production: moved to v1.5.
• Hot configuration reload: not started.
• Unplanned: object storage WAL (in progress, experimental). The WAL writes directly to object storage, removing the cluster’s dependency on Kafka. Not yet in a released version.

Database operability​

• Import/Export Tool v2: delivered. Started in v1.0; v1.2 added parallel chunking and resumable transfers.
• Major Compaction: moved to v1.4.
• Several unplanned operational capabilities also landed.Online repartitioningwas completed in v1.1, and unpartitioned tables can now be split directly. v1.2 addedADMIN discard\_unflushed: when bad data blocks a flush, you can discard only the in-memory data and keep what is already on disk.Event recordsandSHOW FLOW STATUSmake DDL, cluster, and Flow issues easier to troubleshoot. StreamingEXPLAIN ANALYZEchanges from experimental to a regular feature in v1.3.
• Security: hashed password storage (v1.1);SQL local file access sandbox,table-level permissions, Postgres SCRAM authentication, and a separate API port (v1.2); HTTP Bearer Token authentication (v1.3). The local file access sandbox is a breaking change; local import/export paths from older versions need to be adjusted as described in the release notes.

Adaptive resource management​

The two delivery phases moved from v1.2 / v1.3 to v1.4 / v1.5 because priorities changed: query and write optimization, security, and the semantic layer came first. The existing per-component limits for writes, queries, and compaction are sufficient under current workloads, so unified adaptive management is not the most urgent need. Memory limits and scheduling are partially done but not yet unified, and some pieces are still experimental features that are off by default.

• Fine-grained memory tracking and control: in progress. Writes, queries, and compaction each have their own memory limits, and each region has its own write buffer limit. Unified memory management is not finished (#7094).
• Cost-based adaptive scheduling: in progress. Scans are already metered by output bytes. Weighted scheduling between queries and writes is still an experimental feature, off by default, and compaction and flush are not yet connected (#8736).
• Zero-tuning adaptive spill: in progress. For now there is an experimental spill configuration for the temp file path, space limit, and compression, and it can be disabled (#8884).
• Load-aware compaction scheduling: in progress. The number of task-picking threads and the size of the blocking thread pool are now limited, and the task-picking strategy was adjusted per#8575.
• Adaptive cache management, resource quotas, and admission control: not started.

Metric Engine optimization​

• Write optimization: bulk ingestion for OSS: delivered (v1.0).
• Compaction optimization: partially done; the rest goes into v1.3.
• Prometheus Remote Write 2.0: v1.2 supports the new protocol, plus ingestion, validation, and storage of native histograms, with ingestion off by default. v1.3 alpha adds querying: the data can be aggregated and read through the Prometheus query API, and quantiles can be computed for classic and native histograms separately within the same query, for example how long 95% of requests take to complete (P95). It also accepts OpenTelemetry’s cumulative distribution statistics (cumulative exponential histograms).
• Metadata management optimization (high-cardinality scenarios) and automatic multi-value optimization: not started.
• Unplanned: series index (in progress). A query first finds the matching time series by tag, then uses the range index on SSTs to locate the corresponding data, reducing scans of irrelevant data. The two-phase series scan can also distribute these series across multiple output partitions for parallel reads.

Flow Engine​

• Extended time windows and aggregate functions: in progress. Delta merge for incremental aggregation has been merged; the rest is scheduled for v1.4.
• Unplanned: v1.1 added experimental incremental reads. Previously every computation rescanned all source data; now it reads only what was added since the last run.

Logs and traces​

• JSON2: v1.2 delivers the new JSON type, with the new storage layout enabled in the GA release. It expands JSON paths up to a configured limit; anything beyond the limit is still kept, and the full JSON can be reconstructed at query time. Field-level indexing has not started. Tables using the old JSON type have known compatibility issues when upgrading to v1.2; see therelease notesfor the migration path.v1.2.1also fixed a JSON2 data loss issue during compaction, so we recommend going straight to v1.2.1.
• Log Context Search: moved to v1.5.
• Unplanned: on the trace side, v1.1 supportscustom partition rules for trace tablesand a trace type allowlist. v1.3 is working on trace v2 ingestion, with attributes stored as JSON2.

New features​

• Vector Index and AI Functions: dropped. v1.4 plans to remove the existing Vector Index implementation.
• Auto Rollup: moved to v1.4.
• Pandas DataFrame SQL: dropped. Query optimization work such as a cost-based optimizer (CBO) will follow instead.
• Open table format compatibility (Iceberg/DeltaLake):Iceberg is implemented in the Enterprise edition; the DeltaLake implementation is postponed.

What’s next​

With v1.2 out, the focus is v1.3: more PromQL and compaction optimizations. Adaptive resource management continues, split across v1.4 and v1.5.

• v1.4 and v1.5 are both scheduled for Q4; in practice some of their features may ship in a single release.
• Release dates are estimates and will be adjusted based on actual progress.
• See theroadmap issue #7685for discussion.

Get involved​

Items with a tracking issue can be discussed directly in that issue. For anything else, comment on the roadmap issue, start aGitHub Discussion, or join theGreptimeDB Slack.