@Greptime: GreptimeDB v1.2.0-beta.1 is out. 205 changes, 259 commits, 22 contributors. The headline items: JSON2 as a data type, P…

X AI KOLs Following Products

Summary

GreptimeDB v1.2.0-beta.1 is released with major features including JSON2 as a structured column type, Prometheus Remote Write v2 with native histograms, dictionary-encoded series keys for faster queries, and additional hardening/breaking changes.

GreptimeDB v1.2.0-beta.1 is out. 205 changes, 259 commits, 22 contributors. The headline items: JSON2 as a data type, Prometheus Remote Write v2 with native histograms, and Splunk HEC ingestion. Rest of the beta: dictionary-encoded series keys (~24% end-to-end across a 200+ query test set), and a parquet metadata cache that needed a 1 GB limit before and runs on 64 MB now. 4 breaking changes, so test environment first. https://greptime.com/blogs/2026-08-04-greptimedb-v1-2-0-beta-1-release…
Original Article
View Cached Full Text

Cached at: 08/04/26, 02:11 PM

GreptimeDB v1.2.0-beta.1 is out. 205 changes, 259 commits, 22 contributors.

The headline items: JSON2 as a data type, Prometheus Remote Write v2 with native histograms, and Splunk HEC ingestion.

Rest of the beta: dictionary-encoded series keys (~24% end-to-end across a 200+ query test set), and a parquet metadata cache that needed a 1 GB limit before and runs on 64 MB now.

4 breaking changes, so test environment first.

https://greptime.com/blogs/2026-08-04-greptimedb-v1-2-0-beta-1-release…


GreptimeDB v1.2.0-beta.1: JSON2 columns and Prometheus Remote Write v2

Source: https://greptime.com/blogs/2026-08-04-greptimedb-v1-2-0-beta-1-release We released GreptimeDB v1.2.0-beta.1 on July 31, 2026. This is the first beta of v1.2.0 and it carries 4 breaking changes, so evaluate it in a test environment first. The main changes in this release:

  • Support for the Prometheus Remote Write v2 protocol and native histograms
  • JSON2 debuts as a data type; GA will come with the v1.2.0 stable release
  • Query performance: dictionary-encoded series keys give roughly a 24% end-to-end improvement, and RangeSelect projection pruning cuts the columns scanned
  • A round of permission and file-access hardening, including SQL local file sandboxing, which is a breaking change
  • New Splunk HEC ingestion; cluster DDL and operational events now land in a system table

Development stats

  • This release note covers 205 changes
  • From v1.1.0 to v1.2.0-beta.1, 22 contributors landed 259 commits
  • 6 of them contributed to GreptimeDB for the first time: @agrawalx, @raphaelroshan, @srivtx, @yimeng, @divyansh-1009, @RitwijParmar

GreptimeDB contributors from v1.1.0 to v1.2.0-beta.1

Main changes

Prometheus Remote Write v2 and native histograms

GreptimeDB now supports the Prometheus Remote Write v2 protocol. Native histograms can be persisted with write validation, and PromQL gained the corresponding native histogram functions.protobuf\_messageon the Prometheus side defaults to the v1prometheus\.WriteRequest, so pointing the URL at GreptimeDB alone still sends v1. Set the v2 message format explicitly:

yaml

remote_write:
  - url: http://greptimedb:4000/v1/prometheus/write
    protobuf_message: io.prometheus.write.v2.Request

With that in place, v2 sample ingestion works. Native histogram ingestion is still experimental on the GreptimeDB side and is off by default; enable it in the frontend configuration:

toml

[http]
experimental_enable_prometheus_native_histogram = true

JSON2 debuts

JSON2 is a new data type in this release. It stores JSON in a structured, column-oriented layout rather than serializing each document into a JSON string or a JSONB value. With this layout, querying nested JSON is as fast as querying a regular column, and the syntax is simpler: instead of UDFs likejson\_get\_int, you reach a field with\..

sql

CREATE TABLE json2_table (
    ts TIMESTAMP TIME INDEX,
    my_json JSON2
) WITH ('append_mode' = 'true');

SELECT my_json.field_a.field_b::INT64 FROM json2_table;

This release also settles JSON2’s read behavior on nested paths: a field still resolves when it is a scalar in one row and an object in another.

Two constraints apply on the write path. A JSON2 column requiresappend\_mode='true'at table creation, and bothCREATE TABLEandALTER TABLEvalidate it. JSON values whose top level is not an object (arrays, strings, numbers, booleans, null) are rejected.

v1.2.0-beta.1 is a beta, and JSON2 goes GA in the v1.2.0 stable release. For now it is a good fit for testing environments, and we welcome your feedback. We will publish a separate post covering JSON2 in detail.

Performance

In-memory primary key columns now use a dictionary array, which reduces the cost of expanding series keys. On a test set of 200+ queries this gives roughly a 24% end-to-end improvement. Regex filtering on dictionary-encoded columns had its semantics corrected and its fast path restored at the same time.

sql

SELECT * FROM metrics WHERE job = 'node' AND path ~ '/api/.*';
-- Regex filtering on dictionary-encoded columns is now correct and takes the fast path

Range queries now prune unused input columns before the RangeSelect plan, cutting both scanned columns and I/O.

The parquet metadata cache got leaner too: it drops column metadata it never uses and adds a compression layer. Where the metadata cache previously needed a 1 GB limit, 64 MB is now enough, with no cache churn. These numbers come from the test scenarios in the corresponding PRs and do not represent every workload.

Three more optimizations ship without numbers attached: the OTLP trace ingest hot path was optimized and the defaultotlp\.trace\_ingest\_chunk\_sizeraised from 128 to 512; Prometheus remote read result conversion borrows dictionary-encoded label strings instead of copying them per row; and the compaction picker runs asynchronously rather than blocking the region worker loop.

Splunk HEC ingestion

GreptimeDB now exposes endpoints compatible with the Splunk HTTP Event Collector. An existing Splunk collection pipeline (Vector’ssplunk\_hecsink, the OTel Collector’ssplunk\_hecexporter, Fluent Bit) only needs a new URL and token to write logs into GreptimeDB:

text

POST /v1/splunk/services/collector/event   # JSON events
POST /v1/splunk/services/collector/raw     # Plain text, one event per line
GET  /v1/splunk/services/collector/health  # Health probe

Field mapping works like this:timemaps to the timestamp,host/source/sourcetypeand the keys underfieldsmap to tag columns,eventand the remaining keys become data, andindexdetermines the table name. Requests go through thegreptime\_identitypipeline by default, which flattens nestedeventobjects; override it with thepipeline\_namequery parameter or thex\-greptime\-pipeline\-nameheader. The raw endpoint stores each line verbatim in amessagecolumn and takes metadata from query parameters. Request bodies may be gzipped.

Cluster DDL and operational events in a system table

The event recorder records more this time around. Alongside the existing region migration events, DDL on databases, tables, flows and views, plus repartition, WAL prune and bulk GC, are written to a system table as events. Answering “when was this table created, altered or dropped” no longer means digging through logs. Both the scope and the retention period are configurable:

toml

[event_recorder]
ttl = "90d"                                   # TTL of the events table, 90 days by default
event_types = ["create_table", "drop_table"]  # Omit to record everything, [] to turn it off

Permission and file access hardening

This release tightens permissions and file access in several places, one of which is a breaking change:

  • SQL access to local files is sandboxed; see the compatibility notes at the end
  • Query and write protocols enforce table-level permissions across the board, gaps in database ACL checks are closed, and restricted HTTP endpoints are covered by permission checks
  • Invalid password assignments now fail closed instead of passing silently
  • PostgreSQL supports SCRAM-SHA-256 authentication, and the static user file accepts a newpg\_scram\_sha256password format
  • Whoever creates a database automatically gets access to it

There is a related deployment option. The main HTTP port (4000 by default) also serves operational endpoints such as/metrics,/statusand/debug/prof/\*, so you can now start a second port that allows only/v1and/dashboardand returns 404 for everything else:

toml

[http]
enable_api_server = true
api_server_addr = "127.0.0.1:4006"

That way 4006 faces outward and 4000 stays on the internal network. It is off by default, and both ports share the rest of the\[http\]configuration.

Export/Import V2: parallelism and resumption

Snapshot-based Export/Import V2 adds concurrent chunk export (\-\-chunk\-parallelism), parallel import tasks (\-\-task\-parallelism) and progress output (\-\-progress). It also resumes: rerunning the same command skips chunks and tasks that already finished, so you don’t start over.

bash

greptime cli data export-v2 create \
  --addr 127.0.0.1:4000 \
  --to file:///tmp/greptime-snapshots/demo \
  --chunk-parallelism 4
# Rerun the same command to continue from existing progress

For full usage, see theExport/Import V2 documentation.

