Swytch

Database coherency at cache speeds.

You have a coherency problem once you scale. Single-node Redis is fast, simple, well-understood. The moment you cluster it, coherency degrades. Cross-shard operations fragment, replicas lag, failover loses recent writes, multi-region replication ships writes back to a single region and calls it active-active. Your team built workarounds. The workarounds became the system.

Swytch is a distributed cache that gives you database-level coherency across any number of nodes or regions. Every node sees the same writes in the same order. No stale reads. No divergence after partition heal for non-transactional operations. Predictable, documented behavior for transactions under partition. And the architecture that makes this work happens to make operations dead simple: no leader election, no rebalancing, no failover runbooks, no split-brain recovery work.

You pay for the latency to the furthest node that’s interested in a given key, and no more.

A key that’s only used in one region pays regional latency. A key that’s used globally pays the cross-region round trip — but only on writes, only inside a transaction, and only to the nodes that care about that key. Reads are answered locally once a node has subscribed. Non-transactional writes don’t wait for causality at all; they propagate and merge deterministically because the underlying causal DAG is the same at every node.

Cost is locality-bounded. There’s no global coordinator paying global cost on every operation. The full mechanism is in the Light Cone Consistency framework; the practical takeaway is that Swytch’s latency profile is set by the geographic spread of each individual key, not by the cluster size.

# macOS / Linux (Homebrew)
brew tap swytchdb/tap
brew install swytch

# macOS / Linux (curl)
curl -fsSL https://getswytch.com/scripts/install.sh | sh

# Windows (PowerShell)
iwr -useb https://getswytch.com/scripts/install.ps1 | iex

Or pull the container:

docker pull ghcr.io/swytchdb/swytch:latest

Then start it and connect with any Redis client:

swytch redis
redis-cli -p 6379

For sidecar deployments, talk to it over a Unix socket (no TCP overhead, no listener exposed):

swytch redis --unixsocket /tmp/swytch.sock --bind ""

Prebuilt binaries, checksums, and cosign signatures for every release are at https://github.com/swytchdb/swytch/releases.

Swytch is 100% Redis-wire compatible. Your existing client connects, your existing commands run. What changes is how those commands behave at scale:

Full Redis 8.4 semantics across regions. All commands. Cluster-wide pub/sub. Keyspace notifications uniform across the cluster. The behavior you get from single-node Redis is the behavior you get from a multi-region Swytch cluster.

Exactly-once for queue operations. Lists and streams used as queues deliver each item exactly once, not at-least-once. No application-level dedup. Redis Cluster pins queues to a single region; Redis Enterprise’s Active-Active CRDTs are explicit that list pops are at-least-once across regions and that streams have similar delivery and ordering limitations under multi-region reads. Swytch’s envelope-commit gives you exactly-once across regions, in the data plane, with the same Redis commands.

Cross-region transactions with explicit partition behavior. MULTI/EXEC is serializable across regions when the network cooperates, blocks cleanly under partition rather than silently committing on one side. The partition behavior is predictable and documented in the Designing for Partitions page.

No re-sharding, no failover, no rebalancing. Adding capacity is starting another node. Recovering from node failure is restarting the node. These properties fall out of the leaderless architecture; they aren’t separately-engineered features.

Each line below is a piece of infrastructure your stack is probably running today, and a thing Swytch absorbs into a single binary on the servers you already operate:

• The managed Redis tier. Swytch runs as a sidecar in the spare RAM of your application servers (the nearcache pattern), so there’s no separate cluster to provision.
• Sentinel and Redis Cluster operational tooling. No failover orchestration, no hash-slot rebalancing, no split-brain recovery scripts.
• The exactly-once queue layer. No separate Kafka or RabbitMQ for delivery guarantees; the data plane handles it.
• Per-region Redis Enterprise licenses. Swytch’s multi-region active-active doesn’t multiply with region count.

The Economics page has the math: Economics of Swytch.

Drop-in Redis at scale. A team already runs Redis for caching, sessions, rate limits, and leaderboards. They need it across multiple regions without running Redis Cluster or Redis Enterprise, without dealing with primary-replica failover, and without rewriting the app. Swytch speaks Redis RESPv2 and RESPv3; the client doesn’t change, the commands don’t change, and the ops change from “operate Redis Cluster” to “run another Swytch node in the new region.”

Global work queues with exactly-once delivery. Workers in multiple regions consuming from shared queues where every message must be processed once. Redis Cluster pins queues to a single region. Redis Enterprise’s Active-Active is documented as at-least-once for destructive list operations and for streams (XREAD may skip entries; XREADGROUP across regions can re-deliver acknowledged entries), with their recommended mitigation being to route reads through one instance (which gives up the active-active property for queue workloads). Swytch’s envelope-commit gives exactly-once across regions through the same Redis commands.

Telecommunications and session handoff. Equipment along a busy route needs session state that follows users as they move. Reads are local on whichever node the user is nearest to; writes replicate synchronously to the nodes that the user’s next hop will land on. No central session store to page, no replica lag between “the session was updated” and " the next request sees it."

Anywhere the internet is in your threat model. Ships at sea. Construction sites. Rural clinics. Disaster response. Spacecraft. Anywhere writes need to happen while the network isn’t cooperating, and reconcile cleanly when it is.

If your application runs happily on a single-region Redis and the network always cooperates, Swytch probably isn’t giving you anything you need. Use what works. The value shows up when that picture breaks down.

• What is Swytch? — what it is, how it works, what it’s good for.
• Architecture — effects, the causal DAG, envelope-commit transactions, clustering.
• Light Cone Consistency — the framework underneath everything.
• Designing for Partitions — what happens during partitions, what doesn’t, how to design around it.
• Economics of Swytch — the cost math against Redis OSS, Redis Enterprise Cloud, and ElastiCache.
• Swytch vs Redis (OSS/Valkey) — what changes architecturally.
• Swytch vs Redis (Enterprise) — exactly-once vs CRDT semantics.

A SQL mode is also available, speaking the PostgreSQL wire protocol over a SQLite query engine. It’s currently experimental: start here if you’re considering it.