Go Clients for Redis vs Memcached

go-redis: the workhorse

go-redis has been the dominant Redis client in Go since the mid-2010s. The current v9 line is maintained by Redis Inc. and supports every Redis command, Redis Cluster, Sentinel, pub/sub, Streams, Lua scripts, transactions, and pipelining. The API is idiomatic Go: every command takes a context.Context as the first argument, returns a typed result wrapper with .Err() and .Val() (or .Result()).

Connection management is automatic: redis.NewClient(opts) returns a client that manages an internal connection pool of 10*GOMAXPROCS connections per node by default. The pool is sized for typical web-server concurrency; tune via the PoolSize option if you have unusual workload characteristics. Cluster support uses redis.NewClusterClient with a list of seed nodes; the client discovers full topology and routes commands by hash slot.

The major recent additions include RESP3 protocol support (opt-in via the Protocol field), client-side caching with the Redis 6+ invalidation protocol, and improved typed-result handling. For new Go services in 2026, go-redis is the safe default with the broadest ecosystem support.

Side-by-side: a job queue producer

import (
  "context"
  "github.com/redis/go-redis/v9"
)

rdb := redis.NewClient(&redis.Options{
  Addr: "localhost:6379",
  PoolSize: 50,
})

// Producer: enqueue job
ctx := context.Background()
id, err := rdb.XAdd(ctx, &redis.XAddArgs{
  Stream: "jobs",
  Values: map[string]interface{}{
    "type": "email",
    "user_id": "42",
  },
}).Result()

// Consumer: process with consumer group
streams, _ := rdb.XReadGroup(ctx, &redis.XReadGroupArgs{
  Group:    "workers",
  Consumer: "worker-1",
  Streams:  []string{"jobs", ">"},
  Count:    10,
  Block:    5 * time.Second,
}).Result()

import (
  "github.com/bradfitz/gomemcache/memcache"
)

mc := memcache.New("localhost:11211")

// Memcached has no list / stream type.
// Cannot implement a real queue.
// You could simulate with key-per-job:
mc.Set(&memcache.Item{
  Key: "job:" + jobID,
  Value: []byte(payload),
  Expiration: 3600,
})

// But no FIFO, no consumer groups, no ACK,
// no fan-out. Use a real queue, not Memcached.

rueidis: the technically interesting newcomer

rueidis is a newer Go Redis client (first release 2022) built around RESP3 from day one. Its architectural distinguishing feature is request-response pipelining at the protocol level: all commands flow over a single multiplexed connection per node, similar to Lettuce in Java, rather than the connection-pool model that go-redis uses.

For workloads with many concurrent goroutines all hitting Redis, rueidis can outperform go-redis by 20-40% in benchmarks because there is no pool-acquisition overhead and pipeline batching happens automatically across goroutines. The trade-off is a slightly less Go-idiomatic API (more builder-style for commands) and a smaller ecosystem of third-party integrations.

The other notable rueidis feature is built-in client-side caching using the Redis 6+ tracking-and-invalidation protocol. The client can locally cache the result of GET / HGETALL operations, and Redis pushes invalidation messages when the keys change. For high-read workloads this can dramatically reduce Redis traffic. Rueidis is maintained under the redis/ GitHub org alongside go-redis, signaling that both clients have ongoing Redis Inc. support.

gomemcache: the only real Memcached game in town

github.com/bradfitz/gomemcache is the canonical Go Memcached client, written by Brad Fitzpatrick (Memcached's original author at LiveJournal). The API is intentionally minimal: memcache.New(servers...) returns a client, mc.Set(item), mc.Get(key), mc.Increment(key, delta), and the standard CRUD operations.

Multi-server support is consistent-hashing: provide a list of server addresses, and the library hashes keys across them. There is no concept of replication or failover; if a server goes down, the affected keys disappear from cache. This matches the canonical Memcached operational model where the cache is treated as ephemeral and the application can repopulate on miss.

The gomemcache library predates the Go context convention and does not accept a context.Context on operations. For most cache workloads this is acceptable because cache calls are fast and not typically cancelled. For services that need strict deadline propagation, you would either wrap gomemcache calls with custom timeout logic or use one of the smaller community-maintained context-aware Memcached clients (none has reached the same maturity as gomemcache).

FAQ

Related decisions