登录

greptimedb

GreptimeTeamApache-2.0活跃维护

开源可观测性数据库，用一套列式引擎在对象存储上统一存储指标、日志和链路追踪，支持高基数场景，兼容 Prometheus 和 OpenTelemetry。

The open-source observability database. One columnar engine for metrics, logs, and traces, on object storage.

v1.3.0发布于 2026-10-28 11:22 UTC6,800star +7 / 7 天580fork同步于 2026-11-10 17:34 UTC
可观测性数据库列式引擎指标日志链路对象存储高基数
对比 GitHub 官网ai-agentscloud-nativedistributed-databasegreptimedbhigh-cardinality

怎么上手

由 README 提炼，执行前请确认
原文 
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
硬件要求按 README 说明

README 未说明显存或 GPU 要求；提供 Docker 镜像与源码编译方式，未提及 CPU 架构限制。

有 Docker 镜像
下载：源码 zip·GitHub Releases（安装包）本站不镜像安装包

项目说明

由 README 自动翻译提炼
没人工点评？写下你的经验

开源可观测性数据库，用一套列式引擎在对象存储上统一存指标、日志和链路

开源可观测性数据库，用一套列式引擎在对象存储上统一存储指标、日志和链路追踪，支持高基数场景，兼容 Prometheus 和 OpenTelemetry。

核心能力

  • 指标、日志、链路共用 tags+timestamp+fields 表模型
  • 用 SQL 跨信号 join，按 trace_id 关联日志与 span
  • 支持 OTLP、Prometheus Remote Write、Loki Push、ES Bulk 写入
  • 提供 SQL 与 PromQL 双查询，兼容 MySQL/PostgreSQL 协议
  • S3/GCS/Azure Blob 作主存储，内置保留策略与降采样

容易踩的坑

源码编译需 Protobuf 编译器 >= 3.15 及 gcc/g++/autoconf 等 C/C++ 构建依赖；部分企业功能需开启 enterprise Cargo feature，默认不编译；Dashboard 在 4000 端口的 /dashboard 路径下，不是根路径。

内容由模型根据 README 生成，可能不完整或不准确，以官方文档为准。看原文 README

最近发版

