Introduction

Kubernetes, service meshes, and serverless functions generate a torrent of metrics, logs, and traces. The data is not only huge—it carries billions of unique label combinations such as trace_id, user_id, or pod_uid. Conventional TSDBs struggle to keep pace. GreptimeDB addresses this gap with a cloud-native, horizontally-scalable architecture that digests PB-scale telemetry while still returning queries in sub-second latency.

Architecture Built for Scale

Challenge	GreptimeDB Design Choice	Source
Evenly spread writes/reads across a fleet	Distributed tables with user-defined PARTITION ON COLUMNS, e.g. region or namespace, preventing “hot shards”	Practical Guide §Step 6
Minimise network & disk churn from updates	Merge modes (last_row, last_non_null) update only the deltas—ideal for metrics that change every scrape but keep many fields constant	Practical Guide §Step 5
Retain months of data without runway costs	Tiered storage: hot blocks on SSD, cold blocks in S3/GCS (≈3-5× cheaper than EBS)	Storage Deep Dive
Cut long-term volume	TTL + down-sampling jobs executed by Flow tasks, rolling second-level samples into minute-level aggregates	Practical Guide – Performance Tips

With these features, operators routinely keep > 12 months of metrics at one-tenth the cost of block storage alone (Storage Deep Dive).

-- Example: 3-way partitioned service metrics table
CREATE TABLE svc_metrics (
  region      STRING,
  cluster     STRING,
  service     STRING,
  p99_latency DOUBLE,
  error_rate  DOUBLE,
  ts          TIMESTAMP,
  PRIMARY KEY(region, cluster, service),
  TIME INDEX(ts)
) PARTITION ON COLUMNS(region) (
  region='us-east-1',  -- adds shards only where traffic lives
  region='eu-central-1',
  region='ap-southeast-2'
) WITH ('merge_mode'='last_non_null');

Cloud-Native Observability Features

1. Query freedom – Engineers can use plain SQL for ad-hoc analytics or PromQL for familiar dashboarding. 2. Multimodal storage – The same table engine ingests raw logs through the Pipeline engine, numerics from Prometheus remote-write, and JSON traces, enabling one-shot correlation queries. 3. Turn-key Kubernetes ops – GreptimeDB Operator installs a full stack—database, Vector sidecars, and Grafana—via a single Helm value. Enabling monitoring.enabled=true turns on self-monitoring without extra Loki/Jaeger clusters.

Real-World Pattern: Global API Monitoring

A SaaS provider tracks billions of calls per day:

• Schema – Wide-row table api_metrics with low-cardinality composite key (region, service, endpoint) for efficient grouping.
• Indexes – INVERTED on status_code for quick 4xx/5xx filtering; SKIPPING on trace_id for rare drill-downs (Practical Guide §Step 3).
• Partitioning – Region-based shards keep P99 latency queries local to where the traffic occurred, cutting cross-AZ egress. The result: 95th-percentile query latency under 800 ms on 900 TB of compressed Parquet (Vendor case file, internal benchmark).

Operational Tips (from Field Notes)

• Start append-only ('append_mode'='true') for log tables; add primary keys later if you need updates.
• Watch table size – shard once a single partition nears 500 GB to avoid long compaction stalls.
• Reserve headroom – leave ~50 % CPU/RAM for queries after meeting peak ingest (Practical Guide – Performance Tips).

Conclusion

GreptimeDB merges a write-optimized storage core with cloud-native primitives—object storage, Kubernetes Operator, unified SQL/PromQL—to deliver scalable observability for the most demanding micro-service fleets. Whether you store terabytes a day of Prometheus metrics or join petabytes of JSON logs with trace metadata, GreptimeDB supplies the elastic scale, cost control, and analytical horsepower required for today’s cloud-native workloads.

---

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.

⭐ GitHub | 🌐 Website | 📚 Docs

💬 Slack | 🐦 Twitter | 💼 LinkedIn