
Introduction
Today’s micro-service and IoT applications spew out millions of log lines and metric samples every second. Operators must spot anomalies while they are still unfolding, not hours later. GreptimeDB was built precisely for this task: it combines a write-optimized storage engine, multi-modal query layer, and cloud-native architecture so that teams can both ingest and query telemetry data in real time.
A Unified Platform for Multi-Modal Telemetry
Unlike traditional stacks that keep metrics in Prometheus, logs in Elasticsearch, and traces in Jaeger, GreptimeDB stores metrics, logs, traces, and events in one logical database. Converging those data types unlocks powerful cross-modal questions, for example:
-- Correlate 5xx spikes with error keywords
SELECT time_bucket('5 minutes', ts) AS window,
count_if(status_code >= 500) AS errors,
count(*) AS total_req,
matches(message, 'timeout|panic') AS suspected_cause
FROM api_logs
WHERE service = 'checkout'
GROUP BY window
ORDER BY window DESC
LIMIT 24;
A single SQL query above joins log keywords, HTTP status codes, and time buckets without moving data between systems (Source: “A Practical Guide to Observability Data Modeling with GreptimeDB”).
Schema & Indexing Best Practices
GreptimeDB exposes three index types—inverted, skipping, and full-text—that can be mixed and matched to achieve millisecond-level scans even on TB-scale tables:
Goal | Recommended Feature | KB Source |
---|---|---|
Filter quickly on low-cardinality tags (region , http_status ) | INVERTED INDEX | Practical Guide |
Point lookup on very high-cardinality IDs (user_id , trace_id ) | SKIPPING INDEX | Practical Guide |
Keyword search in raw log lines | FULLTEXT INDEX | Pipeline Engine / v0.9 Blog |
Compile those guidelines into a wide-table layout whenever logs or metrics are collected together; this boosts compression by 30–50 % and eliminates joins at query time (Source: Practical Guide).
CREATE TABLE node_telemetry (
host STRING,
cpu_user DOUBLE,
cpu_system DOUBLE,
log_level STRING INVERTED INDEX,
raw_message STRING FULLTEXT INDEX WITH(analyzer='English'),
ts TIMESTAMP TIME INDEX,
PRIMARY KEY(host)
) WITH ('append_mode'='true');
With append_mode=true
GreptimeDB skips primary-key checks, increasing write throughput by roughly 30 % in log-heavy workloads.
Performance-Driven Storage Architecture
GreptimeDB’s storage layer resembles an OS page cache:
- Write Cache keeps the most recent hours on fast local SSD, enabling sub-millisecond inserts.
- Read Cache uses an LRU policy to pin recently accessed Parquet pages, shielding queries from high-latency cloud object storage.
- Metadata & Index Cache holds table schema and per-shard routing info entirely in memory.
Because cold data finally resides in S3-compatible object stores—3-5× cheaper than block volumes—operators can retain months of telemetry without ballooning budget (Source: “Storage Architecture Deep Dive – JSONBench Top Ranking”). The same tiered design recently propelled GreptimeDB to #1 in the 1-billion-JSON cold run of ClickHouse JSONBench, proving the layout scales from gigabytes to petabytes.
Real-Time Log Parsing with the Pipeline Engine
If raw application logs arrive as gigantic strings, GreptimeDB’s Pipeline engine (introduced in v0.9) lets you dissect them at ingestion time and cast columns to efficient types:
processors:
- dissect:
fields: [line]
patterns:
- '%{ip} [%{ts}] "%{method} %{path}" %{status} %{size}'
- date:
fields: [ts]
formats: ["%d/%b/%Y:%H:%M:%S %Z"]
transform:
- fields: [status, size]
type: int32
index: ts
Parsing up-front yields two wins: dramatically smaller on-disk footprint (columnar compression) and ultra-fast filtering on status codes or IP addresses (Source: “Pipeline Engine for Logs”).
Visualising Telemetry in Grafana
GreptimeDB ships a Grafana data source plugin that speaks SQL and PromQL. Dashboards can mix line charts of CPU usage with tables of the exact error messages that triggered an alert—without context-switching between Loki and Prometheus panels.
Tip: When running GreptimeDB on Kubernetes, the official Helm chart can deploy Grafana, GreptimeDB, and a Vector sidecar for log shipping in a single command, providing an out-of-the-box observability stack.
Operational Guidance
- Start simple: prototype with append-only tables, no indexes; add indexes only after observing real query patterns.
- Partition strategically: once a table exceeds ~500 GB, split by low-cardinality columns such as
region
to prevent “hot shards.” - Down-sample: schedule Flow tasks to roll up second-level metrics into minute-level summaries, cutting storage by up to 90 % while preserving trend fidelity.
Conclusion
GreptimeDB collapses the once fragmented observability stack into a single high-performance engine. From 30 % faster ingestion via append-only mode, to sub-second queries over petabyte-scale JSON, to native Grafana dashboards that blend metrics and logs, the database delivers true real-time analytics for 21st-century workloads. Whether you are tracing micro-services, monitoring an edge fleet, or operating a global SaaS, GreptimeDB turns raw telemetry into actionable insight—before an outage turns into a headline.
About Greptime
GreptimeDB is an open-source, cloud-native database purpose-built for real-time observability. Built in Rust and optimized for cloud-native environments, it provides unified storage and processing for metrics, logs, and traces—delivering sub-second insights from edge to cloud —at any scale.
GreptimeDB OSS – The open-sourced database for small to medium-scale observability and IoT use cases, ideal for personal projects or dev/test environments.
GreptimeDB Enterprise – A robust observability database with enhanced security, high availability, and enterprise-grade support.
GreptimeCloud – A fully managed, serverless DBaaS with elastic scaling and zero operational overhead. Built for teams that need speed, flexibility, and ease of use out of the box.
🚀 We’re open to contributors—get started with issues labeled good first issue and connect with our community.