5 个版本v1.3.0
全部 release
  1. v1.4.0-nightly-20261109Release v1.4.0-nightly-20261109pre-release2026-11-09 · 2026-11-09 03:33 UTC
    查看更新说明

    What's Changed

  2. v1.3.0-nightly-20261102Release v1.3.0-nightly-20261102pre-release2026-11-02 · 2026-11-02 11:58 UTC
    查看更新说明

    Full Changelog: https://github.com/GreptimeTeam/greptimedb/compare/v1.3.0...v1.3.0-nightly-20261102

  3. v1.3.0Release v1.3.0最新正式版2026-10-28 · 2026-10-28 11:22 UTC

    v1.3.0

    Release date: October 28, 2026

    GreptimeDB v1.3.0 adds native histogram ingestion, a semantic entity graph over metrics and traces, an opt-in trace schema with JSON2 attributes, and automatic retries for distributed writes. It also fixes incorrect SQL and PromQL results, write routing during schema changes, and storage recovery failures.

    👍 Highlights

    Ingest native histograms without experimental switches

    Prometheus Remote Write v2 native histograms and cumulative OTLP/HTTP exponential histograms are accepted by default. PromQL can query native histograms, including quantiles and fractions. Remote Write v1 native histograms, native histogram Remote Read, and OTel Arrow exponential histograms remain unsupported. (#9301, #8758, #8874)

    Trace V2: JSON2 attributes with Jaeger and semantic entity graph support

    The opt-in greptime_trace_v2 pipeline stores span, scope, and resource attributes in three JSON2 columns instead of adding a SQL column for every attribute. Its 19-column schema also preserves span events and links as JSON arrays. Jaeger queries and semantic entity graph derivation support the new model.

    Select greptime_trace_v2 with the x-greptime-pipeline-name header on OTLP trace ingestion requests. Use a separate destination table from Trace V1. After ingesting into a table named traces_v2, query typed attributes directly:

    SELECT
    trace_id,
    span_attributes."http.status_code"::BIGINT AS http_status,
    resource_attributes."service.name"::STRING AS service_name
FROM traces_v2;

    Existing Trace V1 tables are not automatically migrated. Events and links use JSON in this release; ARRAY(JSON2) is deferred. See #9192, #9232, #9257, and #9278.

    Semantic entity graph (experimental)

    Semantic entity graph is experimental. Future releases may introduce breaking changes.

    GreptimeDB derives an entity graph of services, hosts, containers, and Kubernetes objects from metrics and traces at query time, using built-in conventions for OpenTelemetry, Prometheus, and Kubernetes data. Query it with SQL through greptime_private.semantic_entities and greptime_private.semantic_relationships. information_schema.table_semantics shows what each table contributes to the graph, and ALTER TABLE ... SET/UNSET adjusts a table’s semantic options. GreptimeDB MCP Server v0.6.0 and later lets AI agents query the graph through query_semantic_graph and find tables by concept through search_table_semantics.

    See #8614, #8854, #8880, #8904, #8936.

    Retry distributed writes without replaying successful entries

    Frontends retry transient distributed write failures up to three times by default, refreshing routes when regions move or partitions change. Per-datanode batches remain intact, and partial-failure responses let the frontend retry failed entries without replaying acknowledged successes. Whole-RPC failures can still have an uncertain outcome. Retries do not provide exactly-once ingestion. (#9542, #9543, #9728, [#9720](https://github.com/GreptimeTeam/greptim

  4. v1.4.0-nightly-20261028Release v1.4.0-nightly-20261028pre-release2026-10-28 · 2026-10-28 03:02 UTC
    查看更新说明

    What's Changed

  5. v1.4.0-nightly-20261022Release v1.4.0-nightly-20261022pre-release2026-10-22 · 2026-10-22 03:03 UTC
    查看更新说明

    What's Changed

用户点评

登录用户的真实使用记录，可按版本和硬件筛选
共 0 条

    还没有人点评。第一个说出真实体验的人最有价值。

    README 原文

    未翻译
    在 GitHub 打开

    User Guide  ·  API Docs  ·  Live Demo  ·  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.

    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
    Or skip the install and try the Live Demo.

    Next: Quickstart, the full Install Guide, Demo Scenes, and the FAQ.

    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

    IngestOpenTelemetry (OTLP), Prometheus Remote Write (with native histograms over Remote Write 2.0), Loki Push, Elasticsearch Bulk, InfluxDB line protocol, gRPC
    QuerySQL, PromQL, Jaeger-compatible trace queries, MySQL and PostgreSQL wire protocols
    StorageS3, GCS, Azure Blob and S3-compatible endpoints as primary storage, with memory and local-disk caches
    Built inPipelines that parse and transform logs at ingestion, 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

    Compatibility and Migration

    Compatibility is per protocol, and query-side coverage is narrower than ingestion.

    CompatibleNot compatible
    PrometheusRemote Write ingestion; PromQL queriesGaps are listed in PromQL compatibility
    LokiPush ingestion; dual-write through Grafana Alloy makes the cutover gradualLogQL and the rest of the Loki query API
    Elasticsearch_bulk ingestion in the open-source core; QueryDSL partially, in EnterpriseMost 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 and region migration 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. For GreptimeDB Enterprise inquiries, contact us.

    Architecture

    GreptimeDB can run in two modes:

    • Standalone — single binary for development and small deployments.
    • Distributed — four components, each independently scalable:
      • Frontend — protocol endpoints and the distributed query engine. Stateless, scales horizontally.
      • Datanode — region engine with WAL, memtable, SST, cache, compaction, and indexes. Persists data to object storage.
      • Metasrv — metadata, region routing, and cluster coordination (DDL procedures, failover, region migration, repartitioning). 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.

    Build From Source

    Prerequisites:

    • Rust toolchain — stable, pinned by rust-toolchain.toml
    • Protobuf compiler (>= 3.15)
    • C/C++ building essentials: gcc / g++ / autoconf and the glibc dev package (libc6-dev on Ubuntu, glibc-devel on 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

    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.

    Releases follow Semantic Versioning. For where the project is going, read the v1.0 highlights, the 2026 roadmap, and what we mean by an observability database.

    Community

    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.

    Contributing

    Integration CI Codecov

    Acknowledgement

    Special thanks to all contributors! See AUTHOR.md.

    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.

    相关项目

    同分类里 star 最高的项目
    对比全部 →
    ECC
    affaan-m·JavaScript

    为 Claude Code、Codex、Cursor 等编码智能体提供技能、直觉、记忆与安全防护的性能优化层，让 AI 编程助手更稳定高效地干活。

    智能体框架+4Agent 框架
    300641+191444kv2.2.32026-11-09 04:56 UTC
    deepseek-harness
    deepseek-ai·TypeScript

    DeepSeek 开源的 Agent 编排框架，把模型、工具、记忆等所有能力都做成可插拔插件，方便按需拼装和扩展智能体。

    Agent 框架+3Agent 框架
    278086+288634kdsh-v0.2.2-rc.12026-11-04 13:06 UTC
    hermes-agent
    NousResearch·Python

    一个可随使用不断成长的 AI Agent 框架，支持接入 Claude、ChatGPT 等多种大模型，用于搭建和编排自主智能体。

    Agent 框架+3Agent 框架
    262361+108159kv0.23.02026-11-10 17:13 UTC
    firecrawl
    firecrawl·TypeScript

    把任意网页抓取并转成干净 Markdown 或结构化数据，直接喂给 LLM 和 AI Agent，省去自己写爬虫和清洗的麻烦。

    网页抓取+4Agent 框架
    200422+108311kv2.11.02026-11-10 17:12 UTC