GreptimeDB

Single table model for three signals Metrics, logs, and traces share one schema of tags, timestamps, and fields, so operators correlate signals in one SQL query when they carry common identifiers. Modelling stays telemetry-shaped; it is not a general document store.[1][2]

Multi-protocol ingestion without rebuilding collectors Existing OpenTelemetry SDKs, Prometheus remote-write agents, Loki shippers, and Elasticsearch Bulk senders keep working, which shortens migration from a split stack. Collector configuration and pipeline tuning remain the operator's job.[1][2]

SQL plus PromQL with familiar wire protocols Telemetry is queried in SQL and metrics in PromQL, and MySQL and PostgreSQL wire-protocol compatibility lets standard clients and Grafana connect directly. Teams still need fluency in at least one of the two query languages.[1][2]

Object storage as primary storage Recent data and long retention are served by the same engine on S3-compatible storage with columnar compression. Retention length stays configurable, so unbounded cardinality can still raise the bill.[1][2]

Flow engine for derived metrics Raw events can produce metrics on demand or materialize them continuously, avoiding a separate stream-processing job for routine rollups. Complex transformations beyond documented Flow semantics still need external processing.[1]

Grafana datasource plugin and built-in dashboard Dashboards, visualization, and alerting integrate with existing Grafana workflows rather than requiring a new frontend. Alerting depth follows what the Grafana integration exposes.[1][2]

Standalone binary or Kubernetes cluster A single-process binary covers evaluation and small deployments on Linux, Windows, and macOS, while an operator and Helm charts scale out production clusters. High availability and upgrades are cluster-mode concerns.[1][2]

Jaeger-compatible traces with flexible indexing Trace data migrates through documented paths, with skipping indexes for high-cardinality span IDs and bloom-filter full-text search for logs instead of indexing every field. Ad-hoc text search stays narrower than a search engine's inverted index.[1][2]

Platform teams merging three telemetry backends: one engine, one table model, and one query path replace separate scaling and failure models, which matters most where on-call engineers context-switch across systems during incidents.[1][2]

Operators keeping years of telemetry: object-storage-backed retention with columnar compression fits compliance and historical analysis without funding a second analytics stack, provided cardinality is governed.[1][2]

IoT and edge-to-cloud pipelines: standard-protocol ingestion accepts high-volume device telemetry from existing collectors into a central store built for timestamped data.[1][2]

Teams without Kubernetes or database operations capacity: production clustering, retention tuning, and upgrades expect platform engineering skills a small team may not have.[1]

Buyers needing single sign-on on the free tier: LDAP authentication and dedicated account support are enterprise-tier features, so identity or SLA requirements force a paid conversation.[1][2]

Text-search-first log investigation: inverted-index search engines remain stronger for ad-hoc full-text retrieval across unstructured logs than a columnar observability store.[1]