This thread overlaps a lot with "Observability 2.0 and the Database for It" (https://news.ycombinator.com/item?id=43789625). The core claim there is: treat logs/spans as structured "wide events", and build a storage/query layer that can handle high-cardinality events so many metrics become derived views rather than pre-modeled upfront. It also argues the hard part isn't "dump it in S3", it’s indexing/queryability + cost control at scale.
In an agentic AI world this pressure gets worse: telemetry becomes more JSON-ish, more high-cardinality (tool names, model/version, prompt/template IDs, step graphs), and more bursty, so pre-modeling every metric up front breaks down faster.
I can't believe they made this decision. It's detrimental to the open-source ecosystem and MinIO users, and it's not good for them either, just look at the Elasticsearch case.
Hi HN, I'm Dennis from Greptime. This article is based on a talk by our engineer Ruihang Xia, who is also a PMC member of Apache DataFusion.
The most surprising finding for me was the hash seed trick - using the same random seed across HashMaps in a two-phase aggregation gives you ~10% speedup on ClickBench. The bucket distribution from the first phase can be preserved during merge, eliminating rehashing overhead and making CPU cache happy.
We also discuss why Rust's prost library can be significantly slower than Go's protobuf implementation, and how fixing it improved our end-to-end throughput by 40%.
Happy to discuss Rust performance optimization or DataFusion internals.
Glad to see that Ruby Under a Microscope is still being updated. It’s an essential read for anyone who wants to understand how Ruby works internally — and I truly enjoy reading it.
Thank you for giving GreptimeDB a shout-out—it means a lot to us. We created GreptimeDB to simplify the observability data stack with an all-in-one database, and we’re glad to hear it’s been helpful.
OpenTelemetry-native is a requirement, not an option, for the new observability data stack. I believe otel-arrow (https://github.com/open-telemetry/otel-arrow) has strong future potential, and we are committed to supporting and improving it.
FYI: I think SQL is great for building everything—dashboards, alerting rules, and complex analytics—but PromQL still has unique value in the Prometheus ecosystem. To be transparent, GreptimeDB still has some performance issues with PromQL, which we’ll address before the 1.0 GA.
Are you saying that you prefer SQL over PromQL for metrics queries? I haven't tried querying metrics via SQL yet, but generally speaking have found PromQL to be one of the easier query languages to learn - more straightforward and concise IME. What advantages does SQL offer here?
I didn’t mean SQL over PromQL — they’re designed for different layers of problems.
SQL has a broader theoretical scope: it’s a general-purpose language that can describe almost any kind of data processing or analytics workflow, given the right schema and functions.
PromQL, on the other hand, is purpose-built for observability — it’s optimized for time‑series data, streaming calculations, and real‑time aggregation. It’s definitely easier to learn and more straightforward when your goal is to reason about metrics and alerting.
SQL’s strengths are in relational joins, richer operator sets, and higher‑level abstraction, which make it more powerful for analytical use cases beyond monitoring. PromQL trades that flexibility for simplicity and immediacy — which is exactly what makes it great for monitoring.
These functions encode and decode latitude/longitude to H3 cells and provide utilities for querying cell properties, neighborhoods, distances, and relationships.
I had a brief look at greptime db. And I'd like to give a little bit of feedback on your funnel. It is clear that your product marketing is targeting business folks rather than developers. That 3 minute vid on the frontpage was next to useless for me. Also very clearly AI.
Having stats is nice but i am not choosing your product because of stats. I actually think greptimedb is exactly what I am looking for, I.e. a humio / falcon logscale alternative. But I had to do some digging to actually infer that.
Your material doesn't highlight what sets you apart from the competition. If you want to target developers which you might not. I dont know.
I want to debug issues using freetext search, i want to be able to aggregate stats i care about on demand.
In an agentic AI world this pressure gets worse: telemetry becomes more JSON-ish, more high-cardinality (tool names, model/version, prompt/template IDs, step graphs), and more bursty, so pre-modeling every metric up front breaks down faster.