discord9
4e024452fe
* fix(query): match the whole operand instead of copying matchers A native binary must report what Prometheus reports: when one side holds two series under one matching label set, the query fails with "found duplicate series for the match group ... on the right hand-side". The legacy route answers a value instead, because `matching_filters::propagate` copies the matcher into the other operand's scan and the groups without a partner are dropped before the join - its own documentation says that hides the duplicate. This branch had started applying that rewrite to native operands as well, and had refused multi-selector trees over partitioned tables in process to force the hybrid topology back. Both kept a legacy behaviour the native route does not need: a native binary reads independent raw sources and checks the whole one-side groups itself. Drop the rewrite for native operands, and keep the refusal only for several scans of one partitioned table, whose node cannot run inside a region. The partitioned acceptance case now asserts the duplicate error and that the pair really runs as one native binary; the legacy value stays in the test as the contrast that documents the difference. Signed-off-by: discord9 <discord9@163.com> * test(promql): assert the native binary, not the hybrid join The hybrid cases were written when a cross-table pair over a partitioned table could only run as two region-local producers joined on the frontend. The pair now runs as one native binary over independent raw sources, so those shape assertions describe a topology that no longer exists: two fused nodes, a frontend join, direct region scans under it and a projection above it. Assert what the native plan actually promises instead: the binary is one fused node with more than one input, every operand reads its own source, and the duplicate-group and value assertions stay as they are. The per-scan-partition value check now applies to operand producers only - a matching binary routes by label set, so an input partition may contribute nothing to a given output one. Signed-off-by: discord9 <discord9@163.com> * test(promql): keep the operand metrics for a native binary The per-scan-partition value check ran over every fused node, which now means the binary itself: it routes by label set, so an output partition may legitimately hold nothing from a given input partition. Check the two operand metrics instead - the same assertion the unpartitioned pair already makes - so each operand still proves it registered its values on every partition it reads. Signed-off-by: discord9 <discord9@163.com> * feat(query): admit multi-selector trees the native binary can match Three refusals were left over from when a multi-selector tree could only run inside one region over bare scans, and each of them now only costs coverage: - The aggregate split and the segmentation were admission authority: a tree that needed placement and did not fit the single-selector split fell back, even though each selector occurrence can read its own raw source and the consumer can run above the collection. They are optimizations now. - `multi_input` meant "the metric logical ids differ", so ordinary tables, repeated selectors and mixed engines were treated as a single input. It now means what the code needs: more than one independent input, one per selector occurrence, each bound to its own source. - Several scans of one partitioned table were refused in process. That node cannot run inside a region, but the same tree has a frontend placement over per-occurrence raw sources, so only the cross-table refusal that keeps the hybrid route is left. Tests that asserted the fallback now assert the native plan and the per-source inputs; the value, label and duplicate-group assertions are unchanged, and the shapes the compiler genuinely cannot express stay refused. Signed-off-by: discord9 <discord9@163.com> * fix(query): keep the raw sources under an in-process cut A table partitioned on a column that is not a tag splits one series across regions. When such a tree is cut into segments in process, the cut could fall back to the bare scan, and then a per-region prefix evaluated a window over one region's fragments: `rate` never saw the samples the other region holds, so a window that straddles the boundary produced no value at all. Remote execution already kept the raw source under the cut; in process the flag said otherwise. Pass the boundary fact that matters - the cut must keep each source when the table is split into regions - so the evaluated segment runs the prefix above the reconciliation. An unpartitioned table's scans are whole in one region, so its cuts keep the bare-scan form and the two-aggregate pairs still plan as one execution. The regression puts the two samples of one series on either side of a time-partition boundary and compares the native answer with the existing plan's for a two- and a three-selector window; without this change both lose the value. Signed-off-by: discord9 <discord9@163.com> * test(promql): prove the window runs natively The time-boundary regression compared rows with the existing plan, which a fallback also satisfies. Require a fused node in the frontend tree as well, so the test fails if the planner quietly declines the shape. Signed-off-by: discord9 <discord9@163.com> * test(query): trim redundant gates and assertions A review of this branch found duplications rather than missing coverage: two identical metric-name gates, a `!multi_input` term that now implies its own `selector.len() == 1` partner, a duplicate aggregate-admission test, a redundant cooperative-decorator special case, a tautological region-input assertion, an exact-child-type assertion that pins an intermediate shape, and a window regression that accepted a region-side fused node as proof of frontend admission. Remove them; the behaviour assertions stay. Signed-off-by: discord9 <discord9@163.com> * test(promql): require the native binary for a partitioned pair The values equal the legacy route's, so a legacy frontend join reading the same regions could satisfy the assertions on their own. Require the fused node in the frontend tree as well, and drop a duplicated rustdoc paragraph. Signed-off-by: discord9 <discord9@163.com> * fix(query): drop the stale unconditional canonical refusal A rebase left both the old refusal (`any_partitioned && contains_canonical_merge`) and the transport-scoped one, so the older block declined every canonical merge over a partitioned table on the wire and the acceptance case fell back to the existing planner. Keep the scoped refusal only. Signed-off-by: discord9 <discord9@163.com> --------- Signed-off-by: discord9 <discord9@163.com>
Metrics, logs, and traces.
One engine, on your infrastructure.
A columnar database for metrics, logs, and traces on object storage. Apache-2.0 licensed core.
User Guide · API Docs · Roadmap 2026 · Slack
stable for production · canary includes pre-releases · nightly is a weekly snapshot of main
Introduction
GreptimeDB is an open-source observability database. Metrics, logs, and traces run on one columnar engine over object storage and share one table model: tags, timestamp, and fields. When signals carry common identifiers such as service, host, or trace ID, you can correlate them in SQL without moving data between databases.
Ingest through OpenTelemetry, Prometheus Remote Write, Loki Push, or Elasticsearch Bulk. Use SQL across observability data and PromQL for metrics. Migrate ingestion one signal at a time without rebuilding your collectors.
One Query Across Signals
OpenTelemetry ingestion writes spans to opentelemetry_traces and log records to
opentelemetry_logs. Both tables carry trace_id, so correlating them is a join:
-- The slowest failed spans in the last hour,
-- with the log lines emitted inside those same traces.
SELECT
t.service_name,
t.span_name,
t.duration_nano / 1000000 AS duration_ms,
l.timestamp AS log_time,
l.severity_text,
l.body
FROM opentelemetry_traces t
JOIN opentelemetry_logs l ON l.trace_id = t.trace_id
WHERE t.timestamp > now() - INTERVAL '1' HOUR
AND t.span_status_code = 'STATUS_CODE_ERROR'
ORDER BY t.duration_nano DESC
LIMIT 20;
Metrics join the same way, on any tag the tables share, such as service,
host, or pod.
Why You Might Use It
- You run Prometheus plus Loki or Elasticsearch and want one backend instead of three
- You have outgrown Prometheus on cardinality or retention and don't want the Thanos/Mimir operational surface
- You are hitting Loki's query performance limits as log volume grows
- You need long retention on object storage without a separate analytics stack
- You want to query telemetry with SQL, not only a domain query language
- You are storing GenAI or agent telemetry (OTel GenAI conventions) alongside infrastructure signals
Learn more in Why GreptimeDB.
What's Supported
| Ingest | OpenTelemetry (OTLP), Prometheus Remote Write, Loki Push, Elasticsearch Bulk, InfluxDB line protocol, gRPC |
| Query | SQL, PromQL, Jaeger-compatible trace queries, MySQL and PostgreSQL wire protocols |
| Storage | S3, GCS, Azure Blob and S3-compatible endpoints as primary storage, with memory and local-disk caches |
| Built in | Retention policies, downsampling, continuous aggregation, explicit table partitioning, and inverted / skipping / fulltext indexes |
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.
Benchmarks
- Agent RCA Bench: LLM agents doing root cause analysis over GreptimeDB versus Prometheus + Loki + Tempo. 40% fewer wrong diagnoses, 48% fewer input tokens, 45% lower cost (write-up)
- GreptimeDB tops JSONBench's billion-record cold run test
- TSBS Benchmark
- More benchmark reports
Compatibility and Migration
Compatibility is per protocol, and query-side coverage is narrower than ingestion.
| Compatible | Not compatible | |
|---|---|---|
| Prometheus | Remote Write ingestion; PromQL queries | Gaps are listed in PromQL compatibility |
| Loki | Push ingestion; dual-write through Grafana Alloy makes the cutover gradual | LogQL and the rest of the Loki query API |
| Elasticsearch | _bulk ingestion in the open-source core; QueryDSL partially, in Enterprise |
Most other Elasticsearch APIs |
Limitations and Edition Boundary
Cluster deployment, object storage, the Flow engine, and every ingestion protocol listed above are in the Apache-2.0 build. Repartitioning, region migration, and index creation are manual operations there.
Read replicas, workload isolation, and automated repartitioning are GreptimeDB Enterprise features, along with enterprise security and governance. The Enterprise overview has the current list, and pricing has the edition comparison.
Architecture
GreptimeDB can run in two modes:
- Standalone — single binary for development and small deployments.
- Distributed — four components, each independently scalable:
- Frontend — protocol entry (OTel, Prometheus, MySQL/PostgreSQL, gRPC, ingestion APIs for Elasticsearch/InfluxDB/Loki) and the distributed query engine. Stateless, scales horizontally.
- Datanode — region engine with WAL, memtable, SST, cache, compaction, and indexes. Persists data to object storage. Elastic.
- Metasrv — metadata, routing, repartitioning, and security. Backed by a pluggable KV layer (etcd or RDS).
- Flownode (optional) — continuous flow computation (streaming and materialized views).
For deeper coverage, see the architecture doc or DeepWiki.
Try GreptimeDB
For AI agents — paste this prompt into your agent:
Read https://docs.greptime.com/SKILL.md and follow the instructions
to deploy, configure, ingest, and query GreptimeDB.
docker run -p 127.0.0.1:4000-4003:4000-4003 \
-v "$(pwd)/greptimedb_data:/greptimedb_data" \
--name greptime --rm \
greptime/greptimedb:latest standalone start \
--http-addr 0.0.0.0:4000 \
--grpc-bind-addr 0.0.0.0:4001 \
--mysql-addr 0.0.0.0:4002 \
--postgres-addr 0.0.0.0:4003
Dashboard: http://localhost:4000/dashboard
Read more in the full Install Guide.
Troubleshooting:
- Cannot connect to the database? Ensure that ports
4000,4001,4002, and4003are not blocked by a firewall or used by other services. - Failed to start? Check the container logs with
docker logs greptimefor further details.
Getting Started
Build From Source
Prerequisites:
- Rust toolchain — stable, pinned by
rust-toolchain.toml - Protobuf compiler (>= 3.15)
- C/C++ building essentials:
gcc/g++/autoconfand the glibc dev package (libc6-devon Ubuntu,glibc-develon Fedora) - Python toolchain (optional, only for some test scripts)
Build and run:
make # build greptime binary
cargo run -- standalone start # start in standalone mode
Common dev commands:
make fmt # format Rust code
make clippy # lint (fails on warnings)
make test # unit + integration tests (uses cargo-nextest)
make sqlness-test # SQL regression tests
See the Contribution Guidelines for the full developer workflow.
Tools & Extensions
- Kubernetes: GreptimeDB Operator
- Helm Charts: Greptime Helm Charts
- Dashboard: Web UI
- gRPC Ingester: Go, Java, C++, Erlang, Rust, .NET, TypeScript
- Grafana Data Source: GreptimeDB Grafana data source plugin
- Grafana Dashboard: Official Dashboard for monitoring
Project Status
GreptimeDB is generally available, with stable APIs and regular releases. It runs in production at scale — OceanBase Cloud operates 80+ GreptimeDB clusters managing 300 TB of logs, cutting log storage cost by 60%+ after migrating from Grafana Loki. See more in case studies.
Release lines and support windows are in the version reference. For where the project is going, read the v1.0 highlights and the 2026 roadmap.
Community
We invite you to engage and contribute!
If GreptimeDB is useful to you, please star the repo.
License
GreptimeDB is an open-core project. Its core is licensed under the Apache License 2.0.
A small set of peripheral, enterprise-only features are gated behind the
enterprise Cargo feature (not built by default) and are governed by the
separate GreptimeDB Enterprise License. Source files under
that license carry an explicit Enterprise License header.
Commercial Support
Scaling observability on your infrastructure? GreptimeDB Enterprise adds the operational, security, and support layer for production deployments. Contact us for details.
Contributing
- Read our Contribution Guidelines.
- Explore Internal Concepts and DeepWiki.
- Pick up a good first issue and join the #contributors Slack channel.
Acknowledgement
Special thanks to all contributors! See AUTHOR.md.
- Uses Apache Arrow™ (memory model)
- Apache Parquet™ (file storage)
- Apache DataFusion™ (query engine)
- Apache OpenDAL™ (data access abstraction)
All trademarks, logos, and brand names referenced in this README and in the Overview diagram are the property of their respective owners. Their use is for identification purposes only and does not imply endorsement or affiliation.