GreptimeDB Unified Time-Series Database

You’re likely familiar with the "Observability Tooling Sprawl if you have the experience of managing production systems.
When you use Prometheus or VictoriaMetrics for metrics, Elasticsearch or Loki for logs, and Tempo or Jaeger for traces, even before you know it, you are running three distinct database clusters —each with its own query language, storage architecture, operational overhead, and cloud bill.

Unified Signals: Metrics, Logs, and Traces in One Engine

Historically, databases were optimized for either metric aggregations or full-text log search. Combining them usually meant sacrificing efficiency or write throughput.

GreptimeDB takes a different approach. It abstracts metrics, logs, and traces as Events consisting of:

• Timestamp (Time index)

• Context (Tags / Dimensions / Primary Key)

• Payload (Fields / Log body / Span attributes)

By supporting native OpenTelemetry ingestion (OTLP) directly into columnar Parquet-backed storage, GreptimeDB lets you run cross-signal queries. You can join a spike in application errors (logs) with CPU utilization (metrics) and latency metrics (traces) in a single database using familiar query tools.

One major friction point when adopting new infrastructure is learning proprietary query DSLs. GreptimeDB sidesteps this by supporting the standards developers already use:

Query/Protocol	Scenario
SQL	Analytical queries, ad-hoc reporting, and business intelligence (PostgreSQL & MySQL wire compatible).
PromQL	Native Prometheus query execution for existing Grafana dashboards and alerting rules.
Python	Execute analytical scripts directly inside the database cluster.
OTLP / Influx	Native ingestion endpoints for OpenTelemetry, Influx Line Protocol, and Prometheus remote write.

Getting Started in 60 Seconds

You can run a GreptimeDB instance locally using Docker:

Bash

docker run -p 4000-4003:4000-4003 \
  -p 4242:4242 \
  --name greptime \
  greptimedb/greptimedb standalone start

Once running, you can connect using a standard MySQL or PostgreSQL client:

SQL

-- Create a time-series metric table
CREATE TABLE host_metrics (
    host STRING,
    cpu DOUBLE,
    memory DOUBLE,
    ts TIMESTAMP TIME INDEX,
    PRIMARY KEY (host)
);

-- Insert sample points
INSERT INTO host_metrics(host, cpu, memory, ts) 
VALUES ('server-01', 0.45, 64.2, '2026-09-20 10:00:00');

-- Query using standard SQL
SELECT host, avg(cpu) 
FROM host_metrics 
WHERE ts >= NOW() - INTERVAL '1 HOUR' 
GROUP BY host;

Utilizing advanced vectorization and Massively Parallel Processing (MPP) via Apache DataFusion, GreptimeDB delivers extreme query speeds even on deeply nested JSON formats and cold data.

For anyone who has explored similar kind of unifying observability recently or is using GreptimeDB in their high-scale production systems, would love to hear about your experience!