tporadowski/redis: a Windows port of Redis 5.0 that is a decade past its upstream

Why a Windows port of Redis needed to exist at all

The repository description calls itself a native port of Redis for Windows and says so three times over: unofficial port, native port, for Windows. Repeating the word native is doing real work in that sentence. Before this port and the MS Open Tech build it grew out of, running Redis on a Windows machine meant running it inside WSL, inside a Linux container, or inside Cygwin. None of those give you a `redis-server.exe` that a Windows service manager can start.

The lineage is unusually well documented for a port. The README says the current branches are merged with the archived port of version 3.2.100 from the MS Open Tech team, notes that the original sources were merged by hand, and says the project was updated to Visual Studio 2019 (v16.2.5) with findings from unit tests fixed along the way. That is a more candid account of a port's construction than most repositories give.

The data model is Redis's own, and the description enumerates it: strings, lists, sets, sorted sets, hashes, streams and HyperLogLogs. The description also states that Redis is an in-memory database that persists on disk, which is the right mental model. The homepage points at redis.io, so documentation, licensing and command semantics are meant to be read as upstream Redis rather than as project-specific behaviour.

Two maintained branches and a default branch that is neither

The version picture is where this repository differs most from what a reader assumes. The default branch is `develop`, but the README directs users to two specific long-lived branches instead: `win-4.0.14` for a stable port of Redis 4.0.14, and `win-5.0` for a stable port of Redis 5.0.14, both for Windows x64.

So there is no single Redis version here. There is a 4.0 line and a 5.0 line, each described as stable, and a development branch that is not the thing most people want. If you are cloning this repository without reading carefully, you can easily end up on a branch whose version you did not intend.

The releases confirm the two-line structure. Three tags are visible: v5.0.14.1 published in February 2022, v5.0.14 from October 2021, and v5.0.10 from November 2020. All three are on the 5.0 side, so the 4.0 branch appears to have stopped receiving tagged releases earlier. The v5.0.14.1 body is worth reading for its scope: it is described as a bugfix and maintenance release working around an issue with module usage during asynchronous save operations, with the explicit note that if you are not using modules there is no need to upgrade.

That last sentence is a good signal about what kind of fixes this project ships. Modules arrived in Redis 5.0 and are the feature most likely to break on a platform port, so a patch release narrowly scoped to module and save interaction tells you the port's real work is keeping upstream behaviour intact rather than adding anything of its own.

The jemalloc patch is where the port actually lives

The most interesting technical content in the README is the dependency section, and it is short. Redis depends on jemalloc, and on Windows that dependency needs modification because jemalloc's memory management is built around POSIX assumptions. The README says the vendored copy is slightly customized with respect to calls to `VirtualAlloc` and `VirtualFree`, and that those are replaced with calls to `AllocHeapBlock/PurgePages` and `FreeHeapBlock` from `src/Win32_Interop/Win32_QFork.cpp`.

The reason given for that replacement is not performance. It is to keep track of which memory regions should be made available to child processes, which matters specifically for saving RDB and AOF files. Redis forks to serialize data to disk, and fork is a POSIX concept with no direct Windows equivalent. `Win32_QFork.cpp` is where the port reimplements it, and the allocator changes exist to serve that mechanism rather than as an optimization.

Those changes are maintained separately in the tporadowski/jemalloc repository and then copied into `deps/jemalloc`. The repository tree shows where that lands: a `deps/` directory alongside `src/`, with `src/` holding the server itself, `tests/` for the test suite, and `utils/` for the command-line tooling. There are three test entry points at the top level, `runtest`, `runtest-cluster` and `runtest-sentinel`, which means cluster and sentinel paths are exercised rather than left unbuilt.

The build is driven by a top-level Makefile that does nothing but delegate, which is the conventional layout for the Redis tree:

default: all

.DEFAULT:
	cd src && $(MAKE) $@

Underneath it sits `src/Makefile`, described in the Makefile's own comment as where the real build is.

Building it on Windows needs Visual Studio, not a package manager

The README's build instructions are a numbered list of three requirements, and none of them is a package manager. You need Visual Studio 2019 or newer, meaning Community Edition version 16.2.5 or newer, with the C and C++ features enabled. You need the Windows SDK 10. And you need Git Bash for Windows or Cygwin with Git, because after cloning you must run `src/mkreleasehdr.sh` to generate `src/release.h` from Git metadata. The README allows creating that file by hand instead, which tells you the script is a convenience rather than a real dependency.

This is a source distribution rather than a binary one, which is unusual for a project people mostly consume as a downloadable build. The README opens by pointing at the releases page for both 5.0.14 and 4.0.14 and asking people to test and report issues, so the intended path is download a prebuilt package. Building from source is for people who need to patch it.

Configuration also lives in the repository rather than being generated. The tree includes `redis.conf` and `sentinel.conf`, alongside documentation files with telling names: `Redis on Windows.md`, `Redis on Windows Release Notes.md`, and `Windows Service Documentation.md`. The presence of a dedicated Windows Service document is the clearest signal of what this port was built for, since running Redis as a background Windows service is the specific gap WSL and Docker leave open.

There is also an `appveyor.yml` and an `msvs/` directory, so the project does have continuous integration for the Windows build rather than leaving that entirely to the release maintainer.

A recent commit date and a four-year-old release are different facts

The last push recorded for this repository is dated 2026-09-14, and the repository is not archived. The most recent tagged release is v5.0.14.1 from February 2022. Both statements are true and they point in different directions, so it is worth separating them before deciding anything.

Recent commits on a maintained port branch usually mean dependency updates, build fixes, or work that has not been cut into a release yet. They do not mean Redis features have arrived. What this build supports is bounded by Redis 5.0.14, and that boundary is where the engineering judgement has to sit. Everything Redis shipped after 5.0.14 is absent: no Redis 6, no Redis 7 modules work beyond the one module-save workaround noted in v5.0.14.1, and no Redis 8.

The licensing picture needs the same treatment. GitHub reports the license as NOASSERTION, which is its way of saying it could not classify the repository from its files. The tree contains both `COPYING` and `license.txt`, so licensing material is present even though the classifier did not recognise it. Redis itself is BSD licensed, and the README describes this as an unofficial port rather than a derivative redistribution under different terms, but if license compliance matters to your organisation, read those two files directly instead of relying on the repository field.

The one place the README tells you about a removed feature is the v5.0.10 release note, which says the `activedefrag` feature for active memory defragmentation is switched off because it needs further investigation to work properly. That is a small but instructive detail: features that depend on kernel-adjacent memory behaviour are the first casualties in a port, and the project disables them rather than shipping something unreliable.

Editorial conclusion

tporadowski/redis exists because a specific gap needed filling: a native Windows binary of Redis that did not depend on WSL, Docker or Cygwin. It fills that gap well enough that plenty of Windows development setups still rely on it, and the branch structure makes it easy to pick the version your client library expects. What it does not do is track upstream. Every Redis feature, command and fix landed after 5.0.14 is absent from this build, so treat the port as a compatibility target rather than a Redis installation. Start by confirming your application's client library works against 5.0 semantics, then decide whether a Linux-hosted Redis in Docker or WSL is a better fit for anything beyond local development.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. tporadowski/redis on GitHub