What it is

GreptimeDB is an open-source observability database built on a single columnar engine that stores metrics, logs, and traces together. It lives in the cloud-native infrastructure and operations ecosystem, written in Rust and licensed under Apache-2.0. All three signal types share one table model composed of tags, a timestamp, and fields, so when signals carry common identifiers such as service, host, or trace ID, they can be correlated in SQL without moving data between separate databases. Compute and storage are disaggregated: object storage holds the data while memory and local-disk caches keep recent and frequently queried data close to compute.

The concrete problem it solves is backend sprawl. Teams commonly run Prometheus alongside Loki or Elasticsearch, maintaining three systems with three query languages and three operational surfaces. GreptimeDB replaces that arrangement with one backend that ingests through OpenTelemetry, Prometheus Remote Write, Loki Push, or Elasticsearch Bulk, and queries through SQL, PromQL, and Jaeger-compatible trace queries. It also targets teams that have outgrown Prometheus on cardinality or retention but do not want the Thanos or Mimir operational surface, and teams that need long retention on object storage without standing up a separate analytics stack.

Key capabilities

• Ingests OpenTelemetry (OTLP), Prometheus Remote Write, Loki Push, Elasticsearch Bulk, InfluxDB line protocol, and gRPC.
• Queries with SQL, PromQL, and Jaeger-compatible trace queries, plus MySQL and PostgreSQL wire protocols.
• Uses S3, GCS, Azure Blob, and S3-compatible endpoints as primary storage, with memory and local-disk caches.
• Provides retention policies, downsampling, continuous aggregation, and explicit table partitioning.
• Ships inverted, skipping, and fulltext indexes for data management.
• Correlates metrics, logs, and traces in SQL when signals share identifiers such as service, host, or trace ID.
• Runs the same engine and semantics on resource-constrained devices.

Who uses it and how

• Teams running Prometheus plus Loki or Elasticsearch consolidate onto one backend instead of three.
• Operators who have outgrown Prometheus on cardinality or retention migrate without adopting the Thanos or Mimir operational surface.
• Users needing long retention on object storage query telemetry with SQL rather than only a domain query language.
• Teams storing GenAI or agent telemetry under OTel GenAI conventions place it alongside infrastructure signals.
• Deployments on resource-constrained devices use the same engine and semantics as larger installations.

Getting started

The README points to a Try GreptimeDB section, a Getting Started guide, and a Build From Source path, with stable, canary, and nightly release channels. The homepage at greptime.com/product/db is listed as the product entry point.

When to use it — and when not to

Compatibility is per protocol, and query-side coverage is narrower than ingestion, so migration happens one signal at a time rather than all at once. A self-hoster must operate object storage as primary storage plus memory and local-disk caches, and should expect the limitations and edition boundary the README documents. The project lists commercial support separately, which signals that some needs fall outside the Apache-2.0 core.