Greptime @Greptime

Frontend CPU +95%. Datanode CPU −20%. Prometheus ingestion +81%. We stopped doing row work under the Region lock in v1.2 and moved it to the Frontend, which scales out for free. greptime.com/blogs/2026-05-…

We ran GreptimeDB v1.2 against InfluxDB 3.11 Core and Enterprise: same 8 vCPU box, same TSBS dataset, 103.68M rows from 4,000 hosts. Our read: keeping data in open Parquet hasn't cost us query speed. Queries across all 4,000 hosts (group-by, order-by-limit, lastpoint): GreptimeDB is 1.8–3.6x faster than Enterprise, 3.0–9.9x after one manual compaction. lastpoint: 9,347 ms vs 947 ms. high-cpu-all is roughly a tie. Queries on 1 or 8 hosts: Enterprise wins, 1.3–3.4x faster than compacted GreptimeDB. That's 3.6–19.9 ms vs 5.9–31.8 ms. Ingest: 295k rows/s, 1.31x Enterprise. InfluxDB got 25k-row batches and 16 workers to reach its best; at GreptimeDB's 3k/6 it did 18k rows/s. InfluxDB 3 Core, also on Parquet, was slower on 13 query types and ran out of memory on the other 2. Full numbers, plus agent prompts to reproduce it: greptime.com/blogs/2026-10-…

keyboard_arrow_left Previous keyboard_arrow_right Next

"Payment still failed after retries" is hard to grep for. GreptimeDB v1.3 adds experimental AI functions to SQL: ai_match filters rows by a natural-language prompt, ai_choose classifies them, ai_score rates them. docs.greptime.com/nightly/refere…

@OurTinTinLand @Vivo_GLOBAL @SolanaFndn @Kimi_Moonshot @kong @ideavibes_ai @NEARProtocol We’re honored to sponsor RustChinaConf 2026 and wish the conference every success!

From our blog: ORDER BY end_time DESC LIMIT 10 on a ~5–6B-row trace table took 28.9s. Since v1.0, GreptimeDB feeds TopK's running bound into the scan, building on DataFusion's dynamic filters, and skips row groups that can't make the top 10. Now 0.21s. greptime.com/blogs/2026-05-…

We ran both side by side: one Prometheus 3.15, two remote_write queues into GreptimeDB, 4 minutes. Same 43,445 samples, same 364 tables. RW 2.0 sent 716 KB vs 916 KB for RW 1.0 (metadata included), about 22% less. One small workload; yours will vary.

Running Prometheus with Remote Write 2.0? GreptimeDB v1.2 accepts it for regular samples: add one protobuf_message line to prometheus.yml, nothing to change on the GreptimeDB side. Metadata and exemplars aren't stored yet. greptime.com/blogs/2026-09-…

GreptimeDB in September: v1.2 is GA. If you use JSON2 columns, go straight to v1.2.1: it fixes a bug where a manually triggered strict-window compaction could drop rows. Automatic compaction is not affected. The v1.3 beta adds two observability changes: - Trace V2: OTLP span, scope and resource attributes are stored in three JSON2 columns instead of one column per attribute key. Query them by path, e.g. span_attributes."http.status_code"::BIGINT. Jaeger queries and the Semantic Graph work on the new model. - Native histograms from Prometheus Remote Write v2 and OTLP are ingested by default. No feature switch. Monthly report: greptime.com/blogs/2026-09-…

Large export over a flaky link? GreptimeDB v1.2 splits backups and migrations into time chunks, runs them in parallel, and resumes after an interruption: rerun the same command and finished chunks are skipped. docs.greptime.com/1.2/user-guide…

Big sort or aggregation over the memory limit? GreptimeDB v1.3 lets you pick where it spills to disk, cap the space, and compress the files. Experimental for now.

Versions with JSON2 support: Go v0.7.5 · Java v0.16.0 · Rust v0.19.0 · TS v0.3.0 · .NET v0.4.0 · Erlang v0.3.0 Requires GreptimeDB v1.2.1+ github.com/GreptimeTeam?q…

All GreptimeDB ingester SDKs can now write JSON2 columns: Go, Java, Rust, TypeScript, .NET, and Erlang. JSON2 (new in GreptimeDB 1.2) stores hot JSON paths as their own columns, so a filter on http.status reads that column instead of every full document. How it works: greptime.com/blogs/2026-09-…

GreptimeDB Enterprise 26.05.1 lets Spark, Trino, DuckDB, and pyiceberg read GreptimeDB tables as Iceberg tables, without copying the data. GreptimeDB already stores SST files as Parquet in object storage. On every flush and compaction, it now also writes Iceberg manifests and snapshots that point at those same files, and the frontend serves a REST catalog at /v1/iceberg. Only metadata is duplicated. No second data pipeline to keep in sync. Early preview: read-only, latest snapshot only, no time travel. Also in 26.05.1: - Compaction on a cron schedule, run by metasrv - Region Balancer now tracks per-region query CPU alongside write throughput - Opt-in soft drop: DROP TABLE lands in a recycle bin, UNDROP TABLE brings it back - Named permission actions, regex database ACLs, and a query guard that can ban DROP for every user, admins included Built on the open-source GreptimeDB v1.2 engine. greptime.com/blogs/2026-09-…

HDFS support for GreptimeDB datanode storage has been merged and is coming in v1.3.0-beta.1 this week. [storage] type = "Hdfs" name_node = "hdfs://127.0.0.1:9000" root = "/greptimedb" It goes through OpenDAL's HdfsNative service, backed by the pure-Rust hdfs-native client. No JVM or libhdfs on the datanode. Non-append writes go to a temp file and are published with an atomic HDFS rename, so a failed manifest write can't leave a truncated file at the final path. This was built by community contributor Minghan Jiang (Minghan2005 on GitHub): the backend, the atomic-write and copy layer, and the tests. Thank you, Minghan. Once the beta is out, we'd like to hear how it behaves on your HDFS cluster. github.com/GreptimeTeam/g…

Looking for help: Python bindings (PyO3) for the GreptimeDB Rust ingester. Scope is writes only: row inserts, plus bulk writes over Arrow Flight DoPut. The piece I'd most like help with is on the Rust side. BulkStreamWriter only takes row-by-row Rows today. A public RecordBatch write path would let Python hand over pyarrow / pandas / polars data through the Arrow PyCapsule interface, no per-row conversion. If you know PyO3 or arrow-rs, the plan and checklist are here: github.com/GreptimeTeam/g…

The JSON2 layered storage: 1. Static typed paths for declared fields 2. Dynamic paths for auto-expanded fields within a budget. 3. Remainder paths for long-tail fields

Inside GreptimeDB 1.2's New JSON Type

Dennis Zhuang @killme20082

3 weeks ago

GreptimeDB's JSON2 makes JSON paths individually readable as columns while keeping the complete document. The constraint matters: expanding every path would let the physical schema grow indefinitely. We cap automatic expansion and keep the remaining fields in Parquet Variant.

1 2 18 2K 7

GreptimeDB implements PromQL natively in its planner rather than translating it to SQL.

Dennis Zhuang @killme20082

4 weeks ago

In addition to using EXPLAIN ANALYZE to analyze SQL execution plans, GreptimeDB also supports this for PromQL. You can run it directly in the Dashboard, as shown in the figure. This is because GreptimeDB implements PromQL directly as a DataFusion plan, rather than converting

keyboard_arrow_left Previous keyboard_arrow_right Next

0 1 4 2K 0

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: greptime.com/blogs/2026-09-…