LiveStore: State management based on reactive SQLite and built-in sync engine

Hi folks, creator of LiveStore here (prev. founder Prisma).

Very excited to launch LiveStore in beta today after having worked on it over the past 4 years. I've built it for myself working on Overtone, an ambitious music client aiming for a native-grade high-performance app feel.

LiveStore embraces SQLite by adding a signals-based reactivity layer and combines it with event-sourced based syncing (similar to Git).

Happy to answer any question! Looking forward to thoughts and feedback!

Just saw the talk on it at Local-first Conf. So many snyc engines these days. LiveStore is exploring an interesting space in the idea maze: marrying event sourcing with sync engines.

I couldn't believe how robust LiveStore is already. I've been trying it out for a new project over the last few weeks and it's so smooth.

Congrats on the launch!

Would this fit into the "1. Serialization" strategy described here? https://mattweidner.com/2024/06/04/server-architectures.html...

If so, would it run into the same issue ProseMirror-collab did as mentioned in the article? As in: A frequently updating low-latency client can lock out another high-latency client's updates.

A recent episode of the excellent LocalFirst.fm podcast (hosted by the author) explores LiveStore a bit, https://www.localfirst.fm/24

seems you are using wa-sqlite. Can you elaborate on your strategy for persisting data offline? are you using opfs(which variant AccessHandlePoolVFS?) or indexddb? Also how are you mitigating against unstable implementation of opfs in different browsers and 7 day retention policy of safari for indexeddb?

since sqlite now also provides official wasm builds why did you decided to go with wa-sqlite?

This looks very promising but I'm a bit cautious not to fall in an hype trap.

I was experimenting with something similar for a custom local-first app with multi device support.

Would it be possible to add optional E2E encryption to this? While reading the docs, by adding encryption to the event payload you would be almost there already, even though it would prevent log compaction on the server

Sounds very cool. Not impressed with the cross platform claim when the first thing I see is that android web is not supported, though.

This looks amazing! One small thing I noticed: I was watching the demo video on the landing page and at 1:07 your voice inexplicably pans almost completely to the left speaker - not a big deal but figured I'd apprise you of it.

Neat to ship dev-tools alongside, looks like you've been dog-fooding this library for quite some time.

What are your thoughts on:

- Handling compaction for long lived apps/pages?

- IMO events are nice, but also require discipline and good design w.r.t code (Thinking of how application layer evolves over time, possibility of maintaining code for older client versions and/or schema migrations.

- Overtone looks sick. I've been using Spotify less and less because of janky UI and constant UI changes, would love a replacement. I see that it supports multiple sources, will it offer offline playback?

I like this architecture because I like event sourcing. But you have to be careful with event sourcing. There are schemas where the views you want to materialize are slow to materialize, and anyways as the data grows the materialization gets slower. What to do? Well, the developer just has to write triggers (or equivalent) to update the materialization in-transaction, and you have to do this when doing replication / synchronization. And you need to think carefully about collision resolution -- basically you need to read up on CRDT a fair bit then think about it.

It would be really nice to have a SQLite3-like database with PG language functionality so that one could do local-first and remote-first as just a configuration setting.

LiveStore is the only sync engine I’ve used for Expo / RN that actually just works out of the box. In a space that is seemingly mature it’s nice to see something polished and I’m excited to see how it develops over the next year!

Landing page is awesome! Love the way you demo the software. This is a crowded space with Zero/Convex/Tinybase etc and others so this is a great way to stand out.

Interesting - a lot of problems I face seem to fit into this general framework, and I feel like I keep reinventing the wheel. How is conlict resolution handled?

Interesting to see Signal-based reactivity on the backend! I wrote a Signal library for Python [1] and was thinking about what could be done with it.

[1] https://github.com/buiapp/reaktiv

This looks like interesting technology! Congrats on the launch, it's great to have people exploring the space of realtime data storage & sync. Some thoughts, that I hope you can find constructive.

The landing page draws comparison to Figma, Linear and Notion. But they are vastly different use cases.

Figma is document-centric, which means that:

- All data is tied to a single document, limiting their size.

- Requires that single backend session holds a document in-memory and deals with split-brain issues.

- Operational complexity arises around deployment.

- User interactions are often continuous (one event / frame), imposing tighter latency requirements.

- Generally requires that the document stays loaded in a memory in a stateful backend session.

- Technologies like Jamsocket are targeting such use cases.

Notion & Linear, on the other hand, have collaborative editing but not to the same degree of realtimeness. - Data is not tied to a single document.

- Data can grow unbounded.

- Data is typically more relational.

Presenting both these uses cases adds confusion. By using SQLite (emphasis: database and "SQL"), it makes the technology appear at first glance more suited for the Linear/Notion use case. However, the opposite appears to be true after reading https://docs.livestore.dev/evaluation/when-livestore/.

- "All the client app data should fit into a in-memory SQLite database".

- "Reasons when not to use LiveStore" -> "Your app data is highly connected across users".

The Figma-like document use case does seem like something that LiveStore could support. When it comes to designing a data model for collaborative apps (CRDT or CRDT-like), the most simple and flexible solution is to store every object as a map of [Object ID] -> [Property Name] -> [Property Value]. Assuming that the properties names & values come from a fixed set and are typed (this will generally be true unless you allow for arbitrary user-defined fields), that looks like a database row! So why not just store it in a database, indeed.

However, among databases, there are object stores and relational databases. The latter is useful, as applications often want to represent relationships between different objects. But if we support multiplayer-like use cases which implies the absence of server-side transactions, how should conflicting events involving the creation/deletion/relationships between objects be handled? Is it entirely on the application to think about it? This is an interesting topic that I believe LiveStore seems well-positioned to innovate in.

I also find the "local-first" emphasis to be at odds with all of Figma/Notion/Linear. Local-first software tends to have a limited number of concurrent users accessing the data in-mind. SaaS applications that are truly targeted at collaboration tend to have a lot of different requirements. On the other hand, those applications do tend to have relatively limited offline support, which a local-first application tends to emphasize more.

The Figma-like use cases also has additional requirements. But I understand this is beta and look forward to seeing further development!

Does anyone know how this compares to e.g. instantdb under real-world workloads?

im fairly new to sync engines. Im working on a journal software, and i want it to be local-first. is using livestore great for that?

...incurabel...next!