Greptime | The Single Database for Observability on S3

Prometheus 3.0 is the first major release in 7 years. The breaking changes are subtle, and that's the harder kind for backends to catch up to. The big-ticket items got headlines: UTF-8 metric names by default, Remote Write 2.0 with string interning (60% fewer bytes on the wire, 90% fewer allocations), native histograms, native OTLP ingestion. The quieter ones are what take real work to stay compatible:  • 𝗥𝗮𝗻𝗴𝗲 𝘀𝗲𝗹𝗲𝗰𝘁𝗼𝗿𝘀 went from [closed, closed] to (open, closed]  • 𝐃𝐨𝐭 𝐢𝐧 𝐫𝐞𝐠𝐞𝐱 now matches newlines  • 𝗛𝗼𝗹𝘁-𝗪𝗶𝗻𝘁𝗲𝗿𝘀 renamed to double_exponential_smoothing  • 𝗧𝗦𝗗𝗕 𝗶𝗻𝗱𝗲𝘅 𝗳𝗼𝗿𝗺𝗮𝘁 changed; rollback from 3.0 only works back to v2.55 GreptimeDB implements PromQL in Rust, with our own parser (promql-parser, https://lnkd.in/gh2ksNeN) and an execution engine on Apache DataFusion. Staying drop-in compatible meant four concrete PRs: left-open range selectors, start-exclusive instant selectors, the function rename, and a parser upgrade for UTF-8 label names. What stood out writing this up: PromQL compliance isn't a one-time milestone. Every Prometheus release introduces small semantic shifts. The PromLabs compliance suite is the only honest way to track them. Full walkthrough of every notable 3.0 change and the adaptation work: https://lnkd.in/gCGWG94J #Prometheus #PromQL #Observability #OpenSource

We're excited to collaborate with DeepXplore to help teams move faster from signal to action. By combining GreptimeDB’s unified telemetry foundation for metrics, logs, and traces with DeepXplore's automated analysis capabilities, we can help engineering teams detect issues earlier and accelerate root-cause investigation.

𝗦𝘁𝗼𝗿𝗶𝗻𝗴 𝘁𝗲𝗹𝗲𝗺𝗲𝘁𝗿𝘆 𝗳𝗿𝗼𝗺 𝗖𝗹𝗼𝘂𝗱𝗳𝗹𝗮𝗿𝗲 𝗪𝗼𝗿𝗸𝗲𝗿𝘀 𝗶𝘀 𝗵𝗮𝗿𝗱𝗲𝗿 𝘁𝗵𝗮𝗻 𝗶𝘁 𝗹𝗼𝗼𝗸𝘀. Each invocation is short-lived, and the runtime is V8 isolates rather than Node.js, so long-lived agents and most Postgres drivers don't transplant cleanly. Cloudflare's own storage primitives leave a gap too: D1 is SQLite, designed for relational app data. Workers Analytics Engine caps cardinality and samples lossily, so arbitrary SQL on raw events is off the table. That gap is what our latest guide is about: using GreptimeDB as the event and metric store for Cloudflare Workers, with both writes and reads happening from inside the Worker runtime. Two protocols, one database: - Writes go out as InfluxDB line protocol over HTTP via 𝗳𝗲𝘁𝗰𝗵(). No agent, no SDK that needs a long-lived connection. - Reads go through Cloudflare Hyperdrive over PostgreSQL wire, so each Worker invocation gets pooled connections instead of paying TCP+TLS every request. The schema is small: low-cardinality primary key (𝗰𝗼𝗹𝗼, 𝗰𝗼𝘂𝗻𝘁𝗿𝘆, 𝗵𝘁𝘁𝗽_𝗺𝗲𝘁𝗵𝗼𝗱), 𝗮𝗽𝗽𝗲𝗻𝗱_𝗺𝗼𝗱𝗲 = '𝘁𝗿𝘂𝗲' so request rows don't dedup at the millisecond, 𝘁𝘁𝗹 = '30𝗱' to auto-expire. Tensor Fusion was the team that hit this wall first, before Hyperdrive became their fix. The new piece is that the whole thing is now a `docker compose` demo: clone, run, query, then deploy the same Worker to Cloudflare's edge. https://lnkd.in/gPXbtt4p #CloudflareWorkers #EdgeComputing #Observability #TimeSeries

