I wrote Clojure for about five years. Left when I changed jobs, not because I wanted to. It's genuinely one of the most productive languages I've used, and I still miss the REPL-driven workflow.
One thing I built: defun https://github.com/killme2008/defun -- a macro for defining Clojure functions with pattern matching, Elixir-style. Still probably my favorite thing I've open sourced.
Would love feedback from folks running observability/time-series workloads, especially on upgrade paths + repartition behavior in real clusters. GitHub releases/changelog: https://github.com/GreptimeTeam/greptimedb/releases
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.
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.
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.
These functions encode and decode latitude/longitude to H3 cells and provide utilities for querying cell properties, neighborhoods, distances, and relationships.
Thanks for your feedback. We fixed the descriptions of log query endpoints. Hope it's more clear.
Glad you're considering giving it a try and looking forward to your feedback.
Yes, so many startups are trying to solve the log issue in the current stack.
In my personal observation, the vast majority of startups are still focused on the product layer and use ClickHouse directly for storage. However, ClickHouse’s tightly coupled storage and compute architecture makes it difficult to scale, and this becomes a real problem as workloads grow. GreptimeDB, on the other hand, is more focused on being an all-in-one observability database. Our log UI, however, still has quite a gap compared to products like Kibana.
This space is very crowded. I think it’s unlikely that any new startup will succeed here unless it can first solve its own business use case exceptionally well.
In fact, we have an open-source query language, but it's still in experimental, so we don't present it on the website. The description of the enterprise feature is not precise. Sorry for the inconvenience.
GreptimeDB also open-sources the log view UI if you read the article.
I agree with you that ETL is so powerful, and GreptimeDB is so young, we still have lots of work to do. Thank you.
Fair point. Joining time-series data with business data is often necessary. While GreptimeDB currently supports external tables for Parquet and CSV files, we plan to expand this support to include datasources like MySQL and PG in the future.