cloudparts

ValkeyTimeSeriesPreview

A community module, written in Rust, that adds an in-memory time-series data type to Valkey with the TS.* commands of RedisTimeSeries plus Prometheus-style label queries, joins and anomaly detection.

Used for
Metrics
Type
Open source
Made by
Clayton Collie and contributors (opensource-for-valkey community)
License
Apache 2.0
Status
Preview. No tagged release yet; you build the module from source, and it is a community project, not an official Valkey module.
Facts checked
24 October 2026

What it is

ValkeyTimeSeries is loaded into a Valkey server with --loadmodule. Each time series is a key holding labels (name-value pairs) and a list of chunks: ordered, non-overlapping blocks of samples, each a 64-bit timestamp and a 64-bit float, stored compressed by default. TS.ADD and TS.MADD add samples, creating a series if needed; TS.RANGE and TS.MRANGE read a time range from one series or from every series whose labels match a filter, optionally aggregated into buckets; TS.CREATERULE keeps a downsampled series up to date as samples arrive. A retention period drops old samples, actively in the background rather than lazily on query. The command set is meant to be a superset of RedisTimeSeries, so its clients, such as @valkey/time-series, the node-valkey client’s copy of node-redis’s RedisTimeSeries package, send the same commands.

Its additions go beyond RedisTimeSeries: compaction rules can chain (minutes to hours to days), filters accept Prometheus series selectors such as latency{region=~"us-west-*"}, TS.JOIN joins two series on timestamp, including as-of joins within a tolerance, TS.OUTLIERS flags anomalies with z-score, IQR, MAD or random cut forest, and metadata commands list label names, values and cardinality. Label lookups use an inverted index: an adaptive radix tree from each label pair to a Roaring bitmap of series IDs. Queries and batched inserts run in parallel across series and chunks, and identical label strings are stored once. It works in standalone or cluster mode, where related series should share a hash tag so a query stays on one node.

Why teams pick it

  • Keeps recent metrics in memory next to the rest of an application’s Valkey data, with no extra database to run
  • Speaks the RedisTimeSeries API, so existing clients and code can move from Redis to Valkey
  • Adds Prometheus-style selectors, chained downsampling, joins and anomaly detection on the server
  • Apache 2.0, written in Rust, with parallel queries and batched inserts across series and chunks

Watch out for

  • Not yet released: no tagged versions, a small contributor base, and it is not part of the official valkey-io project
  • Data lives in memory: all retained samples must fit in RAM, so it suits recent, hot data, not years of history
  • Cross-series queries in cluster mode work well only if related keys share hash tags

Good for

Data model
Series keys with labels and compressed chunks of timestamp and float samples
Query language
TS.* commands (a RedisTimeSeries superset) with Prometheus-style selectors
Secondary indexes
Inverted label index: an adaptive radix tree to Roaring bitmaps
How it scales
Standalone or Valkey cluster; related series share a hash tag
Storage engine
In memory, inside Valkey
Retention
Per series, dropped in the background; chained downsampling rules
Written in
Rust
Ways to run it
A module loaded into a Valkey server

Alternatives

What all time-series databases have in common →Compare side by side →
InfluxDBOpen sourceAlso good for high-cardinality time seriesThe 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.PrometheusOpen sourceThe standard open-source metrics system: it pulls numbers from your services over HTTP, stores them as labelled time series and alerts on PromQL queries.TimescaleDBOpen sourceAlso good for high-cardinality time seriesA PostgreSQL extension that turns ordinary tables into time-partitioned, compressed time-series tables.Amazon TimestreamAWSAlso good for high-cardinality time seriesAWS’s time-series databases: a serverless engine now closed to new customers, and managed InfluxDB 2 and 3.Apache IoTDBOpen sourceAlso good for high-cardinality time seriesAn 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 sourceAlso good for high-cardinality time seriesA young single-binary time-series database in Go that writes incoming data as Parquet files and queries them with DuckDB SQL.GreptimeDBOpen sourceAlso good for high-cardinality time seriesA Rust database that stores metrics, logs and traces as tables on object storage, queried with SQL or PromQL.KairosDBOpen sourceAlso good for high-cardinality time seriesA Java time-series server that stores metrics with tags in Apache Cassandra; it began in 2013 as a rewrite of OpenTSDB and is now kept going by a single maintainer.kdb+CommercialAlso good for high-cardinality time seriesA columnar time-series database that is also an interpreter for q, an array language, used for market data across trading and risk.QuestDBOpen sourceAlso good for high-cardinality time seriesA 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 sourceAlso good for high-cardinality time seriesA clustered time-series database for IoT and industrial data that gives every device its own table, grouped under “supertables” with tags.Workers Analytics EngineCommercialAlso good for high-cardinality time seriesCloudflare’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.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.Apache HoraeDBArchivedOpen sourceA 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.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.OpenTSDBArchivedOpen sourceA time-series database built on HBase: stateless Java daemons that turn metric, timestamp, value and tags into compact HBase rows, one row per series per hour.

