killme2008

An open-source, cloud-native observability database released v1.0 after four years of hard work.

Working on a personal project: langfuse on GreptimeDB, try to make S3 optional.

https://github.com/tma1-ai/openfuse

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.

Claude caught up pretty quickly. I think OpenClaw’s core value is the channel, heartbeat, and the open-source ecosystem.

Hi HN — I’m the creator of GreptimeDB. We just shipped v1.0.0-rc.1 (our first 1.0 release candidate / feature-freeze milestone).

Highlights:

Online region repartition (SPLIT/MERGE) to adjust partitions at runtime (distributed clusters; shared object storage + GC).

Faster Metric Engine PK filters via memcomparable byte comparisons (microbench: ~20–90× on dense codec).

PromQL planner prefers TSID (skips unnecessary label columns).

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.

Yeah, that’s true — Microsoft’s report (https://www.microsoft.com/en-us/msrc/blog/2019/07/why-rust-f...) says the same thing, and Google’s recent post on Rust in Android (https://security.googleblog.com/2025/11/rust-in-android-move...) backs it up too.

We’ve been using Rust for about seven years now, and as long as you stay away from fancy unsafe tricks, you really can avoid most memory safety bugs.

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.

Hi there, I’m from the GreptimeDB team.

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.

A technical discussion on the limits of current observability stacks and what a merged data model could look like.

Hi. I am from GreptimeDB team. We use h3o library to implement h3 functions:

https://docs.greptime.com/reference/sql/functions/geo/#h3

These functions encode and decode latitude/longitude to H3 cells and provide utilities for querying cell properties, neighborhoods, distances, and relationships.

Thank you for evaluating GreptimeDB.

We agree that fine-grained access control is important. A read-only user role will be available in the next major release.

Insight: Claude Code uses Haiku model for lightweight tasks, Opus for complex ones.

Really fascinating story—thanks for sharing! Graphics programming has been a major driving force behind the widespread adoption of object-oriented programming, and the abstraction of devices in this context is truly elegant.

This article summarizes our experience from a commercial project that runs on an in-vehicle Android system. In this project, we needed to invoke Rust code(DB) from Java(App), so we couldn't directly use the project’s source code for demonstration. Instead, we created a demo project: https://github.com/GreptimeTeam/rust-java-demo

1. I agree that using Rust doesn't necessarily mean faster performance; it simply gives you the opportunity to implement some compute-intensive modules in Rust, which is a possible approach.

2. This is a great suggestion, and we organized our project in the same way. You don’t need to use unsafe for every call. However, if you want to call JNI APIs from Rust, unsafe is required.

3. Sorry, some details were missing here. We use AsyncRegistry(Java) as an intermediary. Before initiating an async operation in Rust, we need to call Java code in advance to register a future and obtain a unique future ID. After the async execution completes, we retrieve the registered future by its ID, and then complete it or complete it exceptionally depending on the async result. You can refer to this code: https://github.com/GreptimeTeam/rust-java-demo/blob/90ffa0ba... and https://github.com/GreptimeTeam/rust-java-demo/blob/90ffa0ba...

4. This article was not generated by AI; it’s just that our official blog has a fixed template at the end. Sorry for the inconvenience.

Interesting idea! However, I'm hesitant to trust it, as I don't even fully trust code that was written by myself :)

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.

Would love to hear your thoughts.

We'll find a way to fix it forever :D

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.

The author is not a native speaker; I promised it's not an AI article but with some minor reviews from AI :)

I completely agree with you—Rust is not well-suited for application development. Application development requires rapid iteration, acceptable performance, and most importantly, a large developer community and a rich software ecosystem.

Languages like Go , JavaScript, C# or Java are much better choices for this purpose. Rust is still best suited for scenarios where traditional system languages excel, such as embedded systems or infrastructure software that needs to run for extended periods.

Yes, GreptimeDB requires a time index column for optimized storage and querying. It's not a constraint of a primary key, but just an independent table constraint.

Could you elaborate on why you find this inconvenient? I assumed logs, for example, would naturally include a timestamp.

Thanks for pointing it out! The footer has been updated.

Agree. Leveraging capabilities provided by cloud vendors is always a good idea. However, as the scale grows, cost inevitably becomes an issue. Third-party solutions often offer cost advantages because they support multi-cloud deployments and are optimized for specific scenarios.

Thanks for your question. GreptimeDB, like MongoDB, is schemaless. When ingesting data via OTEL or its gRPC SDKs, it automatically creates tables by inferring the schema and dynamically adds new columns as needed.

Secondly, I prefer wide tables to consolidate all sources for easy management and scalability. With GreptimeDB's columnar storage based on Parquet, unused columns don't incur storage costs.