Comment by rudi-c

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!