Carmine: a pure Clojure Redis client whose compatibility table says no to Sentinel and Cluster

The compatibility table rules out two of the Redis deployments you are most likely to run

Carmine's README leads with a table of Redis flavours and, in four of the five rows, the answer is a single word. A single node is supported. Redis Enterprise and Redis Cloud are supported. Redis Sentinel is marked "No (possibly later)". Redis Cluster is marked "No (possibly later)" as well.

That table is the single most useful thing in the README, because Sentinel and Cluster are exactly the two configurations that a team reaches for when Redis becomes important enough to worry about. The parenthetical is the only hint of a plan, and it is not a schedule. Nothing in the visible documentation says when, or under what conditions, either might be added.

The other two supported rows are worth reading closely too. Enterprise and Cloud are listed with the features "High availability, sharding" and, for Cloud, "hosted". So the supported path for a sharded, highly available deployment is the commercial offering, not the open source clustering mode. Whether that is a deliberate product decision by the maintainer or a consequence of the protocol work involved is not something the README resolves, but the practical effect is the same: a team that standardised on Sentinel has to change its deployment or change its client.

The client is described as a "mature Redis client for Clojure that offers an idiomatic Clojure API", and the stated qualities are speed, power and ease of use. It is a pure Clojure library, with no native dependency, and the documentation states support for the "latest Redis commands and features".

Nippy handles serialization, which decides what you can store

One of the six reasons the README gives for using Carmine is the "Auto de/serialization of Clojure data types via Nippy". Nippy is a separate library by the same author, and Carmine uses it to move Clojure values into Redis and back.

This is the feature that most changes how you write the calling code, and it also defines the boundary of what Carmine can talk to. If a value is serialized as a Clojure data structure, then anything that reads that Redis key has to understand the same format. A Go service, a Python script, or a colleague looking at the data in `redis-cli` will see something that is not JSON. That is a deliberate trade: idiomatic Clojure in exchange for interoperability that you have to arrange yourself.

The obvious question is whether the raw string and numeric Redis commands still work, and the README's claim of support for the latest Redis commands suggests the library covers the command surface rather than only the Clojure-typed convenience layer. The API reference on cljdoc is where the split between the two layers is documented, and the README points there rather than summarising it.

The `deps/` directory at the repository root is the place to look for how those data formats are wired in, since that is where reader and codec declarations live for this kind of library.

Connection pooling, a message queue and a lock, all in one library

The remaining three reasons to choose Carmine are infrastructure rather than protocol. The first is "production-ready connection pooling", which matters because a Clojure web application makes many short Redis calls per request and a fresh socket per call does not survive production traffic.

The second is the message queue API, described as fast and simple, with the documentation living on a wiki page titled for message queues. The third is a distributed lock API, documented separately on cljdoc under the locks namespace. Both of these are the kind of feature that teams otherwise write themselves, badly, and a shared implementation is worth more than a hand-rolled one.

The repository root contains `mq-architecture.svg` and `mq-architecture.monopic`, which is a diagram of the queue's internal design, and a `wiki/` directory that holds the pages the README links to. The `carmine-v4.org` file in the root is a separate document about a v4 of the library, which suggests the message queue design has been worked on across major versions rather than bolted on at the end.

Where the library comes from and where the documentation actually is

The README contains no installation command. Carmine is a library published to Clojars under the coordinate `com.taoensso/carmine`, and the README links the Clojars page and the cljdoc API documentation. The wiki is described as covering getting started and usage, with the API reference hosted separately on cljdoc, and support offered through Slack or GitHub issues.

That structure means the README is a signpost, not a manual. A new user following it lands on the wiki for the actual getting started material, which is the norm for Clojure libraries and the norm for this author in particular, but it does mean you cannot evaluate the API surface from the repository's front page.

The tooling in the repository shows how the project is developed and tested. There is a `project.clj`, so the build is driven by Leiningen, alongside a `deps/` directory, and a `bb.edn` with a `bb/` directory for Babashka tasks. Two separate test workflows are referenced by the badges at the top of the README, one for the main tests and one for Graal tests, so GraalVM native image compatibility is a tracked concern rather than an accident. A script named `check-resp3.sh` sits in the root, which points at attention being paid to the RESP3 protocol, the newer Redis wire protocol, alongside the older one.

Release history: a long gap, a v3.5.0, and work since

The release list is short and unevenly spaced. v3.4.0 and v3.4.1 arrived in May 2024, four days apart, and the next tag, v3.5.0, came on 2025-11-06, roughly a year and a half later. The last push to the repository was on 2026-10-09, which is about eleven months after v3.5.0 shipped. The README's own headline links to v3.5.0 as the latest release.

So the default branch is ahead of the latest tag by a long way, and a project that does not cut releases often gives you an awkward choice between an old tag and a moving branch. There is a `CHANGELOG.md` in the root, which is where you would look before pinning either.

Licensing is uncomplicated. Carmine is under EPL 1.0, the same licence as Clojure itself, and the README carries a copyright line for Peter Taoussanis covering 2014 to 2025, with the licence text in `LICENSE.txt` at the root. The project also has a `SECURITY.md` and a `FUNDING.yml`, and the README asks for sponsorship to support continued work on the library and the author's other projects.

Where Carmine is the wrong choice

The wrong choice case is Redis Sentinel or Redis Cluster, and it is not a close call. A client that cannot speak to your failover mechanism is not a partial solution; it is a deployment blocker. If Sentinel is already running in your infrastructure, no amount of Carmine's queue and lock APIs will make the choice work, and the alternatives are a different client or a different deployment.

The second case is a mixed-language estate. The automatic serialization through Nippy means the Redis contents are Clojure values rather than plain text, so any consumer outside Clojure needs the same codec on its side. The README does not describe a JSON-first mode, so treating Carmine as a neutral shared datastore for several services is a decision to make with care.

The third case is a team that needs a stable, dated release on a schedule. With a v3.5.0 from November 2025 and a default branch that has moved since, the choice is between a tag that predates the current work and a branch that carries no version guarantee. The `carmine-v4.org` document in the repository root hints at a next major version, and a v4 design in progress is a reason to read the changelog carefully before building on the current API.

Editorial conclusion

Adopt Carmine if your Clojure service talks to a single Redis node, or to Redis Enterprise or Redis Cloud, and you want connection pooling, message queues and distributed locks without leaving Clojure. Do not adopt it if your deployment depends on Sentinel failover or Cluster sharding, because the compatibility table marks both as unsupported, with only a vague possibility of later support. Before you upgrade, check the version you are on against v3.5.0 from 2025-11-06 and read the `carmine-v4.org` file in the repository root, since master has moved since that release.

Frequently asked questions

Official sources

1. License: EPL-1.0
2. Project website
3. README
4. Releases
5. taoensso/carmine on GitHub