Technology comparison
TLDR of what sets LiveStore apart
Section titled “TLDR of what sets LiveStore apart”- Uses combination of reactive, in-memory + synced, persisted SQLite for instant, synchronous queries
- Based on event-sourcing methodologies
- Client-centric (with great devtools)
LiveStore is best compared along three categories: state-management libraries, backend-as-a-service platforms, and local-first sync layers for existing databases.
State-management libraries
Section titled “State-management libraries”LiveStore vs Redux
Section titled “LiveStore vs Redux”LiveStore shares a lot of similarities with Redux in that sense that both are based on event-sourcing methodologies. Let’s compare some of the core concepts:
- Redux actions are similar to LiveStore events: Both are used to describe “things that have happened”
- Redux views are similar to LiveStore’s state (e.g. SQLite tables): Both are derived from the history of events/actions.
- A major difference here is that LiveStore’s state materialized as a SQLite database allows for a lot more flexibility via dynamic queries and aggregations vs Redux’s static views.
- Redux reducers are similar to LiveStore’s materializers: Both are used to transform events/actions into a final state.
- Both Redux and LiveStore are client-centric.
- Both Redux and LiveStore provide powerful devtools.
While LiveStore can be used for the same use cases as Redux, LiveStore goes far beyond Redux in the following ways:
- LiveStore leverages SQLite for a more powerful state model allowing for flexible queries and aggregations with much simpler materialization logic.
- LiveStore supports client-persistence out of the box.
- LiveStore comes with a built-in sync engine syncing events between clients.
As a downside compared to Redux, LiveStore has a slightly larger bundle size.
Other state-management libraries
Section titled “Other state-management libraries”Zustand, Redux Toolkit (RTK), MobX, Jotai, XState, Recoil, and TanStack Query solve in-memory state management (or server-cache management) but not persistence, offline support, or cross-client syncing. The same comparison as with Redux applies: with LiveStore, state lives in SQLite, is derived from an eventlog, and syncs between clients out of the box.
Backend-as-a-service (Firebase, Supabase, …)
Section titled “Backend-as-a-service (Firebase, Supabase, …)”These platforms provide syncing but treat the server as the source of truth:
- Reads require network round-trips (or an additional caching layer)
- Offline support is limited or requires significant extra work
- You adopt their data model and pricing
LiveStore is client-centric: queries run synchronously against the local SQLite database, apps work fully offline, and events sync via a pluggable sync provider of your choice.
Local-first sync for existing databases (ElectricSQL, Zero, PowerSync)
Section titled “Local-first sync for existing databases (ElectricSQL, Zero, PowerSync)”These technologies sync an existing database (usually Postgres) to clients and are a great choice when that database is — and should remain — your source of truth. LiveStore instead assumes a new app where the eventlog is the source of truth from day one:
- Choose them when you need to keep an existing server database authoritative.
- Choose LiveStore when you want event-sourcing semantics (not just row-level sync) and the flexibility to materialize state in different ways.
Other local-first/syncing technologies
Section titled “Other local-first/syncing technologies”To compare LiveStore with other local-first/syncing technologies, please see the Local-First Landscape resource.