What is Swytch?
Swytch is a distributed cache with database-level coherency.
Every node accepts writes. Every node serves reads. Writes commit synchronously to the nodes subscribed to the data; reads are answered locally once a node has subscribed. The cluster has no primary, no consensus protocol, no coordinator whose health the cluster depends on. Every node arrives at the same ordering decisions without coordinating to agree, because the causal DAG underneath is the same at every node and the rules for ordering events on it are deterministic.
Swytch speaks Redis. Your existing client connects, your existing commands run. What changes is what those commands do at scale: full Redis semantics across regions, exactly-once for queue operations, cross-region transactions with predictable partition behavior, no rebalancing, no failover, no Sentinel.
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.
One binary per node. Deploy it as a sidecar next to your application, using the RAM you already overprovision for your app (Swytch takes a memory budget as a percentage of available memory). Your app talks to its local Swytch over a Unix socket or localhost TCP. Nodes find each other through DNS and replicate over QUIC with mutual TLS. No central service sits in the middle; nodes talk to each other directly. Scaling the cluster is adding another binary to another host and pointing it at the same DNS name.
Swytch nodes form a leaderless cluster. Nodes discover each other through DNS and communicate over QUIC with mutual TLS.
Replication is subscription-driven. A node subscribes to the keys its application actually touches, and only receives writes for data it’s subscribed to. When a write happens, it commits synchronously to the subscribed nodes. Reads are local after the first one: the first read on a given node triggers a subscription; subsequent reads are answered from memory.
You pay for the latency to the furthest node interested in a given key, and no more. A key used only in one region pays regional latency. A key 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. Non-transactional writes don’t wait for causality; they propagate and merge deterministically because the underlying causal DAG is the same at every node.
Under the hood, every write produces a semantic effect: an immutable record carrying the operation and pointers to its causal dependencies. Effects form a causal DAG, and every node sees the same DAG structure for the data it subscribes to. When two transactions conflict, every node detects the conflict and orders them deterministically from the DAG. Same DAG at every node, same rules, same result. Exactly one commits; the other fails cleanly. No voting, no communication to decide.
Read more about the architecture →
By default, Swytch handles partitions the same way most distributed databases do: writes to data that can’t reach its subscribers return an error, and the partition shows up as write-unavailability on the unreachable data. Reads still serve from local state. When the partition heals, non-transactional writes merge cleanly; transactions resume.
Swytch also implements a non-default mode called holographic divergence where both sides of a partition keep writing
and reconcile on heal, with the full causal history preserved. Holographic mode is for workloads where partitions are
part of the normal operating cycle (field equipment on remote sites, devices that drop uplink for scheduled windows). It
isn’t a self-service flag yet; if your workload needs it, email holographic@getswytch.com.
Read more about designing for partitions →
Swytch’s architecture isn’t ad-hoc. It’s a direct implementation of Light Cone Consistency, a formal framework that describes every message-passing system as the same three-parameter function over a causal DAG. Pick your parameters, you get a consistency model.
Swytch picks serializable consistency for transactions and causal consistency for everything else. Those are points on the LCC map; the framework describes the whole map.
By default, Swytch data lives in RAM across the nodes subscribed to it. If a node dies, the data is still on the other subscribers. If every subscriber for a given piece of data dies simultaneously, that data is gone.
Swytch Cloud adds distributed durable storage; writes land on disk, survive full-cluster restart, and the causal history is preserved. Your data still lives on your nodes; Swytch Cloud is the control plane that coordinates durability and cross-region reconciliation, not a hosted cache service.
If your failure model requires data to survive “everything is on fire at the same time,” you want Swytch Cloud. If your failure model is about individual node failures and recovering via the rest of the cluster, the default model is what you want.