When to use LiveStore (and when not)

Choosing a data layer for a local-first app is a big decision and should be considered carefully. On a high level, LiveStore can be a good fit if …

• you are looking for a principled data layer that works across platforms
• you want to use SQLite for your queries
• you like event sourcing to model data changes
• you are working on a new app as LiveStore doesn’t yet provide a way to re-use an existing database
• the current state of the project aligns with your own timeline and requirements

Evaluation exercise

A great way to evaluate whether LiveStore is a good fit for your application, is by trying to model your application events (and optionally state) schema. This exercise can be done in a few minutes and can give you a good indication of whether LiveStore is a good fit for your application.

Example: Calendar/scheduling app

Let’s say you are building a calendar/scheduling app, your events might include:

• AppointmentScheduled
• AppointmentRescheduled
• AppointmentCancelled
• ParticipantInvitedToAppointment
• ParticipantRespondedToInvite

From this you might want to derive the following state (modeled as SQLite tables):

• Appointment
  • id
  • title
  • description
  • participants
• Participant
  • id
  • name
  • email

Great use cases for LiveStore

• High-performance desktop/web/mobile apps
  • e.g. productivity apps like
• AI agents
• Apps that need …
  • solid offline support
  • audit logs

Benefits of LiveStore

• Unified data layer combining local reactive state with globally synced data
• Easy to …
  • reason about
  • debug
  • test
  • evolve
  • operate

Reasons when not to use LiveStore

• You have an existing database which is the source of truth of your data. (Better use Zero or ElectricSQL for this.)
• Your app data is highly connected across users (like a social network / marketplace / etc.) or modeling your data via read-write model separation/event sourcing doesn’t seem feasible.
• You want to build a more traditional client-server application with your primary data source being a remote server.
• You want a full-stack batteries-included solution (e.g. auth, storage, etc.). (Technologies like Jazz or Instant might be a better fit.)
• You don’t like to model your data via read-write model separation/event sourcing or the trade-offs it involves.
• You’re a new developer and are just getting started. LiveStore is a relatively advanced technology with many design trade-offs that might make most sense after you have already experienced some of the problems LiveStore is trying to solve.
• You want to keep your app bundle size as small as possible. LiveStore adds a few hundred kB to your app bundle size (mostly due to bundling SQLite).

Considerations

Database constraints

• All the client app data should fit into a in-memory SQLite database
  • Depending on the target device having databases up to 1GB in size should be okay.
  • If you you have more data, you can consider segmenting your database into multiple SQLite database (e.g. segmented per project, workspace, document, …).
  • You can either use the storeId option for the segmentation or there could also be a way to use the SQLite attach feature to dynamically attach/detach databases.

Syncing

LiveStore’s syncing system is designed for small/medium-level concurrency scenarios (e.g. 10s / low 100s of users collaborating on the same thing for a given eventlog).

• Collaboration on multiple different eventlogs concurrently is supported and should be used to “scale horizontally”.

Other considerations

• How data flows / what’s the source of truth?