Greptime is heading to 𝐈𝐨𝐓 𝐓𝐞𝐜𝐡 𝐄𝐱𝐩𝐨 𝐍𝐨𝐫𝐭𝐡 𝐀𝐦𝐞𝐫𝐢𝐜𝐚 𝟐𝟎𝟐𝟔 — part of TechEx, the leading enterprise tech event series in North America. Find us at 𝐁𝐨𝐨𝐭𝐡 𝟏𝟏𝟓 for two days of conversations on real-time data infrastructure for the connected world. #IoTExpoNA2026

𝟯𝟬𝟬𝗧𝗕 of multi-cloud logs and SQL audit, on GreptimeDB. That's where OceanBase Cloud landed a year after migrating off Grafana Loki, and the platform team came back to the GreptimeDB user meetup with the numbers: - 𝟴𝟬+ clusters across 7 major public clouds (Alibaba, Huawei, Tencent, Baidu, AWS, Azure, GCP) - 300TB at 7-day retention; largest single cluster 50TB; ~1GB/s sustained write - 𝟲𝟬%+ overall storage cost reduction — and the same 60% passed through to end customers on SQL audit pricing What stood out to me wasn't the numbers themselves — those are the result. It was that they didn't skip the messy parts. They tried Aliyun SLS first (vendor lock-in, expensive at full-index scale). They surveyed all 7 cloud-native logging stacks and gave up on a unified abstraction over CloudWatch, KQL, LogQL, and friends. They looked at ClickHouse before its text index was production-ready. Loki carried them through generation one, until label-only indexing capped them at minute-range queries. The blog also walks through version pain points (0.12 → 0.13 → 0.15), the move to GreptimeDB Enterprise, and a newer piece their team built: an AI diagnosis agent that pulls Top SQL from the same audit table their SREs use, over GreptimeDB MCP Server. https://lnkd.in/gKP7ivEG #Observability #Logging #MultiCloud

𝗪𝗵𝗮𝘁 𝗶𝗳 𝘀𝗰𝗮𝗹𝗶𝗻𝗴 𝗜𝗼𝗧 𝘁𝗼 𝗺𝗶𝗹𝗹𝗶𝗼𝗻𝘀 𝗼𝗳 𝗱𝗲𝘃𝗶𝗰𝗲𝘀 𝗱𝗶𝗱𝗻'𝘁 𝗿𝗲𝗾𝘂𝗶𝗿𝗲 𝗽𝗮𝗶𝗻𝗳𝘂𝗹 𝗺𝗶𝗴𝗿𝗮𝘁𝗶𝗼𝗻𝘀? With EMQX Tables powered by GreptimeDB, teams can scale from standalone to distributed clusters without changing SQL, pipelines, or dashboards. A great deep dive from the EMQX team — worth a read. #GreptimeDB #EMQX #IoT #TimeSeries #DistributedSystems

𝗙𝗼𝘂𝗿 𝘆𝗲𝗮𝗿𝘀 𝗼𝗳 𝗚𝗿𝗲𝗽𝘁𝗶𝗺𝗲𝗗𝗕 𝗶𝗻 𝘁𝗵𝗲 𝗼𝗽𝗲𝗻 Four years ago this November, our kernel lead clicked the button that turned GreptimeDB's GitHub repo public — and was so excited he forgot his password. No launch event. We just went back to coding. Now at v1.0, Jiachun Feng has written down the version of those four years that doesn't fit in a press release. He's still proud of choosing Rust in 2022, when picking it for a database was still very much a minority choice. He's still proud of the v0.4 storage rewrite (Mito2), made when patches stopped helping. And he's still proud of the bet that metrics, logs, and traces shouldn't stay siloed, even though th conventional answer at the time said otherwise. Other things didn't hold up as well. We shipped a Python coprocessor users didn't really want, and spent a long stretch treating community-building as something that would just happen if the code was clean. The abstraction boundaries we left fuzzy at v0.1 ended up costing us interest for years. Then there's the part the post lingers on. Lanqing Yang, who started with a small UX PR and slowly worked his way into the kernel until we made him a committer. DeepXplore, who picked us not because we were faster, but because they wanted their time back. The 126 contributors behind 5,200+ commits, most of whom we'll never meet in person. The line that stays with you: in infrastructure software, judgment matters. 𝗧𝗵𝗲 𝗿𝗮𝗿𝗲𝗿 𝘁𝗵𝗶𝗻𝗴 𝗶𝘀 𝗽𝗮𝘁𝗶𝗲𝗻𝗰𝗲. 𝘃𝟭.𝟬 𝗶𝘀𝗻'𝘁 𝗮 𝗳𝗶𝗻𝗶𝘀𝗵 𝗹𝗶𝗻𝗲. It's where we start being responsible for something other people depend on. Read: https://lnkd.in/gJ_zNaxx  #OpenSource #Database #Observability

