Local-first software, a paradigm emphasizing data sovereignty and network-independent functionality, is rapidly emerging as a cutting-edge trend in technology. The expanding ecosystem of frameworks and libraries makes it hard to choose the right tool for a job. Let's talk about the choices developers have.

Evolu vs Custom Solution

Let's face it. Developers love to create new things from scratch. "Not Invented Here" syndrome is real. But sometimes it's also necessary, especially when we have special requirements.

I decided to create Evolu because I made a few local-first apps, but I spent too much time on data persistence and synchronization details with each of them. Typically, I started with the front end and had much fun until I had to implement a server. Local-first apps are effectively distributed systems, and distributed systems are one of the most challenging topics in computer science.

Just try to google "app sync problem," and you will see that even the most prominent companies fail to deliver reliable software. Apple Notes, for example: "11 Ways to Fix Apple Notes Not Syncing Between", "Notes Not Syncing Across Devices", and many more. If it's hard for Apple, how hard will it be for smaller companies?

Creating a custom solution is possible but requires a deep understanding of distributed systems. Did you know that computer clocks can go backward? What should happen if the user edits the same data on two different offline devices? Can we enforce database constraints like transactions? And what about database schema changes? Should we migrate all data? How can we ensure outdated clients can work with new data or don't crash, at least? And that's only the tip of the iceberg. A local-first platform should work with all desktop, mobile, and native platforms.

And the last and most crucial question: What will happen when the author of a custom solution leaves the company?

If someone still decides to write the most straightforward working code, they will end up with something similar to Evolu minus years of Evolu evolving.

Evolu vs ElectricSQL

It's not secure by default and stable yet. It also requires a proprietary server. I like what ElectricSQL (opens in a new tab) does, but it is not local-first as described in the essay (opens in a new tab). If ElectricSQL goes out of business and shuts down its servers, I wonder if an external developer will maintain their sophisticated open-sourced sync service written Elixir. It is not impossible, but there is another problem. The ElectricSQL server is not generic by design. It's not a bug; it's a feature, but the feature that is making ElectricSQL a non-local-first. Evolu is different. The Evolu Server is actually a simplified Evolu Client generic for all Evolu applications. Zero-configuration and nothing to maintain.

Evolu vs Vulcan Web (CR-SQLite)

TLDR: It isn't stable yet and is not secure by default. TODO: Compare CRDT approaches.

Evolu vs Loro and other SQL-less CRDTs

Evolu CRDT is built on SQLite, which gives it SQL queries and scalability. CRDTs can also be made with custom data structures, often for particular purposes like rich text data. Custom data structures can be super efficient and fast, but they're not SQL anymore. As always, choosing the right tool depends on requirements. Evolu was made for general-purpose apps where SQL is a must. We observe the competition among SQL-less CRDTs and will choose the winner (or make our own).