Swytch just released 1.6

[u/ReasonableLoss6814]

Disclosure: with the recent rules being changed, I debated whether to share this here. Swytch has been in R&D since 2019 and commercial for years, but only recently open-sourced earlier this year when my cofounder and I incorporated to land a large client. We're still open-sourcing parts of the commercial engine. We use AI where we can, but AI fails to work on Swytch properly as it falls back on 40 years of distributed systems that Swytch basically rejects. 2P commits aren't a thing. Leaders aren't a thing. Clock sync isn't a thing. Transaction aborts ... you guessed it, not a thing. So, mods, feel free to kill this post if you want.

Today, I'm happy to announce Swytch 1.6!

For anyone unfamiliar with Swytch, it's an open-source, Redis-compatible, leaderless distributed database. You can run it on one machine or across multiple regions in active-active mode, with serializable transactions and no CRDT shenanigans.

So, what's new?

First: interactive transactions.

You know how Redis returns QUEUED for commands inside MULTI?

With --ssi enabled, Swytch returns the actual results immediately, using a consistent MVCC snapshot.

You can read a value, make a decision in Go, Python, PHP, or whatever you're using, and issue additional commands before calling EXEC to commit.

No need to move your application logic into Lua just to perform a transactional read-modify-write. Lua is still supported if you prefer it.

Second: disk durability.

One of our most requested features since launching six months ago.

With --data-dir, Swytch can restore its local state after restarting, even if the network is unavailable.

This is particularly useful for edge deployments and offline-first applications.

A note: local disk durability isn't a backup. Swytch retains a mirror of resident effects, so we recommend Swytch Cloud for full-history backups and point-in-time recovery.

Third: choose how to handle network partitions. Per key.

Swytch defaults to safe mode, prioritizing consistency for transactions when peers become unavailable.

With 1.6, you can configure unsafe mode globally or for individual keys and key patterns.

Unsafe mode allows transactions to continue in disconnected parts of the cluster, with deterministic reconciliation when connectivity returns.

For some applications, losing availability is far more expensive than reconciling inconsistent data afterward.

Imagine a multiplayer game across several regions. Players should be able to keep exploring, collecting rewards, and playing even if regions become disconnected. But operations requiring stricter consistency, like trading a unique item, can wait for connectivity to return.

Swytch lets you make that decision per key instead of taking the entire game offline.

And when competing transaction histories are discovered after reconnecting, Swytch exposes conflict reports containing transaction evidence so your application can decide whether compensation is needed.

Finally: bug fixes.

So many bugs. As you'd expect.

We've been testing some particularly awful network topologies, and quite a few subtle consistency issues turned out to be one-line fixes.

The source is available here:

https://github.com/swytchdb/swytch

I'd love to hear what you think, especially if you're building something with Redis today.

[u/vivekkhera]

That looks pretty cool.