Integrate GreptimeDB with your preferred technology stack
Installation Guide
Learn more
Metrics, logs, traces, and wide events in one database. OpenTelemetry-native ingestion, SQL + PromQL query, Flow engine for continuous aggregation and metric derivation. One system replaces Prometheus + Loki + Elasticsearch.
Compute-storage disaggregation architecture with object storage (S3, Azure Blob, GCS) as primary. Scale storage and compute independently. Pay for what you use — no over-provisioning.
PromQL-compatible for existing Prometheus dashboards and alerts. Loki Push API and Elasticsearch bulk API for log ingestion. Jaeger Query API for trace visualization. Grafana datasource, MySQL/PostgreSQL wire protocol. Migrate without rewriting.
Built with Rust on Apache Arrow and DataFusion. Rich indexing (inverted, fulltext, skipping) enables sub-second queries on petabyte-scale datasets. Handles high-dimensional, high-cardinality observability events.
Designed for Kubernetes. Stateless compute nodes scale horizontally — add nodes to scale, remove without data loss. No Thanos-style sidecar complexity.
Deploy on ARM-based edge devices or cloud clusters with identical APIs. Bandwidth-efficient sync between edge and cloud. One binary, from a Raspberry Pi to a 100-node cluster.
Quick answers to common questions about GreptimeDB.
In published benchmarks, GreptimeDB writes about 2× faster than InfluxDB and 2.17× faster than TimescaleDB, with time-range queries up to 67× faster and storage as low as 1/18 the size on the same dataset. For logs, ingestion runs 1.5× faster than Loki and queries 40 to 500× faster; storage lands around 50% of ClickHouse and 12.7% of Elasticsearch. Methodology and full numbers are in the benchmark reports and compare pages.
Yes. GreptimeDB takes data through OpenTelemetry OTLP, Prometheus Remote Write, Loki Push, Elasticsearch Bulk, and Jaeger Query APIs, and stores all three signals in the same columnar engine. You query everything with SQL or PromQL, so a single query can join metrics and logs without ETL. The data model is wide events. For details, read Why GreptimeDB and the Integrations Overview.
No. The open-source build ships the full distributed system: cluster deployment, object storage, the Flow engine for continuous aggregation, and every ingestion and query protocol. Enterprise adds operational and scaling features (5× bulk ingestion, auto repartition, read replicas, LDAP/RBAC, the management console, 24/7 support), but the core engine and APIs are the same. See the feature comparison.
GreptimeDB runs as a single-binary standalone (Linux, macOS, ARM edge devices, Raspberry Pi) or as a Kubernetes cluster with stateless compute and storage on object stores. The same binary handles a Raspberry Pi or a 100-node cluster, and edge nodes sync to cloud clusters over the same APIs. For production storage use S3, GCS, or Azure Blob; for cluster metadata use etcd, MySQL, or PostgreSQL. Setup steps are in the installation guide.
Per-protocol setup: Ingest Data.
Li Auto runs GreptimeDB on-vehicle across its EV production fleet to capture raw telemetry at the edge and save tens of millions in cloud bandwidth costs (case study). OceanBase Cloud runs 80+ GreptimeDB clusters carrying 300TB+ of logs and SQL audit data, with storage cost down by over 60% after migrating off Grafana Loki (case study). Other industries with public deployments: e-commerce observability, AI infrastructure, industrial IoT. More in Use Cases.
Enterprise clustering and professional support
Fully-managed cloud service with auto-optimization
Specialized automotive and IoT integration
Stay in the loop
Get the latest updates and discuss with other users.