How it fits with other technologies

Labelled series, a downsampling rule and a label query, from the Keyspace 2025 slides · bash

TS.ADD temperature:bedroom * 22.1 LABELS room bedroom building main
TS.MADD temperature:living_room * 25.8 temperature:bedroom * 22.2

# hourly averages, kept up to date as samples arrive
TS.CREATERULE temperature:living_room temperature:living_room:1h AGGREGATION avg 3600000
TS.RANGE temperature:living_room -1hr + AGGREGATION avg 3600000

# Prometheus-style selector over labels
TS.QUERYINDEX latency{region=~"us-west-*",service="inference"}

See it in a real stack

No architecture uses ValkeyTimeSeries yet. Drop it into the playground and wire it up yourself.Open playground →

Worth exploring

Slides· August 2025Harder, Better, Faster, Stronger: Building Valkey-TimeseriesClayton Collie, Keyspace 2025 (Valkey’s conference, Amsterdam)The author’s slides for ValkeyTimeSeries, a Rust module meant as a drop-in replacement for RedisTimeSeries. A short tour of the TS.* commands, then what it adds: background expiry of old samples, chained compaction rules, Prometheus-style series selectors, TS.JOIN with as-of joins, an inverted label index built from an adaptive radix tree of Roaring bitmaps, parallel queries and string interning for labels. Written by the module’s developer, so it describes plans and strengths rather than trade-offs.
All resources →
Where it came from2024–2026

Time series in Redis came from a separate module, RedisTimeSeries, made by Redis Ltd. When Redis moved to source-available licences in March 2024 and the Linux Foundation started Valkey as an open-source fork, Valkey had no time-series data type, and in May 2024 users asked for one; the request is still open. Clayton Collie, an independent developer, started ValkeyTimeSeries in Rust in early 2025 as a drop-in replacement for RedisTimeSeries, and wrote up its design as an RFC in his fork of Valkey’s RFC repository.

Collie presented it at Keyspace 2025, Valkey’s conference in Amsterdam, on 28 August 2025, describing it as faster and more scalable than RedisTimeSeries and adding Prometheus-style queries and joins. Work has continued in the community opensource-for-valkey organisation; by October 2026 the module also offered anomaly detection, label discovery and a differential fuzzer that checks its answers against RedisTimeSeries, but no tagged release.

Why it’s built this way

Copy the RedisTimeSeries API
Applications and client libraries already used TS.* commands, so a superset of that API lets them switch servers without rewriting code.
Prometheus selectors and metadata queries
Many users store monitoring metrics, and Prometheus’s label-matching syntax and label metadata APIs are what monitoring tools already speak.
A radix tree of bitmaps for labels
Queries select series by label; mapping each label pair to a compressed bitmap of series IDs makes intersecting filters cheap even with millions of series.
Write it in Rust
Valkey modules run inside the server process, so memory safety and lock-free parallel reads matter; Valkey’s own Bloom filter module is also in Rust.

Timeline

  1. 2024

    Redis changes licence; Valkey forks it in March, and users ask for a time-series module in May

  2. 2025

    Repository created in February; presented at Keyspace 2025 in Amsterdam on 28 August

  3. 2026

    Commits continue through October; still no tagged release

Sources5 · facts checked 24 October 2026

Improve this page on GitHub