GreptimeDB: One Columnar Engine for Metrics, Logs and Traces on Object Storage

The three-backend problem GreptimeDB is aimed at

A typical observability stack keeps metrics in Prometheus, logs in Loki or Elasticsearch, and traces in a third store. The README frames the target user as someone who runs Prometheus plus Loki or Elasticsearch and wants one backend instead of three. The second stated motivation is cardinality and retention: teams that have outgrown Prometheus and do not want the Thanos or Mimir operational surface. The third is long retention on object storage without standing up a separate analytics stack. There is also a narrower audience the README names explicitly: teams storing GenAI or agent telemetry alongside infrastructure signals, following the OpenTelemetry GenAI semantic conventions. That is a real category now, because agent traces carry prompt and completion attributes that do not fit a metrics label model well. The audience is therefore infrastructure and platform engineers who already accept SQL, not application developers looking for a hosted dashboard product.

One table model for three signals

The mechanism is a shared table model: every signal is stored as tags, a timestamp, and fields. Metrics, logs and traces are not separate storage engines behind a federation layer. They are tables in one columnar engine, and when records carry common identifiers such as service, host, or trace ID, the README states you can correlate them in SQL without moving data between databases. That is the substantive difference from a federation approach. In a federated setup, correlating a log line with the metric spike that preceded it means querying two systems and joining in your head or in a script. Here the join is a SQL join over columns in the same engine. The cost of that design is that the table model has to be general enough for all three signals, which is why the README describes traces as queried through Jaeger-compatible endpoints rather than through a native trace-specific storage format.

Ingest protocols, query protocols, and where the coverage narrows

Ingest is broad: OpenTelemetry OTLP, Prometheus Remote Write, Loki Push, Elasticsearch Bulk, InfluxDB line protocol, and gRPC. The README's migration pitch is that you move ingestion one signal at a time without rebuilding your collectors. Query is narrower. You get SQL, PromQL, Jaeger-compatible trace queries, and MySQL and PostgreSQL wire protocols. The README's compatibility section states plainly that compatibility is per protocol and that query-side coverage is narrower than ingestion, and the table it presents is cut off mid-row in the material available here. That truncation matters: the exact list of what is not compatible is the single most decision-relevant table in the document, and it is the one I cannot fully read. Anyone evaluating this should open the compatibility section in the repository rather than rely on a summary. The asymmetry is understandable (accepting a write format is cheaper than reproducing a query language) but it is also where migration surprises live. The README does not claim drop-in query compatibility, and it should not be read as claiming it.

Disaggregated compute and storage, and what sits on the local disk

The architecture is disaggregated: object storage holds the data, while memory and local-disk caches keep recent and frequently queried data close to compute. Supported primary storage includes S3, GCS, Azure Blob, and S3-compatible endpoints. That list is worth checking against your own infrastructure before anything else, because object storage is primary storage here, not a tiering target. If your data lives somewhere not on that list, the deployment model does not apply. The cache layer is the part that determines query latency for recent data, and the README does not give sizing guidance for it in the material available. Built-in features include retention policies, downsampling, continuous aggregation, explicit table partitioning, and inverted, skipping and fulltext indexes. Continuous aggregation is the mechanism that keeps long retention affordable: you store raw data at low cost on object storage and keep aggregated tables for the queries that run often. Downsampling and retention policies are configured per table, which means the retention design is something you author rather than something the system infers.

Getting a standalone instance running

The README points to a Try GreptimeDB section and a Getting Started section, and documents building from source. The primary language is Rust, and the project publishes images to Docker Hub under greptime/greptimedb, which the README links via its Docker pulls badge. The release channels are defined in the README itself: stable is for production, canary includes pre-releases, and nightly is a weekly snapshot of main. That distinction is not cosmetic. The most recent stable release listed is v1.2.0, with v1.3.0-alpha.1 and a nightly build of v1.3.0-alpha.1 appearing alongside it. If you are evaluating for production, v1.2.0 is the release the README's own channel definition points you at, and the v1.3.0 artifacts are pre-release or nightly builds. Configuration keys, storage options and deployment commands live in the user guide's configuration and deployment sections rather than in the README, so the README alone is not enough to stand up a cluster. Treat the README as the map and the user guide as the instructions.

The edition boundary, and the limitation the README names itself

The README has a section titled Limitations and Edition Boundary, and it states that the core is Apache-2.0 licensed while describing an edition boundary. That phrasing implies functionality split between an open core and something else, and the README does not enumerate the split in the material available here. This is the first thing to resolve before a serious evaluation, because it determines whether the feature you need is in the build you can compile yourself. A second limitation follows from the architecture: object storage as primary storage means every query that misses the caches pays an object-store round trip. The README presents memory and local-disk caches as the mitigation, not as an elimination of that cost. A third is the query-side compatibility gap already described. And a fourth is that this is a database you operate. The README's own framing of the alternative (not wanting the Thanos or Mimir operational surface) applies equally to GreptimeDB: you are trading one operational surface for another, and the distributed engine is the part that has to be run.

Compared with keeping Prometheus and adding a long-term store

The obvious alternative is the stack the README names as the thing you have outgrown: Prometheus for recent metrics plus Thanos or Mimir for long-term storage, with Loki or Elasticsearch alongside for logs. The difference in approach is where the join happens. In that stack, each signal keeps its own query language and its own storage engine, and correlation is a cross-system operation. In GreptimeDB, one engine holds all three and correlation is SQL over shared columns. The trade is that you give up the maturity and the exact query semantics of the tools you already know. PromQL support here is a reimplementation, not the Prometheus engine, and the README's own compatibility caveat tells you to expect differences. For logs specifically, the alternative of staying on Elasticsearch keeps the query DSL and the ecosystem around it; GreptimeDB accepts Elasticsearch Bulk writes but does not claim to answer Elasticsearch queries. That is the honest shape of the choice: broader ingest compatibility, narrower query compatibility, one engine instead of three.

Maintenance cost and licence position

Maintenance cost has two components visible in the material. The first is release cadence: stable, canary and nightly channels, with nightly builds cut weekly from main. Following nightly means following a moving target; staying on stable means waiting for v1.3.0 to leave alpha. The second is operational: object storage is primary storage, so your backup, lifecycle and access-control policies for that bucket become part of the database's correctness story, and the caches need sizing. The licence is Apache-2.0 for the core, per the README and the repository metadata, with the edition boundary described above sitting alongside it. I am not in a position to give legal advice on what that boundary means for a commercial deployment, and the README does not spell it out in the material available. If the split matters to your organisation, read the licence files and the edition documentation in the repository directly, and get your own advice on the open-core terms before you build a service on it.

Editorial conclusion

Adopt GreptimeDB if you already run Prometheus plus Loki or Elasticsearch and want one backend, or if Prometheus cardinality or retention is the constraint and you do not want the Thanos or Mimir operational surface. Do not adopt it if your query path depends on a Prometheus-compatible HTTP API or on Elasticsearch query DSL, since the README places query-side compatibility below ingest-side compatibility. Before committing, verify three things: which edition the build you are evaluating corresponds to, whether your specific PromQL expressions and trace queries are covered, and whether your object store appears in the supported storage list.

Official sources

1. GreptimeTeam/greptimedb on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases