Greptime

The open-source observability database. One columnar engine for metrics, logs & traces on object storage. SQL across signals. PromQL for metrics.

[Greptime @Greptime]

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: https://t.co/ZVk3nyw7yM

[Greptime @Greptime]

Metrics, logs, and traces in one explore view, with one time range and one set of label filters across all three. Signals Explore ships in the GreptimeDB v1.3 dashboard.

Click a trace_id in a log line and the whole trace opens next to it.

The live demo runs on the OpenTelemetry official shop Demo:
https://t.co/lzcAhNQA0T

[Greptime @Greptime]

Day 1 at #KubeCon

Thank you for stopping by and speaking with us about observability data infrastructure.

See you tomorrow at booth 262—let’s keep connecting!

[Greptime @Greptime]

High-cardinality telemetry and fast access to historical data are both essential for observability at scale.

Our co-founder shares how OpenAI uses GreptimeDB to address these challenges for Spark—and make the data more accessible to AI agents. 👇

[Dennis Zhuang @killme20082]

#OpenAI gave two talks at Community Over Code EU 2026 on running #Spark at their scale: hundreds of thousands of applications a day. Both end up at GreptimeDB for Spark observability, from opposite ends.

One wanted metrics for every Spark task. That's up to tens of millions of new series a day, with logs, metrics and events sitting in separate stores.

The other needed the Spark History Server fast enough for agents. Opening a 100 GB+ event log could take up to half an hour, and every agent tool call waited on it.

Where it landed: a listener in the Spark driver writes jobs, stages, tasks and executors into #GreptimeDB. The History Server reads from it. The #Flink job that parsed event logs, "probably one of the most expensive Flink apps at OpenAI", is no longer needed. The data sits on S3 as #Parquet, so Spark and Trino query it directly.

My read: high cardinality and scattered signals are one problem. They show up together once telemetry is fine-grained enough to be useful.

Our notes on both talks, with timestamps: https://t.co/p2h0C4FVP4

[Greptime @Greptime]

Getting ready for KubeCon + CloudNativeCon North America 2026! 🚀

Come meet the Greptime team at booth #262. See you tomorrow! 👋

#KubeCon #CloudNative #Observability

[Greptime @Greptime]

In GreptimeDB's original trace model, every new span attribute key becomes a new table column. Ship a feature flag, add two columns.

Trace V2 in GreptimeDB v1.3 stores span, scope, and resource attributes in three JSON2 columns instead. We wrote the same 160 spans from three services to both models:

- Trace V1: 37 columns, two of them added when one service started sending feature_flag.* attributes
- Trace V2: 19 columns, before and after

Attributes stay queryable with plain SQL. Quote a key that contains dots and cast it to the type you need:

span_attributes."http.response.status_code"::BIGINT

Trace V2 is experimental and opt-in: set x-greptime-pipeline-name: greptime_trace_v2 on OTLP/HTTP requests and write to a new table. Existing V1 tables are not migrated.

https://t.co/07qszlVvlD

#OpenTelemetry #Observability #OpenSource

[Greptime @Greptime]

What's a Prometheus native histogram? One sample holding sum, count, and exponential buckets that follow the data, instead of one series per bucket edge you fixed in advance.

Same 13,612 requests: classic p99 says 99 ms, native says 90 µs.

GreptimeDB v1.3 ingests and queries native histograms by default.

https://t.co/UiMb7pzuXx

[Greptime @Greptime]

GreptimeDB v1.3: native histograms are on by default. Send them over Prometheus Remote Write v2 or as cumulative OTLP exponential histograms, then query with histogram_quantile and histogram_fraction.

PromQL compliance tester: 88.7% in v1.2.1, 94.8% in v1.3 (labels and values; __name__ not compared).

Also new, experimental: Trace V2 with attributes in JSON2, and a semantic entity graph you can query with SQL.

Read the full blog:
https://t.co/GmyBJ6diHf

[Dennis Zhuang @killme20082]

The recordings are up. Both talks get into how OpenAI uses GreptimeDB:

- Operating Spark at OpenAI's Hyperscale Lakehouse: per-task metrics mean tens of millions of time series a day, and logs, metrics and events sat in separate systems. GreptimeDB now holds metrics, events and logs together, stored on S3 as Parquet.
https://t.co/FnAsbLbacC

- Beyond the Spark UI: a listener in the Spark driver ships job, stage and task records through Grafana Alloy into GreptimeDB, which let them drop one of their most expensive Flink jobs.
https://t.co/0k5qfTVOnh

[Greptime @Greptime]

October in GreptimeDB updates:

v1.3 shipped, with native histograms on by default and opt-in Trace V2.

On main for v1.4:
- PostgreSQL COPY FROM STDIN loads CSV and InfluxDB line protocol: ~997K rows/s vs ~47K for INSERT in the PR's benchmark
- JSON2 paths can declare inverted and skipping indexes, so filters on them prune SSTs
- TWCS stops rewriting L1 files in windows with no new data: write amplification 40.7 → 3.3 in a 6-hour benchmark

