# RedisTimeSeries became part of Redis 8, which changes how you adopt it

> RedisTimeSeries is a time series data structure for Redis, holding samples, labels, a retention period and automatically updated compactions, and since Redis 8 it is integral to the server rather than a module you install separately. The README is also explicit that standalone versions are no longer released, that 32 bit systems are not supported, and that the licence changed with Redis 8.

**RedisTimeSeries/RedisTimeSeries** — Time Series data structure for Redis

- Repository: https://github.com/RedisTimeSeries/RedisTimeSeries
- Website: https://redis.io/docs/stack/timeseries/
- Stars: 1,063 · Forks: 146
- Language: Python
- License: NOASSERTION
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/redistimeseries-redistimeseries

## The module became a data structure in Redis 8

The first note in the README changes everything for anyone evaluating this today. Starting with Redis 8, the Time Series data structure is integral to Redis, you do not need to install this module separately, and there are no longer standalone versions of RedisTimeSeries.

That is a change of packaging, not of behaviour, and it has two consequences for an adopter. The first is that the upgrade path disappears: there is no new module to install on an existing Redis 5 or 7, because the same feature now ships inside the server, so a decision about this technology is now a decision about your Redis version. The second is that the deployment story changes, because a module has to be loaded with --loadmodule while a built in data structure needs nothing.

The other note is the platform constraint. 32 bit systems are not supported, and the Makefile enforces the same rule at build time, checking the detected architecture and refusing anything that is not x64.

The result is a project whose repository is still a full source tree with its own build system, its own tests and its own container images, but whose role in the Redis stack has shrunk from being a component you assemble to being a data type you use.

The audience is still a team that needs time series and already runs Redis, which is the common case for sensor and monitoring workloads, and the integration projects in the RedisTimeSeries organisation make that case concrete.

## A series is samples, a retention window, labels and compactions

The structure of a time series in this engine has four parts, and the overview section describes each of them.

Raw samples come first, and each one is a time tag and a value pair. The time tags are measured in milliseconds since January 1st 1970 at 00:00:00, and they can be specified by the client or filled in automatically by the server. The values are 64 bit floating point numbers, the intervals between time tags can be constant or variable, and the samples can be reported in order or out of order.

Then there is an optional configurable retention period. Raw samples older than the retention period are discarded, and the reference point for that comparison is the raw sample with the highest time tag, so retention is relative to the newest data rather than to the wall clock.

Series metadata is a set of name value pairs, with the examples given being room = 3 and sensorType = 'xyz'. This is the part that turns a collection of numbers into a queryable set, because the same metadata applies across series, and the engine supports cross time series commands, so you can aggregate the data over all the sensors in a room or all the sensors of the same type.

Finally, a series can have zero or more compactions, which are described as an economical way to retain historical data. A compaction has a timeframe, an aggregator such as min, max, sum or avg, and an optional retention period. The example given is the compaction {10 minutes, avg, 10 years}, which stores the average of the raw values measured in each ten minute time frame, for ten years.

## Out-of-order samples and a duplication policy are the details that matter

Two of the smaller features are the ones that decide whether a time series engine survives contact with real data.

The first is the duplication policy. When two samples arrive with identical time tags, the series can be told what to do with them: block the new sample, or keep the first, or the last, or the minimum, or the maximum, or the sum. Real sensors and real network protocols both produce duplicate timestamps, and a system that rejects them outright loses data while a system that accepts them silently picks an arbitrary winner. Making the choice explicit, and configurable, is the difference between a policy and an accident.

The second is that samples can be reported in order or out of order, which is the normal case for anything that batches writes or arrives over a network. An engine that only accepts ascending timestamps forces the client to sort, and that is a bug that shows up as a rejected write rather than as a rejected design.

The millisecond timestamp basis and the 64 bit floating point value type are the other two choices in that list, and both are worth stating plainly. Milliseconds since the epoch is the convention most time series tools use, which makes interleaving with other systems straightforward, and floating point values mean a sensor reading does not have to be an integer.

