GreptimeDB

Three observability signals usually mean three backends, three query languages and no way to join across them. GreptimeDB puts metrics, logs and traces on a single columnar engine over object storage, sharing one table model of tags, timestamp and fields, so signals sharing a service, host or trace identifier correlate in SQL.

Compute and storage are disaggregated. Object storage on S3, GCS, Azure Blob or an S3-compatible endpoint holds the data, while memory and local disk caches keep recent and frequently queried rows near compute. A standalone binary suits development, and the distributed mode splits into frontend, datanode, metasrv and an optional flownode for streaming computation.

Migration can move one signal at a time rather than all at once.

• Ingestion: OpenTelemetry, Prometheus Remote Write, Loki Push, Elasticsearch bulk, InfluxDB line protocol and gRPC.
• Query: SQL and PromQL, Jaeger-compatible trace queries, and the MySQL and PostgreSQL wire protocols.
• Built in: retention policies, downsampling, continuous aggregation, explicit table partitioning and inverted, skipping and fulltext indexes.
• Compatibility limits: LogQL and most Elasticsearch APIs are not covered, and PromQL has documented gaps.
• Edition boundary: read replicas, workload isolation and automated repartitioning belong to the commercial Enterprise build.

The Apache-2.0 core includes cluster deployment, object storage, the flow engine and every ingestion protocol listed above, though repartitioning, region migration and index creation are manual. A Docker image starts a standalone instance with a dashboard on port 4000, and building from source needs a nightly Rust toolchain, protobuf 3.15 or later and C and C++ build essentials.