Cloud Parts

GreptimeDB

A Rust database that stores metrics, logs and traces as tables on object storage, queried with SQL or PromQL.

What it is
Time-series databases
Used for
Observability
Type
Open source
Made by
GrepTime Inc.
License
Apache 2.0 (core); a few enterprise-only features under the GreptimeDB Enterprise License, not built by default
Facts checked
6 October 2026
Website Source code

What it is

GreptimeDB runs as one binary for development or as a cluster of four kinds of process. Frontends are stateless: they accept OpenTelemetry (OTLP), Prometheus remote write, Loki push, Elasticsearch bulk, InfluxDB line protocol, gRPC and the MySQL and PostgreSQL wire protocols, then plan queries and route reads and writes. Metasrv keeps the catalog and the map of which Datanode hosts which region (a slice of a table), backed by etcd or a relational database. Datanodes hold the regions: each write goes to a write-ahead log and an in-memory table (memtable), which is flushed as Parquet files to S3, Google Cloud Storage, Azure Blob or local disk, with memory and local-disk caches for recent data. The WAL can be local (an embedded raft-engine) or remote in Kafka, which is what makes fast failover and moving regions between nodes possible. An optional Flownode runs continuous aggregations into other tables.

Every signal is a table with tag columns (the primary key), one time-index column and field columns: a Prometheus metric becomes a table with its labels as tags, OpenTelemetry logs and spans land in opentelemetry_logs and opentelemetry_traces, and SQL can join them on trace_id. The core is Apache 2.0, including cluster mode, object storage and every ingestion protocol. GrepTime Inc. sells GreptimeDB Enterprise, which adds read replicas, automatic rebalancing, LDAP, RBAC and audit logging, either fully managed from $290 a month or deployed in your own cloud at custom prices. Version 1.0 shipped in April 2026; the current release is 1.2.1.

Why teams pick it

  • One engine and one SQL dialect for metrics, logs and traces, so you can join a slow span to the log lines it produced
  • Drop-in ingestion for existing agents: OpenTelemetry, Prometheus remote write, Loki push, Elasticsearch bulk and InfluxDB line protocol
  • Object storage is the primary store, so long retention costs bucket prices and compute scales separately from data
  • PromQL for dashboards and alerts that already exist, plus SQL over the same data through MySQL or PostgreSQL clients
  • Cluster mode, object storage and continuous aggregation (Flow) are all in the Apache 2.0 build

Watch out for

  • Open core: read replicas, automatic repartitioning and region rebalancing, LDAP, RBAC, audit logging and Kibana-style Elasticsearch queries are Enterprise only; in the open build, repartitioning and region migration are manual
  • Query compatibility is narrower than ingestion: Loki’s LogQL and most Elasticsearch APIs aren’t supported, and PromQL has documented gaps
  • Fast failover needs Kafka as a remote WAL; with the local WAL, recovery means replaying the log and regions can’t move to other nodes
  • Young as a 1.x product: GA only in April 2026, and 1.2.0 shipped a compaction bug that could lose JSON2 data, fixed in 1.2.1
  • The self-serve Hobby and Serverless cloud plans of 2024 are gone from the pricing page; managed service now starts at $290 a month

Alternatives

What all time-series databases have in common →
Amazon TimestreamAWSAWS’s time-series databases: a serverless engine now closed to new customers, and managed InfluxDB 2 and 3.Apache IoTDBOpen sourceAn Apache time-series database for industrial IoT that stores everything in its own open file format, TsFile, and lets you model devices as a tree of paths or as SQL tables.+1 TimechoDBArcOpen sourceA young single-binary time-series database in Go that writes incoming data as Parquet files and queries them with DuckDB SQL.ArcticDBCommercialMan Group’s serverless DataFrame database: a Python library with a C++ engine that stores versioned pandas DataFrames directly in S3, Azure Blob Storage or local LMDB.InfluxDBOpen sourceThe best-known time-series database, fed by line protocol and Telegraf; now in its third generation, a Rust rewrite that keeps data as Parquet files on object storage.kdb+CommercialA columnar time-series database that is also an interpreter for q, an array language, used for market data across trading and risk.QuestDBOpen sourceA columnar time-series database in Java, C++ and Rust that ingests millions of rows a second and answers time-series SQL, with old partitions kept as Parquet.TDengineOpen sourceA clustered time-series database for IoT and industrial data that gives every device its own table, grouped under “supertables” with tags.TimescaleDBOpen sourceA PostgreSQL extension that turns ordinary tables into time-partitioned, compressed time-series tables.Workers Analytics EngineCommercialCloudflare’s time-series analytics store for Workers: a non-blocking `writeDataPoint()` call to record events with unlimited cardinality, adaptive sampling to keep it cheap, and a SQL API to query them.

How it fits with other technologies

A metrics table, a downsampling flow, and PromQL from SQL · sql

