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.
- What it is
- Time-series databases
- 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 →
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.
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.
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.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.
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
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.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.
Timeline
- 2024
Redis changes licence; Valkey forks it in March, and users ask for a time-series module in May
- 2025
Repository created in February; presented at Keyspace 2025 in Amsterdam on 28 August
- 2026
Commits continue through October; still no tagged release
- Redis blog: Redis adopts dual source-available licensing (Mar 2024)
- Linux Foundation: Launches open source Valkey community (Mar 2024)
- GitHub: valkey-io/valkey issue #464, About support timeseries module (May 2024, open)
- Clayton Collie: Harder, Better, Faster, Stronger, Building Valkey-Timeseries (Keyspace 2025 slides)
- Valkey: Keyspace 2025 (28 August 2025, Amsterdam)
- GitHub: ccollie/valkey-rfc TimeSeries.md (design RFC in a fork of valkey-io/valkey-rfc)
- GitHub: opensource-for-valkey/valkey-timeseries (created February 2025, commits through 2026)
- GitHub: valkey-io/valkey-bloom (Rust module)
Sources5 · facts checked 24 October 2026
- GitHub: opensource-for-valkey/valkey-timeseries README (features, commands, cluster mode, build)
- valkey-timeseries docs: TS.JOIN
- Clayton Collie: Building Valkey-Timeseries (Keyspace 2025 slides; structure, index, improvements over RedisTimeSeries)
- npm: @valkey/time-series (RedisTimeSeries commands for the node-valkey client, MIT)
- GitHub: valkey-io organisation repositories (no official time-series module)