GreptimeDB
Unify metrics, logs, and traces in one columnar engine running on your own infrastructure.
The evidence explains ingestion protocols, query interfaces, component topology, object storage, and workflows that publish documentation or update another repository. Checkout credential persistence is disabled, the Helm update is manually dispatched with scoped permissions, and Git dependencies are revision-pinned. Deductions apply because there is no Agent-facing permission manifest, per-action confirmation policy, data classification, or credential-handling specification. The quick start exposes four service ports and mounts writable storage, while the external SKILL.md is neither revision-pinned nor visible here. A security policy and TLS dependencies provide only partial sensitive-data and supply-chain assurance; Actions use mutable version tags and no dependency-audit evidence is supplied. Atomic replacement tests and gradual dual-write migration offer limited recovery evidence, but no comprehensive database rollback or disaster-recovery procedure is shown. Project, author, and upstream attribution are visible, although publisher identity remains unknown.
The README, Cargo workspace, and supplied tests are broadly consistent about versions, platform validation, configuration updates, and compatibility-version management. Tests cover invalid inputs, missing files, HTTP failures, architecture mismatch, and idempotent updates. Deductions apply because this static review cannot establish that tests pass or that the service behaves as described; Docker latest, external documentation, registries, the GitHub API, object stores, and many third-party dependencies remain availability factors. The README gives only basic startup and connectivity troubleshooting. Tests expect explicit exceptions, but the evidence does not show consistent actionable failure messages across the database or an Agent workflow.
The documentation thoroughly identifies scenarios including Prometheus/Loki/Elasticsearch migration, long retention, constrained devices, GenAI telemetry, and standalone or distributed deployment. It also states protocol gaps, open-source versus enterprise boundaries, manual operational tasks, and optional components, supporting high scores for scenarios and capability boundaries. Environment coverage includes several object stores, protocols, deployment modes, and build prerequisites, but the shown development-image validation covers only Linux amd64/arm64, and resource requirements and broader OS constraints are absent. No actual Agent trigger, invocation-selection rule, or locally reviewable Agent instruction is provided; the README merely directs an Agent to an external SKILL.md, so trigger precision scores zero.
The README is well structured and supplies a Docker quick start, source-build prerequisites, common development commands, FAQ, architecture, compatibility, release channels, limitations, community, and support paths. The Apache-2.0 core license is present in full, and the separate enterprise boundary is explicitly described, justifying full scores for licensing, installation, information architecture, examples, and limitations. Deductions apply because stable/canary/nightly conventions and workspace versioning are clear, but latest, main, and nightly references are mutable. Releases, version references, and roadmaps are linked, yet no complete revision-local changelog is supplied. Contribution, security-reporting, community, and commercial-support routes exist, but the publisher is unverified and no named maintainer accountability or response commitment is shown.
Combining metrics, logs, and traces behind shared ingestion and SQL/PromQL querying offers clear marginal value for operators otherwise maintaining several observability backends. Protocol tables, architecture material, a dashboard, and client compatibility make ordinary database outputs usable. Deductions apply because there is no structured Agent-output contract, success definition, or result-quality guarantee. Cost-benefit claims are supported at an asserted level by backend consolidation, object-storage retention, and a cited storage-cost case, but the benchmark and case-study claims are project-linked rather than independently evidenced here, and operating resources, migration cost, enterprise pricing, and Agent execution cost are not quantified.
Core capabilities are traceable to the README and receive some cross-source support from Cargo components, the license, the security policy, and tests for platform checks, atomic configuration updates, and version-window maintenance. Compatibility and edition sections distinguish supported and unsupported behavior. Deductions apply because performance, production scale, cost reduction, GA status, and stable-API claims rely on external benchmark, case-study, or release pages not included in the supplied evidence and therefore cannot be independently checked here. The documentation generally separates compatibility facts and edition boundaries, but some promotional conclusions omit methods, raw data, and uncertainty.
- The Agent entry point tells users to fetch and follow an external SKILL.md whose contents and pinned revision are absent from the evidence; review and pin it separately before use.
- The quick start maps four ports and mounts a writable data directory. Restrict network exposure, filesystem permissions, and object-store credentials before use outside an isolated local environment.
- Do not make a production choice solely from the README's performance, scale, and cost case claims; validate them independently against the intended workload, retention, and object-storage setup.
- Repartitioning, region migration, and index creation are manual in the open-source edition, and the supplied material does not document comprehensive rollback or disaster recovery.
- The dependency surface is large and includes several Git-revision dependencies plus GitHub Actions referenced by version tags; audit the lockfile, licenses, vulnerabilities, and workflow provenance before deployment.
What does this agent do, and when should you use it?
GreptimeDB is an open-source columnar observability database that stores metrics, logs, and traces on object storage under a shared table model of tags, timestamps, and fields. It ingests OpenTelemetry OTLP, Prometheus Remote Write, Loki Push, Elasticsearch Bulk, InfluxDB line protocol, and gRPC, while exposing SQL, PromQL, Jaeger-compatible queries, and MySQL/PostgreSQL wire protocols. It can run as a standalone binary or as a distributed system composed of Frontend, Datanode, Metasrv, and an optional Flownode; compute is separated from storage, with memory and local disk serving as caches. The open-source build includes clustering, object storage, the Flow engine, retention, downsampling, continuous aggregation, explicit partitioning, and several index types, although repartitioning, region migration, and index creation remain manual. It is a credible fit for teams consolidating telemetry backends, extending retention, or correlating signals with SQL, provided they can accept the documented query-compatibility gaps and enterprise feature boundary.
Telemetry enters through Frontend endpoints for OpenTelemetry, Prometheus Remote Write, Loki Push, Elasticsearch Bulk, InfluxDB, gRPC, or supported database wire protocols. Frontend handles protocol access and distributed queries; Datanode processes regions with a WAL, memtable, SSTs, caches, compaction, and indexes, then persists data to S3, GCS, Azure Blob, or S3-compatible storage. Metasrv manages metadata, routing, repartitioning, and security over a pluggable etcd or RDS key-value layer. The optional Flownode performs continuous flow computation and materialized-view processing. Users can then correlate metrics, logs, and traces with SQL, query metrics through PromQL, issue Jaeger-compatible trace queries, and apply retention, downsampling, or continuous aggregation.
- A platform team running Prometheus alongside Loki or Elasticsearch that wants one telemetry backend instead of operating separate stores.
- An SRE team exceeding Prometheus cardinality or retention limits that wants object-storage retention without adopting the full Thanos or Mimir operational surface.
- An observability team that needs to correlate metrics, logs, and traces in SQL using shared service, host, or trace identifiers.
- An organization planning a gradual migration that wants to move one signal at a time while retaining Prometheus Remote Write, Loki Push, or Elasticsearch Bulk ingestion.
- A team storing GenAI or agent telemetry based on OTel GenAI conventions alongside infrastructure signals.
- A self-hosting user who wants to start with one standalone binary and retain a path to a disaggregated distributed cluster.
What are this agent's strengths and limitations?
- A single columnar engine and table model handles metrics, logs, and traces, allowing SQL correlation through common identifiers without moving data between databases.
- OTLP, Prometheus Remote Write, Loki Push, Elasticsearch Bulk, InfluxDB line protocol, and gRPC provide practical paths for signal-by-signal migration without rebuilding collectors.
- Object storage is primary storage, compute and storage are disaggregated, and memory plus local-disk caches keep recent or frequently queried data near compute.
- Deployment can begin with one standalone binary and grow into independently scalable Frontend, Datanode, Metasrv, and Flownode components.
- The Apache-2.0 core includes clustering, object storage, the Flow engine, retention, downsampling, continuous aggregation, explicit partitioning, and multiple index types.
- Protocol compatibility is incomplete: PromQL has documented gaps, while Loki support covers Push ingestion but excludes LogQL and the rest of the query API.
- The open-source core supports Elasticsearch
_bulkingestion, but partial QueryDSL support is an Enterprise feature and most other Elasticsearch APIs are unsupported. - Repartitioning, region migration, and index creation are manual in the Apache-2.0 edition; read replicas, workload isolation, and automated repartitioning require Enterprise.
- A distributed deployment introduces Frontend, Datanode, Metasrv, optional Flownode, object storage, and an etcd or RDS key-value layer, creating a larger operational footprint than standalone mode.
- Building from source requires a pinned nightly Rust toolchain, Protobuf, and native C/C++ build dependencies.
How do you install or deploy this agent?
The shortest documented path requires Docker and a writable local data directory. Run:
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:4003This exposes HTTP on 4000, gRPC on 4001, MySQL on 4002, and PostgreSQL on 4003, with data persisted in greptimedb_data under the current directory. No credentials are required by this local example. A source build requires the repository-pinned Rust nightly toolchain, Protobuf compiler 3.15 or newer, and C/C++ build prerequisites including gcc, g++, autoconf, and glibc development files; run make, followed by cargo run -- standalone start.
How do you use this agent?
After the container starts, open http://localhost:4000/dashboard to verify the service. Configure collectors to send data through the appropriate OpenTelemetry OTLP, Prometheus Remote Write, Loki Push, Elasticsearch Bulk, InfluxDB line protocol, or gRPC endpoint; the supplied local example does not specify protocol-level write requests or authentication settings. Query the stored telemetry with SQL, PromQL, Jaeger-compatible trace queries, or clients using the MySQL and PostgreSQL wire protocols. If connections fail, verify that ports 4000 through 4003 are not blocked or already occupied. If startup fails, inspect the container with docker logs greptime.
How does this agent compare with similar options?
Compared with operating Prometheus plus Loki or Elasticsearch, GreptimeDB consolidates all three telemetry types into one columnar engine and table model, with SQL available across signals. It is positioned for Prometheus users facing cardinality or retention pressure who want to avoid the broader Thanos or Mimir operational surface, but its PromQL coverage has gaps. Loki migration can be gradual through Push ingestion and Grafana Alloy dual-writing, yet LogQL is unavailable. Open-source Elasticsearch compatibility is centered on _bulk ingestion, so it should not be treated as a complete Elasticsearch replacement.
FAQ
Are distributed clusters and object storage included in the open-source edition?
Which capabilities require GreptimeDB Enterprise?
Can existing Loki, Prometheus, or Elasticsearch clients assume complete API compatibility?
_bulk but not most other Elasticsearch APIs.What should I check if the local container fails to start or accept connections?
docker logs greptime.