The examples the README gives for what the structure is for are also revealing. Sensor data, such as temperatures or fan velocity for a server in a server farm, historical prices of a stock, and the number of vehicles passing through a given road counted per one minute timeframes. All three are counters or gauges sampled on a schedule, which is the shape the engine is built for.

## Compactions are the answer to keeping ten years of data

The compaction mechanism deserves more attention than it usually gets, because it is where the cost of time series data is decided.

A compaction takes the raw samples and stores an aggregate over each time frame instead. The example is a ten minute frame with the average aggregator and a ten year retention, which means the engine keeps one value per ten minutes for a decade, and discards the raw samples behind it.

The economics are the point. Raw sensor samples arrive at whatever rate the device reports, and ten years of them is a large amount of memory and disk. A compaction turns that into a bounded, predictable series, and the engine updates it automatically, so the application does not have to maintain a rollup table of its own.

There is a trade, and it is worth being explicit about. An average over a ten minute frame discards the shape of the data inside the frame, so a spike that lasted thirty seconds is invisible in the compacted series. That is usually fine for a monitoring dashboard and wrong for an application that needs to detect short excursions. The choice of frame size, aggregator and retention is therefore a modelling decision about which history you are willing to lose.

The feature list calls compactions automatically updated aggregated timeseries, and the retention period on the raw samples is configurable separately, so the two mechanisms compose: keep raw data for a short window, keep aggregates for a long one, and let the engine discard the raw samples once they age out.

## Labels are what turn it into a sensor database

The secondary index is the feature that distinguishes this from a list of numbers with timestamps, and the README describes it as each time series having labels, which are name value pairs, and which allow querying by labels.

Combined with the cross time series commands, that is the whole query model. A label set of room = 3 and sensorType = 'xyz' lets you ask for every series in a room, or every series of a type, and then aggregate across them. That is the query a monitoring system actually needs, and building it on top of plain Redis keys means writing the index yourself.

The feature list also names the aggregate operations available over any time bucket: Min, Max, Avg, Sum, Range, Count, First, Last, STD.P, STD.S, Var.P, Var.S and twa. The standard deviation and variance variants are the ones worth noting, since a mean alone hides a sensor that is oscillating.

Around that sit the two other headline capabilities, high volume inserts with low latency reads, and querying by start time and end time.

The integration list shows what the design is for. The RedisTimeSeries organisation holds a Prometheus adapter, described as a read and write adapter to use RedisTimeSeries as a backend database, a Grafana data source plugin, a Telegraf integration, and StatsD and Graphite exports using the graphite protocol. The Prometheus adapter is the interesting one, because it means an existing metrics pipeline can read from and write to this engine rather than only talking to it through a custom client.

## Building it yourself, and the module you no longer need

The repository still contains everything needed to build the module, which matters for anyone on a Redis version before 8.

The Dockerfile is a two stage build. The builder stage starts from debian:bullseye-slim, copies the Redis installation out of a redis:bullseye image, runs the readies dependency step, then the setup script, then make fetch build. The runtime stage starts from redis:bullseye, creates the modules directory, copies the built shared object in, exposes 6379 and starts the server with the module loaded:

```bash
redis-server --loadmodule /usr/lib/redis/modules/redistimeseries.so
```

That last line is what a pre-8 deployment looks like, and it is also a clear picture of what the module is, a shared object that Redis loads at start-up.

For a local build the Makefile offers a bootstrap target that runs the install script, with list and dry-run modes for checking the dependencies first, and a version of the install script that invokes sudo on Linux. It also handles the platform details that break naive builds, resolving the versioned OpenSSL formula on macOS because Homebrew's unversioned alias tracks the latest major release, which matters for the hiredis, LibMR and libevent builds.

The architecture detection is the other platform detail worth knowing, mapping x86_64 and amd64 to x64 and aarch64 and arm64 to arm64v8, and then refusing anything that is not x64.

