Swytch vs Redis (OSS/Valkey)

Swytch’s Redis mode supports RESPv2 and RESPv3, Redis commands, and Redis-format ACLs. Check the compatibility guide for limits before migrating your clients and scripts.

What changes is the shape of the cluster underneath. Redis is a single primary with replicas. Swytch is leaderless: every node accepts reads and writes, data flows to interested subscribers, and a new region can join the same system. That architectural difference is what the rest of this page is about.

For the commercial multi-region product, see Swytch vs Redis (Enterprise).

For the local mirror’s sync window, eviction behavior, and recovery requirements, see local durability. It uses Swytch’s effect format rather than RDB or AOF.

The biggest architectural difference is how the two handle more than one node.

Redis OSS is designed around a single primary. Scaling reads means adding replicas that follow that primary asynchronously. Scaling writes means Redis Cluster: sharding keys across multiple primaries via hash-slot assignment, with each primary having its own replicas. Multi-region active-active isn’t available in OSS at all; it’s a Redis Enterprise feature.

Swytch’s clustering is leaderless. Every node is a peer; there are no hash slots, no primaries, no replicas. Start a node with --join ip:port pointing at a reachable peer and --cluster-advertise ip:port set to its own reachable endpoint. Further peers are learned through membership keys. Cluster traffic runs over QUIC with mutual TLS, authenticated by a shared passphrase. Adding a node means starting another binary with the same passphrase and an existing peer as its bootstrap contact. Removing a node is stopping it; online state remains available where another holder or storage tier retains it. A local mirror can restore synced resident state when the node restarts on the same storage.

Multi-region works the same way as single-region, because the architecture doesn’t distinguish. A node in Frankfurt can join a reachable peer in Sydney or Virginia and advertise its own endpoint to form one active-active cluster. Resident reads can be local after subscribing. Transactions on shared state incur subscriber latency. Peer addresses must be reachable across regions; see multi-region topology.

Redis executes the commands queued by MULTI as an uninterrupted sequence at EXEC. WATCH detects changes to keys read before that execution, allowing a client to retry a read-modify-write decision.

With swytch redis --ssi, MULTI captures a snapshot and each command returns its actual result immediately. Your application can read stock, decide whether an order fits, and update several keys before EXEC commits the changes. Reads include the transaction’s earlier writes; other connections see only committed state. EXEC returns the collected results without running the commands again. A confirmed conflict aborts with a null result; retry the whole transaction, including the decision.

This is the recommended way to write transactional logic in Swytch. Lua is not required. Lua scripts and functions are provided on a best-effort basis for compatibility with existing Redis applications. Keep branches and calculations in your application’s language; the transaction guide shows how.

The default mode still queues commands and returns QUEUED for Redis client compatibility. --ssi is an opt-in protocol extension, so use a client that accepts immediate replies on one connection. WATCH remains available for observations made before MULTI; reads inside an SSI transaction already participate in isolation.

Test the deployed client’s transaction, conflict, and retry paths before migrating. A lost EXEC response can leave the commit outcome unknown. SSI also retains the engine’s partition and safety behavior.

For applications that rely on MULTI/EXEC for correctness (counters that must not lose updates, stock decrements, rate limiters, any stateful operation where “this should be atomic” actually means it), this is a meaningful upgrade. For applications where MULTI/EXEC is used loosely or not at all, the difference doesn’t show up in day-to-day code.

When evaluating Swytch against Redis, compare equivalent deployment models and failure conditions.

Redis OSS Cluster uses primary-owned writes. Redis Enterprise Active-Active supports writes in multiple regions. These have different consistency and reconciliation semantics.

For queue correctness, consult Redis’s documented Active-Active list behavior, including concurrent duplicate pops. For acknowledged-write safety, consult the Redis Cluster specification’s failover scenarios.

Evaluate whether successful operations can disappear, whether conflicting operations can both be acknowledged, whether the system preserves their histories, and whether applications can detect and reconcile the outcome.

Apply the same criteria to Swytch 1.6+, distinguishing safe and unsafe transactions from ordinary nontransactional operations.

See vs. Enterprise for more.

Reach for Redis OSS when:

• You need a module whose commands Swytch does not implement. RedisJSON is built in; see JSON support.
• You rely on Lua cjson or cmsgpack; Swytch’s Lua support doesn’t include those libraries.
• You’re running a single region and current Redis is working fine.
• You have an operational preference for a dedicated cache tier separate from your application servers.

Reach for Swytch when:

• You’re running multi-region and need active-active without Redis Enterprise.
• You want simpler ops. No Sentinel, no sharding, just add servers.
• You want to cut infrastructure costs by running on servers you already pay for. See Economics of Swytch for the math.

Swytch uses Redis clients and supported Redis commands; compatibility still needs a workload-specific check. The cluster underneath does: Redis is a primary-with-replicas model that scales through Cluster sharding and Sentinel-managed failover, while Swytch is leaderless, subscription-driven, and active-active across regions by default. For applications running inside a single region with no transactional requirements beyond basic key-value operations, Redis OSS is battle-tested and fine. For applications that need multi-region, real MULTI/EXEC isolation, or just want to stop operating Sentinel and Redis Cluster, Swytch is what that looks like when the architecture is built for it from the ground up.