The open-source observability database. One columnar engine for metrics, logs & traces on object storage. SQL across signals. PromQL for metrics.
Wolfe Road Sunnyvale
- Tweets 904
- Following 197
- Followers 1,020
- Likes 551
GreptimeDB v1.1: you no longer have to lock in a table's partition layout when you create it.
Before, only tables created with PARTITION ON COLUMNS could be resharded. Now you can take an existing single-Region table and split it online:
ALTER TABLE sensor_readings PARTITION ON COLUMNS (device_id, area) (...)
Repartition as data grows, instead of guessing up front.
Full blog in detail: greptime.com/blogs/2026-06-1…
ALT GreptimeDB v1.1.0 is out, a production-focused release after the v1.0 GA
2
3
707
Greptime retweeted
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/grep…
1
2
11
1,124
Greptime retweeted
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
Made with AI
3
5
146
Inside GreptimeDB 1.2's New JSON Type
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.
Type hints give stable, frequently queried paths dedicated columns. Other paths expand within a budget; querying a path in the remainder still requires extraction.
Luo Fucong @Greptime explains the storage layout and how SQL determines which paths and types to read:
greptime.com/blogs/2026-09-2…
ALT Side-by-side diagram of JSONB and JSON2. JSONB reads whole documents and parses them before filtering and aggregation. JSON2 stores paths in separate columns; the highlighted attrs.http.status column feeds filtering and aggregation directly.
150
GreptimeDB implements PromQL natively in its planner rather than translating it to SQL.
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 PromQL into SQL.
2
2
1,832
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-1…
2
3
572
GreptimeDB now reuses work across overlapping windows in PromQL min_over_time and max_over_time. In our local benchmark, query time for a 2h window at a 30s step dropped about 68%.
At that shape, consecutive windows share almost all their samples, and the old code rescanned each window. The new code keeps a monotonic deque of candidates across windows. A sample is removed once a later sample is higher, because it cannot be the max of any later window. Samples that leave the window are removed from the front. The front is the result. This is the standard sliding window maximum algorithm.
When windows barely overlap, maintaining the deque costs more than a scan, so the evaluator is chosen per batch and those batches use the plain scan.
Same benchmark, 30s step: 5m window −24%, 30m −45%, 2h −68%.
PR by @bwz13624684 on our team. The animation shows the deque on a small example.
github.com/GreptimeTeam/grep…
1
3
586
GreptimeDB v1.2.1 is out: fixes for JSON2 data loss in strict-window compaction, query correctness, MySQL protocol compatibility, and runtime crashes.
On v1.2.0? We recommend upgrading.
github.com/GreptimeTeam/grep…
Made with AI
2
4
166
Greptime retweeted
The OpenTelemetry demo ships with three storage backends: Jaeger for traces, OpenSearch for logs, Prometheus for metrics.
I swapped all three for one GreptimeDB standalone. The collectors didn't change — every signal keeps the protocol it already speaks, only the write address moves.
Reference architecture, plus the compose file to reproduce it:
greptime.com/blogs/2026-09-1…
ALT Reference architecture diagram in four columns. Sources: Application (OTel SDK), Hosts / middleware (exporter), Log files. Collection: OTel Collector (OTLP), Prometheus (remote write), Vector / Fluent Bit (Loki push / ES bulk). All three collection paths converge on a single GreptimeDB box containing Frontend, Metasrv, Datanode, Flownode and Object storage, labelled "metrics, logs, traces in separate tables, one engine". Two arrows leave it: Dashboards and alerts (Grafana, PromQL / SQL), and Investigation and analysis (SQL, agent, Jaeger API).
2
2
16
1,775
GreptimeDB Enterprise now integrates with Apache Iceberg, making your tables queryable from Spark, Trino, DuckDB, and pyiceberg—without copying data. It publishes Iceberg metadata that references existing Parquet files in object storage, enabling seamless, read-only analytics across your data stack.
docs.greptime.com/enterprise…
#GreptimeDB #ApacheIceberg
2
3
208
Evaluate the query interface alongside the RCA model.
In Agent RCA Bench, six models investigated the same 14 incidents. Across 168 runs per interface, GreptimeDB’s SQL/PromQL interface produced 40% fewer wrong diagnoses and used ~48% fewer input tokens than our Prometheus/Loki/Tempo API wrappers.
These totals compare complete bundles of storage, query language, and tool design.
Interactive report: rca-bench.greptime.com/
Full writeup: greptime.com/blogs/2026-09-0…
1
2
396
greptimedb-mcp-server 0.6.0 adds query_semantic_graph.
Since v1.3.0 (alpha), GreptimeDB keeps entity and relationship views in greptime_private, built from trace spans and declared edges. The tool reads them directly, so an assistant asks what calls what instead of writing a self-join over span tables.
The summary view answers first — which types exist and what they connect:
{
"type": "calls", "count": 2,
"endpoints": [
{
"source": "service",
"destination": "service",
"count": 2
}
]
}
Then entities or relationships when it wants the rows.
On older servers the tool isn't offered at all — the server probes the views at startup and drops it from the list.
github.com/GreptimeTeam/grep…
1
1
109
JSON2 shipped in GreptimeDB v1.2.0. When should you use it over JSON?
JSON vs JSON2: a visual guide below. JSON2 is Beta, append-only.
Get started: docs.greptime.com/user-guide…
2
441
GreptimeDB v1.2.0 ships JSON2.
The original JSON type encoded each object as one JSONB binary value. To read http.status, the query engine had to read the entire value.
Logs, traces and agent events are mostly the same shape, and a query touches a few paths. JSON2 stays one complete JSON object to you, and is structured data that can be pruned by path underneath:
SELECT attrs.http.status::BIGINT,
json_get(attrs, 'http.path')::STRING
FROM application_logs;
7 breaking changes to read first.
greptime.com/blogs/2026-09-0…
ALT GreptimeDB v1.2.0 release summary. Left: JSON2 with path pruning, nested paths and list indexing; Import/Export V2 with parallel tasks, progress and resume; ingestion and operations covering Splunk HEC, Prometheus Remote Write v2 and Flow status. Right: a diagram of logs, traces and agent events all flowing into JSON2. Bottom: 331 commits, 25 contributors, 7 first-time contributors, and a note to review breaking changes before upgrading.
75
GreptimeDB v1.3.0-alpha.1 — PromQL native histograms, wide: selection, rate()/delta(), vector operators, aggregations, histogram_quantile and histogram_fraction, over classic, native, and mixed inputs, served on the Prometheus HTTP API. Ingest stays opt-in on both paths; OTLP delta temporality still unsupported.
Also lands: a read-time entity graph derived from OTLP traces, riscv64 builds, Dashboard v0.13.14.
And v1.2.0 GA will ship this week, with JSON2.
github.com/GreptimeTeam/grep…
1
1
2
806
FYI. The semantic layer user guide is ready:
docs.greptime.com/nightly/us…
34
Our contributor guide had been quietly rotting. A few things they told you:
• use memtable.type = partition_tree — removed in v1.1
• writes wake the Flow batching task — they don't, it's on a timer
• Metasrv has a "Central Nervous System" scheduling unit — it does not, and never did
Rewrote 24 pages against the actual source.
docs.greptime.com/contributo…
102
MediaHub's video mixers and audio encoders publish metrics to MQTT topics. Those topics land in a database, queryable in SQL, with no pipeline in between.
That's EMQX Tables from @EMQTech — GreptimeDB is the engine underneath. The EMQX rule engine writes over InfluxDB line protocol, and tables and columns are created from the payload, so ingestion starts before anyone defines a schema.
@tvunetworks runs it for live video production across North America and Europe. Their engineering manager's summary of the change: routing metrics between services used to take days of cross-team coordination. Now it's topic design.
greptime.com/blogs/2026-08-2…
3
118