Other improvements

  • Streaming EXPLAIN ANALYZE:POST /v1/sql/analyze/streamreports per-stage metrics as the query runs, so you don’t wait for the whole distributed query to finish.http\.experimental\_enable\_explain\_analyze\_streamis on by default
  • Manual compaction accepts a time range.start\_timeandend\_timemust appear together, the interval is half-open\[start\_time, end\_time\), and timestamps without a time zone are interpreted in the session time zone: sql ADMIN COMPACT_TABLE('t', 'regular', 'parallelism=2,start_time=2026-01-01T00:00:00Z,end_time=2026-02-01T00:00:00Z');
  • auto\_flush\_intervalis now a table-level option, set at creation or changed withALTER TABLE SET, instead of one global cadence for every region
  • A MySQL object store backend is new. It does not support repartition yet: OpenDAL’s MySQL service has no nativecopy, so the region file copy that repartition triggers returnsUnsupported
  • Dashboard updated to v0.13.10, most notably self-contained dashboard snapshots that open read-only without querying the live data source

Notable fixes

Three fixes worth checking against your own workload:

  • PromQL had three classes of bugs that produced wrong or missing results: plain NaN samples were dropped,ormatching mishandled missing labels and empty operands, and query-aligned range tails were truncated
  • The MySQL protocol returns an error for timestamps it cannot represent instead of returning wrong data
  • In the metric engine, logical projection indexes are validated, route pruning uses the physical partition type, and a missing route column no longer panics

Compatibility notes

SQL local file access is sandboxed (#8708)

WhenCOPY FROM/TO,COPY DATABASEand file engine external tables touch local files, paths are now confined to a sandbox directory,<storage\.data\_home\>/copyby default: relative paths resolve inside the sandbox, and absolute paths are accepted only if they fall inside it. The newstorage\.copy\_rootsetting points the sandbox at a dedicated local directory; values that would expose GreptimeDB’s internal data, WAL, manifest or configuration directories are rejected. In distributed deployments, SQL access to Datanode local files is disabled. Object storage paths (S3/OSS/GCS/AzBlob) are unaffected.

Before upgrading: reviewCOPYworkflows and external tables that reference local paths outside the sandbox, then move the files into the sandbox, setstorage\.copy\_root, or switch to object storage.

holt_winters removed, fill modifiers rejected (#8457)

promql-parser is upgraded to v0.10.0 and the deprecatedholt\_winterscompatibility shim is gone. Thefill,fill\_leftandfill\_rightmodifiers are rejected outright until the outer-join semantics they require are implemented, which avoids producing silently wrong query plans.

Before upgrading: check whether your PromQL queries and alerting rules still useholt\_wintersor these fill modifiers.

sparse_primary_key_encoding setting removed (#8470)

The metric engine always uses sparse encoding now, and thesparse\_primary\_key\_encodingsetting is retired. Leaving it in an existing configuration file does not raise an error, so you can clean it up whenever it is convenient.

Pipeline integer narrowing checks (#8589)

When a pipeline transform converts an integer to a narrower declared type, it now range-checks first. Out-of-range values no longer wrap silently (previously\-1touint8gave255and256toint8gave0); instead they follow the configuredon\_failurepolicy: ignore, default, or a hard error. Narrow numeric strings follow the same range rules.

Before upgrading: if a pipeline relied on wrapping, adjust the input data or theon\_failuresetting.

Closing

This release is worth testing if any of these apply: you write through the Prometheus ecosystem and care about native histograms; you ingest JSON logs at volume; you have high series cardinality and are sensitive to query performance; or you need cross-instance migration and regular backups.

It is a beta, so validate it in a test environment first, and go through the 4 breaking changes above one by one before upgrading. The full change list is in theGitHub Release.

Thanks to the 22 contributors in this cycle. Six of them contributed for the first time:

  • @agrawalxbuilt the Splunk HEC ingestion
  • @raphaelroshanadded table-levelauto\_flush\_interval, along with connection string redaction and a literal negation panic fix
  • @srivtxaddedALTER TABLE SET auto\_flush\_interval
  • @yimengmade PostgreSQL acceptintervalstylewithout quotes
  • @divyansh-1009made timestamp display precision follow the column schema
  • @RitwijParmarmade Prometheus label discovery stream catalog tables instead of looking each one up by name

These capabilities will keep improving before the v1.2.0 stable release, and we welcome bug reports from your testing.

Similar Articles