Skip to main content
Swytch Documentation
Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Back to homepage

Swytch

Distributed databases have a leader problem.

Almost every one you’ve used elects a primary for each piece of data and sends writes there. It’s a sound design. It’s also the reason your European users wait on Virginia, your writes stall during failover, your partitions escalate to incidents, and your “multi-region” deployment secretly has a favorite region.

Swytch is built the other way. No leader. No consensus protocol. No coordinator to keep alive. Writes commit synchronously to the nodes subscribed to the data; reads are answered locally once a node has subscribed. Every node accepts writes. Every node serves reads. The database is serializable, and every node arrives at the same ordering decisions without talking to each other to agree.


Two faces, one cluster

Swytch runs in one of two modes, chosen when you start a node:

  • Redis mode speaks RESPv2 and RESPv3. Drop it in where Redis runs today.
  • SQL mode speaks the PostgreSQL wire protocol. Your Postgres drivers connect without changes. The SQL they send must be valid SQLite, which is what Swytch uses as its query engine underneath.

Who uses Swytch

Global ticketing and events. A venue loses its uplink five minutes before doors open. The POS keeps running, check-ins keep flowing into the local Swytch node, and when connectivity returns the main cluster learns exactly who walked in and when. No “please wait while we reconcile.” No ops paging.

Remote industrial and field operations. An oil platform loses its satellite link during a storm. Sensor readings, maintenance logs, and shift data keep writing locally for six hours. The uplink returns, the causal log catches up, and nothing was lost because nothing was waiting on a central writer that couldn’t be reached.

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. A system with 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 supports multi-region Active-Active via CRDTs, but Redis’s own documentation is explicit that list pops are at-least-once: “Lists in Active-Active databases guarantee that each element is POP-ed at least once, but cannot guarantee that each element is POP-ed only once.” Their recommendation is to route all POPs to a single instance — essentially giving up the Active-Active property for queue workloads. Swytch’s envelope-commit gives you exactly-once delivery across regions, actively. Paid in one cross-region RTT per operation when subscribers are in different regions, not in the post-incident cleanup of duplicate processing.

Multi-region SaaS. A product with customers in three continents needs every region to write at local latency and read at local latency. Region-local tables (user profiles, per-region operational data) commit without touching other regions. Globally shared tables (account-level config, billing status) commit only to the nodes that actually care, on the timetable those nodes require.

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. Wherever 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 or single-primary SQL database 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.


Where to go next