GrepTimeDB

GrepTimeDB is a cloud-native, open-source time series database written in Rust. It provides a unified platform for storing and querying metrics, logs, and events — the three pillars of observability — with a familiar SQL interface and compatibility with popular protocols like Prometheus, InfluxDB line protocol, OpenTelemetry, and MySQL/PostgreSQL wire protocols.

Features

• Unified observability storage — store metrics, logs, and traces in a single system rather than running InfluxDB, Loki, and Jaeger separately
• SQL interface — query your time series data with standard SQL, including time-range predicates, aggregations, and window functions; no proprietary query language to learn
• Multiple ingestion protocols — accepts data via InfluxDB line protocol, OpenTelemetry, Prometheus remote write, MySQL protocol, PostgreSQL protocol, and a native gRPC API
• Cloud-native architecture — separates storage (object storage: S3, GCS, Azure Blob) from compute, enabling elastic scaling and low operational cost
• Distributed mode — scale out across multiple nodes for high availability and horizontal throughput scaling
• Standalone mode — run as a single binary for development, edge, or small-scale deployments
• Prometheus compatible — act as a Prometheus remote write target and run PromQL queries against stored data
• Flow engine — built-in continuous aggregation for computing real-time rollups and materialised summaries as data arrives
• Written in Rust — memory safety and high performance without a JVM or garbage collector

Installation

Binary

Download a pre-built binary from the releases page:

# macOS (Apple Silicon)
curl -L https://github.com/GreptimeTeam/greptimedb/releases/latest/download/greptime-darwin-arm64.tar.gz | tar xz
./greptime standalone start

# Linux (x86_64)
curl -L https://github.com/GreptimeTeam/greptimedb/releases/latest/download/greptime-linux-amd64.tar.gz | tar xz
./greptime standalone start

Docker

docker pull greptime/greptimedb:latest

# Start in standalone mode
docker run -p 4000-4003:4000-4003 \
  -v $(pwd)/greptimedb_data:/tmp/greptimedb \
  greptime/greptimedb:latest \
  standalone start

Homebrew (macOS)

brew tap greptimeteam/greptime
brew install greptimedb
greptime standalone start

Debian / Fedora

No official apt or dnf package is available. Use the pre-built Linux binary from the releases page:

# Debian / Ubuntu / Fedora — pre-built Linux binary (x86_64)
curl -L https://github.com/GreptimeTeam/greptimedb/releases/latest/download/greptime-linux-amd64.tar.gz | tar xz
./greptime standalone start

Or use Docker, which works on all Linux distributions:

# Debian / Fedora — Docker (works on all Linux distributions)
docker pull greptime/greptimedb:latest
docker run -p 4000-4003:4000-4003 \
  -v $(pwd)/greptimedb_data:/tmp/greptimedb \
  greptime/greptimedb:latest \
  standalone start

Starting the server

# Standalone mode — everything in one process, data stored locally
greptime standalone start

# With custom data directory and config
greptime standalone start \
  --data-home /var/lib/greptimedb \
  --config-file /etc/greptimedb/config.toml

# Distributed mode — start frontend, datanode, and metasrv separately
greptime metasrv start
greptime datanode start --node-id 1 --metasrv-addr 127.0.0.1:3002
greptime frontend start --metasrv-addr 127.0.0.1:3002

Once running, the following endpoints are available:

Querying with SQL

Connect with any MySQL or PostgreSQL client:

# Via MySQL client
mysql -h 127.0.0.1 -P 4002 -u greptime public

# Via psql
psql -h 127.0.0.1 -p 4003 -U greptime -d public

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

-- Insert data
INSERT INTO host_metrics VALUES
  ('web-01', 42.5, 68.3, NOW()),
  ('web-02', 38.1, 72.0, NOW());

-- Query the last hour of data
SELECT host, AVG(cpu_usage) AS avg_cpu
FROM host_metrics
WHERE ts >= NOW() - INTERVAL '1 hour'
GROUP BY host
ORDER BY avg_cpu DESC;

-- Time-bucket aggregation (5-minute averages)
SELECT
    date_bin('5 minutes', ts) AS bucket,
    host,
    AVG(cpu_usage) AS avg_cpu
FROM host_metrics
WHERE ts >= NOW() - INTERVAL '24 hours'
GROUP BY bucket, host
ORDER BY bucket;

Prometheus integration

GrepTimeDB can act as a Prometheus remote write target:

# prometheus.yml
remote_write:
  - url: http://localhost:4000/v1/prometheus/write

remote_read:
  - url: http://localhost:4000/v1/prometheus/read

Run PromQL queries against stored data:

# Query via HTTP
curl 'http://localhost:4000/v1/prometheus/api/v1/query_range' \
  --data 'query=rate(http_requests_total[5m])' \
  --data 'start=2024-01-01T00:00:00Z' \
  --data 'end=2024-01-01T01:00:00Z' \
  --data 'step=60'

InfluxDB line protocol ingestion

# Write data using InfluxDB line protocol
curl -X POST 'http://localhost:4000/v1/influxdb/write?db=public' \
  --data-binary 'cpu_usage,host=web-01 value=42.5 1704067200000000000
cpu_usage,host=web-02 value=38.1 1704067200000000000'

OpenTelemetry ingestion

GrepTimeDB accepts OTLP (OpenTelemetry Protocol) for metrics and logs:

# otel-collector-config.yaml
exporters:
  otlphttp/greptimedb:
    endpoint: http://localhost:4000/v1/otlp

service:
  pipelines:
    metrics:
      exporters: [otlphttp/greptimedb]
    logs:
      exporters: [otlphttp/greptimedb]

Flow engine (continuous aggregation)

Define streaming aggregations that compute automatically as data arrives:

-- Create a summary table for pre-aggregated 1-minute averages
CREATE TABLE cpu_1m (
    host     STRING,
    avg_cpu  DOUBLE,
    ts       TIMESTAMP TIME INDEX,
    PRIMARY KEY (host)
);

-- Define a flow that continuously populates the summary
CREATE FLOW cpu_summary
SINK TO cpu_1m
AS
SELECT
    host,
    AVG(cpu_usage) AS avg_cpu,
    date_bin('1 minute', ts) AS ts
FROM host_metrics
GROUP BY host, date_bin('1 minute', ts);

Why GrepTimeDB?

Running separate systems for metrics (InfluxDB/Prometheus), logs (Loki/Elasticsearch), and traces (Tempo/Jaeger) means separate operational overhead, separate query languages, and no easy way to correlate across them. GrepTimeDB provides a single system with a single query language (SQL) for all three, at cloud-native cost thanks to object storage as the primary persistence layer.