The repository has a Dockerfile for a long list of base images, from alpine and several Debian releases to Amazon Linux, Azure Linux, Mariner, Ubuntu from bionic to resolute, Rocky and openSUSE, which is what a module that has to build on every distribution ends up looking like.

## The licence is a choice, and the choice is yours to make

The licensing section is the part to read carefully, because it changed with Redis 8 and because it offers a choice rather than a single grant.

Starting with Redis 8, RedisTimeSeries is licensed under your choice of the Redis Source Available License 2.0, the Server Side Public License v1, or the GNU Affero General Public License version 3, and the README asks you to review the license folder for the full terms and conditions. Prior versions remain subject to the first two of those options.

So there is no single licence, and that is a genuine decision rather than a formality. RSALv2 and SSPLv1 are source available licences with their own conditions, and AGPLv3 is the copyleft option with the network use provisions. A team shipping a commercial service on top of the engine has to decide which of the three it can live with, and the AGPL option is the one most organisations will want precisely because it is the one they already know how to reason about.

Code contributions are on different terms again. By contributing code in any form, including a pull request, a code fragment or a patch by private email or public discussion, the contributor agrees to release it under the Redis Software Grant and Contributor License Agreement, with the details in CONTRIBUTING.md, and security issues are handled through SECURITY.md.

The repository also holds a licenses/ directory, which is where the full terms live.

For a reader deciding whether to adopt this, the licence is not a footnote, it is the first question. And for anyone on Redis 8 or later, the practical step is simpler than any of this: the data structure is already in the server, and the module question does not arise.

## Conclusion

RedisTimeSeries suits a team that already runs Redis and wants time series in the same store, with labels, retention and downsampling handled by the engine rather than by application code, and that can live with a server side licence rather than an OSI approved one. It does not suit a deployment that must ship under AGPL or a permissive licence without choosing the right option, and it is the wrong tool if you need 32 bit support or a standalone module you can drop into an existing Redis. Verify first which Redis version you are on, because from Redis 8 the structure is built in and installing the module is unnecessary, and check the licence folder for the terms of the option you intend to pick.

## FAQ

### Do I still need to install RedisTimeSeries as a module?

No. Starting with Redis 8 the Time Series data structure is integral to Redis and you do not need to install the module separately, and the project no longer releases standalone versions of RedisTimeSeries. On older Redis versions the module is loaded with redis-server --loadmodule.

### What does a Redis time series store?

Raw samples as time tag and value pairs with millisecond timestamps and 64 bit floating point values, an optional configurable retention period, series metadata as name value pairs such as room = 3, and zero or more compactions that store aggregated values over a timeframe with their own retention.

### What happens when two samples have the same timestamp?

A duplication policy decides. It can be set to block, first, last, min, max or sum, so the engine either rejects the new sample or keeps a defined winner among them.

### Can RedisTimeSeries be used with Prometheus and Grafana?

Yes. The RedisTimeSeries organisation publishes a Prometheus adapter for reading and writing with RedisTimeSeries as a backend database, a Grafana data source plugin, a Telegraf integration, and StatsD and Graphite exports using the graphite protocol.

### What licence applies to RedisTimeSeries?

Starting with Redis 8 it is licensed under your choice of the Redis Source Available License 2.0, the Server Side Public License v1, or the GNU Affero General Public License version 3, with the full terms in the license folder. Earlier versions remain under the first two options, and code contributions are accepted under the Redis Software Grant and Contributor License Agreement.

## Sources

- [Issues](https://github.com/RedisTimeSeries/RedisTimeSeries/issues)
- [Project website](https://redis.io/docs/stack/timeseries/)
- [README](https://github.com/RedisTimeSeries/RedisTimeSeries/blob/master/README.md)
- [RedisTimeSeries/RedisTimeSeries on GitHub](https://github.com/RedisTimeSeries/RedisTimeSeries)
- [Releases](https://github.com/RedisTimeSeries/RedisTimeSeries/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/redistimeseries-redistimeseries