cloudparts

Apache HoraeDBArchived

A distributed time-series database in Rust, started at Ant Group as CeresDB, that keeps recent writes in a WAL and memtable and flushes them as Parquet files to object storage.

What it is
Time-series databases
Used for
Metrics
Type
Open source
Made by
Ant Group (retired Apache Incubator podling)
License
Apache 2.0
Status
Archived since 3 March 2026
Facts checked
23 October 2026
Website Source code (archived)

What it is

HoraeDB began as CeresDB, the storage layer of Ant Group’s monitoring system, and aimed at both time-series and analytic workloads. Classic time-series databases build an inverted index on every tag, which gets expensive when a tag has very many distinct values. HoraeDB instead leaned on scanning and pruning, as analytic databases do: tables are stored sorted by primary key in Parquet files, each file keeps statistics such as minimum and maximum values, and queries skip files that can’t match. The SQL layer adds TAG columns and a timestamp KEY to an ordinary table definition, and planning and execution are delegated to Apache DataFusion, which is also how PromQL was implemented.

The storage engine, called Analytic, is a log-structured merge design. A write goes to a write-ahead log and an in-memory skiplist memtable; full memtables are flushed as Parquet SST files, split by a per-table segment_duration so each file covers one time segment, and a compactor merges small files with size-tiered or time-window strategies borrowed from Cassandra. The WAL lives in RocksDB on local disk for a single node, or in Kafka or OceanBase for a cluster; SST files go to the local file system or object storage. In cluster mode, HoraeMeta assigns shards (groups of tables) to HoraeDB nodes, with etcd underneath, and follower shards serve reads by replaying the WAL. Clients write over HTTP, gRPC or the MySQL protocol, and HoraeDB also accepts Prometheus remote write and read, the InfluxDB 1.8 write and query API, and OpenTSDB put.

Why teams pick it

  • Compute and storage are separate: SST files sit in object storage and the WAL in a shared service, so shards can move between nodes without copying data
  • No inverted index by default, so high-cardinality tags don’t blow up index size; filters prune Parquet files by their statistics instead
  • Speaks several existing protocols: Prometheus remote write and read, InfluxDB 1.8 line protocol and InfluxQL, OpenTSDB put, and MySQL clients
  • Apache 2.0 throughout, with the code, design documents and RFCs still readable in the archived repositories

Watch out for

  • Unmaintained: the podling retired in March 2026, the repositories are archived, and nobody ships fixes or security updates
  • The last release, 2.1.0 (November 2024), is the legacy Analytic engine; the main branch holds an unfinished rewrite, so building from source gives you neither
  • Its own docs said the Parquet-based SST format suited analytic queries better than typical time-series lookups
  • A highly available cluster needs Kafka or OceanBase for the WAL, etcd for HoraeMeta and an object store, which is many moving parts for one database

Specs

Compare with alternatives →
Data model
SQL tables with TAG columns and a timestamp key
Query language
SQL and PromQL, planned by Apache DataFusion
Client protocol
HTTP, gRPC and MySQL; Prometheus remote write, InfluxDB 1.8 and OpenTSDB put
How it scales
HoraeMeta assigns shards of tables to nodes
Replication
WAL in Kafka or OceanBase; follower shards replay it to serve reads
Storage engine
Analytic, an LSM design with a WAL and skiplist memtables
Storage format
Parquet SST files on local disk or object storage
Written in
Rust
Ways to run it
Self-hosted only; the project is archived

Alternatives, recommended first

What all time-series databases have in common →Compare side by side →
GreptimeDBOpen sourceA Rust database that stores metrics, logs and traces as tables on object storage, queried with SQL or PromQL.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.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.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.kdb+CommercialA columnar time-series database that is also an interpreter for q, an array language, used for market data across trading and risk.AkumuliArchivedOpen sourceA single-node C++ time-series database that keeps one compressed B+tree per series, with its own codecs for timestamps and floating-point values.

How it fits with other technologies

Create a table with a tag and a timestamp key, then write and read over HTTP · bash

docker run -d --name horaedb-server -p 8831:8831 -p 3307:3307 -p 5440:5440 apache/horaedb-server

curl -X POST 'http://127.0.0.1:5440/sql' -d '
CREATE TABLE `demo` (
  `name` string TAG,
  `value` double NOT NULL,
  `t` timestamp NOT NULL,
  timestamp KEY (t))
ENGINE=Analytic WITH (enable_ttl="false")'

curl -X POST 'http://127.0.0.1:5440/sql' -d '
INSERT INTO demo (t, name, value) VALUES (1702224000000, "horaedb", 100)'

curl -X POST 'http://127.0.0.1:5440/sql' -d 'SELECT * FROM `demo`'

See it in a real stack

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

A team at Ant Group started building the database in 2021 as the storage layer for the company’s monitoring system. They found that the popular time-series databases either lacked native clustering or struggled with high-cardinality tags, because the inverted index they build on every tag grows too costly. They chose Rust, built on Apache Arrow and DataFusion, and put data on object storage. The project went public on GitHub as CeresDB in June 2022 under Apache 2.0, and 1.0 followed in March 2023.

Because Ant Group wanted to keep the CeresDB brand, the open-source project was renamed HoraeDB in late 2023 and entered the Apache Incubator on 11 December 2023. Its ten initial committers came from Ant Group, Tencent, Greptime and Zhejiang University. Version 2.0.0 in April 2024 was the first under the new name and needed a migration from CeresDB settings; 2.1.0 in November 2024 was the last release.

In August 2024 the team wrote an RFC for a new engine aimed at metrics with hundreds of millions of series, with an index modelled on VictoriaMetrics’, and moved the old engine to an analytic-engine branch. The rewrite stayed unfinished. Commits thinned out through 2025, the podling missed its report to the Incubator, and in February 2026 the Incubator’s report said it was very likely to retire. It retired on 3 March 2026.

Why it’s built this way

Scan and prune instead of indexing every tag
Inverted indexes on high-cardinality tags were too costly to store and search in Ant Group’s workloads. Sorted columnar files with per-file statistics let queries skip data instead, the way analytic databases do.
A pluggable WAL and object storage underneath
Separating compute from storage was meant to make failover, load balancing and scaling simple: a shard can move to another node because its files and log live in shared services.
Build on DataFusion rather than write a query engine
DataFusion gave a SQL planner and executor that could be extended with custom operators, which is how PromQL was added.

Timeline

  1. 2021

    Development starts at Ant Group as CeresDB

  2. 2022

    CeresDB open-sourced on GitHub in June

  3. 2023

    Version 1.0 in March; renamed HoraeDB and enters the Apache Incubator in December

  4. 2024

    2.0.0 in April, RFC for a new metric engine in August, 2.1.0 in November

  5. 2026

    Retires from the Apache Incubator on 3 March; repositories archived

Sources10 · facts checked 23 October 2026

Improve this page on GitHub