We reran the GreptimeDB ingestion protocol benchmark on v1.0 GA. 𝗧𝗵𝗲 𝗽𝗿𝗼𝘁𝗼𝗰𝗼𝗹 𝘀𝗲𝗹𝗲𝗰𝘁𝗶𝗼𝗻 𝗴𝘂𝗶𝗱𝗮𝗻𝗰𝗲 𝗶𝘀 𝘁𝗵𝗲 𝘀𝗮𝗺𝗲. gRPC Bulk is still the fastest for bulk imports, gRPC SDK is a reasonable default, HTTP (InfluxDB LP / OTLP) is the one to pick when you're already in an ecosystem, and SQL is for debugging and ad-hoc work. What changed this round was the run conditions: - OTLP Logs goes through the `greptime_identity` pipeline now, so attributes are expanded into individual columns. The storage layout is finally comparable to the other protocols. Pipeline processing is not free, and OTLP throughput drops to about 621K rows/sec. - A timestamp type mismatch in the Go ingester, surfaced by v1.0's stricter Arrow schema check on the Bulk path, is fixed in `greptimedb-ingester-go` v0.7.2. - PostgreSQL has prepared-statement caching enabled. Throughput roughly doubled. Numbers at batch=1000, 1M series (rows/sec): - gRPC Bulk (Arrow): 2.68M (3.34M at batch=2000) - gRPC Stream: 1.56M - gRPC SDK: 1.17M - InfluxDB LP: 889K - OTLP Logs: 621K - PostgreSQL: 74K - MySQL: 72K About 37x between fastest and slowest. One thing we didn't expect and ended up chasing: gRPC Bulk runs 𝟯𝟳% 𝗳𝗮𝘀𝘁𝗲𝗿 𝗮𝘁 𝟭𝗠 𝘀𝗲𝗿𝗶𝗲𝘀 𝘁𝗵𝗮𝗻 𝗮𝘁 𝟭𝟬𝟬𝗞. It's the only protocol that speeds up as cardinality grows, and it came down to BulkMemtable flush costs. A 50M-row rerun showed the same pattern. https://lnkd.in/gWVndd96 #TimeSeries #Observability #Database

Most TSDB engines put an inverted index on label sets, and that's usually what breaks before the cartesian product does. Past a million series the posting lists get huge and intersecting them gets slow, and for high-cardinality columns (request IDs, trace IDs), the queries end up touching most of the series anyway. At that point you're often better off skipping the index and doing columnar scans with min-max / zone pruning over time partitions. Physical layout matters at least as much as indexing, and gets talked about less. Classic TSDB storage is series-oriented: a buffer per series in the memtable, rows packed tight per-series on disk. Works great for a few hundred thousand series. At millions, the per-series bookkeeping (memory, dedup merge cost) eats everything, and scans start behaving like a row store. A flat columnar layout with bulk-sorted parts and no per-series state scales a lot better. On TSBS at 2M series we got around 4x write throughput and up to 10x on some queries vs. the series-oriented layout. If you want to dig in, we wrote these up: - https://lnkd.in/g_PAm2qE — why inverted indexes break in TSDBs - https://lnkd.in/gyvqcfZX — the flat layout and benchmarks #TimeSeries #HighCardinality

Excited to be in Seattle this week! ✈️ I’m looking forward to speaking at the DataFusion meetup https://luma.com/hxshbp0m about JSON. I’ll be diving into some technical insights, performance considerations, and how we could better handle JSON in modern workloads. If you’re in the area or attending the meetup, I’d love to connect, swap ideas, or just grab a coffee! See you there! 👋