-- tags form the primary key; one time index; fields hold the values
CREATE TABLE cpu (
  host STRING,
  region STRING,
  usage_pct DOUBLE,
  ts TIMESTAMP TIME INDEX,
  PRIMARY KEY (host, region)
) WITH ('ttl' = '30d');

-- keep 5-minute peaks per region; Flow creates and updates cpu_5m
CREATE FLOW cpu_5m_flow
SINK TO cpu_5m
AS
SELECT region, max(usage_pct) AS peak_pct,
  date_bin('5 minutes'::INTERVAL, ts) AS time_window
FROM cpu
GROUP BY region, time_window;

-- a metric written by Prometheus remote write, queried with PromQL
TQL EVAL (1759730400, 1759734000, '1m')
  sum by (job) (rate(http_requests_total[5m]));

GreptimeDB, Prometheus or TimescaleDB?#

All three store time-stamped data, but they start from different places: GreptimeDB from object storage and several signal types, Prometheus from scraping metrics, TimescaleDB from PostgreSQL.

GreptimeDBPrometheusTimescaleDB
What it storesMetrics, logs and traces, each signal in its own tablesMetrics onlyAny PostgreSQL rows; hypertables split them into time chunks
Where the data livesObject storage (S3, GCS, Azure Blob) or local disk, with local cachesLocal disk on one server, not clustered or replicatedPostgreSQL’s own disks
How data gets inOTLP, Prometheus remote write, Loki push, Elasticsearch bulk, InfluxDB line protocol, SQL insertsPulls (scrapes) HTTP /metrics endpointsOrdinary PostgreSQL inserts
Query languagesSQL and PromQLPromQLSQL
LicenceApache 2.0 core; some features Enterprise onlyApache 2.0Apache 2.0 core; most features under the Tiger Data License
  • The two can be combined: Prometheus can keep scraping and send its samples to GreptimeDB with remote_write, using it as long-term storage, and read them back with remote_read.

Open source and Enterprise#

The same database in each column; Enterprise adds operations, security and support features and a commercial licence. Prices are list prices checked on 2026-10-06.

FeatureOpen sourceEnterprise, your cloudEnterprise, fully managed
Who runs itYouYou, with GrepTime support (also on AWS Marketplace)GrepTime
PriceFreeCustomFrom $290 a month
Cluster mode, object storage, Flow, all ingestion protocolsYesYesYes
Read replicas, automatic region rebalancing, scheduled compactionNoYesYes
LDAP login, RBAC, audit logging, protection against `DROP`NoYesYes
Elasticsearch query compatibility (Kibana), triggers with webhooksNoYesYes
Active-active disaster recoveryNoYesYes
  • Enterprise-only source files carry the GreptimeDB Enterprise License header and sit behind the enterprise Cargo feature, which the default build leaves out.

See it in a real stack

No architecture uses GreptimeDB yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2022–2026

Most of Greptime’s founding team had spent four years building a proprietary time-series database at a major tech company, which at peak wrote more than 100 million data points a second. Storage costs kept growing, and they had seen the cost of running metrics, logs and traces in three siloed systems: when something broke, the logs and traces behind a metric spike lived somewhere else. Existing architectures also kept several copies of the data on over-provisioned clusters, and handling high-cardinality series at a reasonable cost was still unsolved.

Founder and CEO Dennis Zhuang announced GreptimeDB on November 15, 2022, when the GitHub repository went public after about six months of work. It was a cloud-native time-series database written in Rust, with stateless frontends and Datanodes and cheap object storage such as S3 underneath. Version 0.4 in October 2023 replaced the first row-oriented storage engine with a columnar one, Mito2, which made scans several times faster.

The project then widened from metrics to logs and traces in one table model, and reached 1.0 in April 2026. In June 2026 GrepTime added a separate Enterprise License for its feature-gated code, keeping the core under Apache 2.0.

Why it’s built this way

Rust instead of Go or Java
The team wanted precise memory control and stable latency under heavy write load. Co-founder Jeremy Feng wrote that at the storage-engine level “a single GC pause can mean a latency spike”, which they considered unacceptable.
Object storage underneath, with local caches
Separating storage from compute lets data live on commodity object storage while compute scales elastically; local disks keep hot data close to avoid object-store latency.
Rewriting the storage engine as columnar
The original row-oriented memtable duplicated keys and tags for every row and inflated memory. Incremental fixes couldn’t solve a data-layout problem, so version 0.4 rebuilt it around series and columnar files.
One table model for all three signals
Metrics, logs and traces are all timestamped events with context. Storing them as tables with shared tags lets one SQL query correlate them instead of jumping between three systems.

Timeline

  1. 2022

    GreptimeDB open-sourced on GitHub on November 15

  2. 2023

    First release, 0.1.0, in March

  3. 2023

    0.4 in October replaces the storage engine with columnar Mito2

  4. 2026

    Version 1.0 GA in April

  5. 2026

    Enterprise License for gated code in June; 1.2 adds JSON2 in September

Sources18 · facts checked 6 October 2026

Improve this page on GitHub