GreptimeDB

Definition

GreptimeDB is an open-source, distributed time-series database written in Rust that stores metrics, logs, and events in a single unified engine. It is designed for cloud-native and edge deployments where observability data must be ingested at high throughput, retained cheaply over long windows, and queried with both SQL and PromQL. GreptimeDB separates compute from storage so it can scale horizontally on object storage such as S3, distinguishing it from single-node time-series databases built around a fixed local disk layout.

Overview

Time-series workloads generate enormous volumes of small, timestamped writes, and most general-purpose databases struggle to ingest and compact that data efficiently once retention windows stretch into months or years. GreptimeDB addresses this by building a storage engine specifically around time-partitioned, columnar data, so writes land in append-friendly segments that are later compacted and compressed the way a log-structured merge tree handles keys, rather than the way a row store handles arbitrary updates. Mechanically, GreptimeDB ingests data through multiple protocols, including line protocol compatible with InfluxDB, OpenTelemetry metrics, and Prometheus remote write, and stores it in a columnar format that separates tags, timestamps, and fields for efficient scanning. A metadata layer tracks table and region placement across nodes, letting the system split large tables into regions that can be moved, compacted, or queried independently. Object storage backing means compute nodes can be added or removed without re-balancing raw disk data, since the underlying files already live in shared storage. Among its neighbors, GreptimeDB sits between narrowly scoped metrics stores like Prometheus and broader observability backends like a combined logs-metrics-traces platform. Unlike Prometheus, which is optimized for short-term local retention and pull-based scraping, GreptimeDB targets long-term storage and can ingest push-based data from many sources at once. Compared with general column stores such as ClickHouse, GreptimeDB bakes time-partitioning and downsampling into its core model rather than requiring the operator to design that behavior manually. In practice, teams deploy GreptimeDB as a long-term metrics backend behind Prometheus or Grafana Agent, using its PromQL compatibility so existing dashboards and alerting rules continue to work without rewriting queries. Some teams also route log and metric data through the same cluster to reduce the number of storage systems they operate, querying both with SQL when correlation across signal types is needed. Its Rust implementation and small footprint make it a candidate for edge or IoT deployments where a full observability stack would be too heavy. The trade-offs are typical of a newer distributed system: the operator tooling, ecosystem integrations, and community track record are smaller than those of long-established projects like Prometheus or InfluxDB, so teams adopting it take on more operational risk during early rollout. Very small, single-node monitoring setups may find GreptimeDB's distributed architecture unnecessary overhead compared to a simple local Prometheus instance. Organizations already deeply invested in an existing time-series stack should weigh migration cost against the storage savings and unified query model GreptimeDB offers before switching.

Key Features

• Unified storage engine for metrics, logs, and events in one system
• Separates compute from storage to scale independently on object storage
• Supports PromQL and SQL query interfaces against the same tables
• Ingests via InfluxDB line protocol, Prometheus remote write, and OpenTelemetry
• Time-partitioned columnar storage designed for compaction and downsampling
• Written in Rust for a small memory and CPU footprint
• Distributed metadata layer for splitting tables into movable regions

Use Cases

Alternatives

Frequently Asked Questions

Related in Database