243 PRs merged, 34 of them from 14 community contributors ♥️.

https://t.co/y8PpGALLts

[Greptime @Greptime]

Your logs keep growing. Query traffic comes in peaks. Why scale storage and compute together?

In 3 minutes: how GreptimeDB separates them with shared object storage in distributed deployments, and reuses data files during repartitioning.

https://t.co/3hCde9iAY8

[Greptime @Greptime]

Observability has spent years borrowing databases built for something else. It deserves one built for it, and only for it.

Greptime co-founder @killme20082 on what that commits us to. The replies show what it changes inside the engine.

[Dennis Zhuang @killme20082]

What is an observability database? My definition: a database with unified storage and querying for metrics, logs, traces and wide events, that understands the semantics in the data and uses them to optimize storage, query execution and scaling.

How it differs from what's around it:
- vs. one store per signal: one logical model, one engine for SQL and PromQL
- vs. a general analytics engine: protocol semantics drive the physical design, and it serves telemetry only
- vs. a platform: it sits below; alerts stay on Prometheus, dashboards with Grafana

GreptimeDB v1.3, out today, moves closer on storage, query execution, and semantics. More in the post:

https://t.co/0kaLS5vpx5

[Greptime @Greptime]

Heading to KubeCon + CloudNativeCon North America in Salt Lake City? Come find us at Booth 262, Nov 10–12.

We'll be running a live demo there: an OpenTelemetry pipeline sends metrics, logs, and traces over OTLP into one GreptimeDB instance, and dashboards and AI-assisted investigation query that same data.

Our CEO @killme20082 , CTO @Sunng , and engineer @ratuthomm will be there. Bring your observability storage bill and your migration questions.

#KubeCon

https://t.co/ZY4q6RbH82

[EMQ Technologies @EMQTech]

A recent benchmark found #GreptimeDB achieved 31% higher ingestion throughput than #InfluxDB Enterprise!

Explore the findings on ingestion throughput, query performance, and storage footprint, and what they mean for #EMQX Tables: https://t.co/3EyqH2TxJJ

#IoT #EMQXTables

[Greptime @Greptime]

On the ingest side, moving is an exporter change in your OTel Collector. Grafana keeps its Prometheus and Jaeger datasources; LogQL and TraceQL panels move to SQL.

https://t.co/whutp0CDVI

[Greptime @Greptime]

Loki, Tempo, and Mimir: three backends, three query languages, three retention configs. GreptimeDB replaces all three and keeps your Grafana.

[Greptime @Greptime]

Does one interface matter? In Agent RCA Bench, agents querying GreptimeDB got 130 of 168 root causes right, against 105 through Prometheus, Loki, and Tempo, and read about 48% less input. Storage, query language, and tools change together, so this isn't one variable.

https://t.co/BStml6InqW

[Greptime @Greptime]

OpenTelemetry's GenAI semantic conventions give an LLM call, each agent step, and each MCP tool call the same trace_id. That pays off only if your backend can join on it: keep traces, token metrics, and conversation logs in one database, and "which prompt burned the tokens?" is one SQL query.

Update since our spec walkthrough: the conventions moved to open-telemetry/semantic-conventions-genai (still Development), and a merged, unreleased change splits gen_ai.client.token.usage into per-direction histograms.

Demo: https://t.co/gUWhs7jVNY

Spec: https://t.co/mD9oZW1skU

KubeCon NA, Nov 10–12: Booth 262.

[Dennis Zhuang @killme20082]

We ran 504 root-cause investigations to test one thing: does the query interface matter as much as the model?

Six models, same prompt, same incidents. One arm queried Prometheus, Loki, and Tempo through their native APIs. The other queried the same telemetry in GreptimeDB with SQL and PromQL.

The GreptimeDB arm got 130 diagnoses right versus 105, 40% fewer wrong ones, with about 48% less input: roughly $0.60 versus $1.10 per investigation. Five of six models improved. Claude Fable 5.1 went from 27 to 26.

We sponsor this benchmark, so check our work. Protocols were frozen in Git, every trajectory is public, and only 3 of the 12 pre-specified endpoints passed statistical correction, all on input reduction.

https://t.co/0AWr8DmXS5

[Dennis Zhuang @killme20082]

Part two of the agent-data thread: what happens when that data grows faster than you planned.

In a GreptimeDB cluster, data lives in object storage. A datanode owns regions; it doesn't hold the only copy. Moving a region to another node moves ownership, not bytes.

I tried it on my laptop (v1.2.1, 2 datanodes + MinIO):
- 12.4 MB region: moved in 0.11–0.18 s
- 1.81 GB region, 30M rows: 0.10–0.27 s

150× the data, same move time. The new node opens the region from its manifest, the old one flushes what's still in memory, then leadership and routing switch. No SST is copied 😃.

The cost: writes to that region fail for ~20–40 ms during the switch. Every acked write was there afterwards (I counted). In v1.2 the client retries; v1.3 beta retries in the frontend.

Busy laptop, so treat the numbers as indicative. The flat line is the point.

https://t.co/9cSDSkxm9h