# LiveStore: a reactive SQLite data layer with event-sourced sync > LiveStore replaces client state libraries with an embedded SQLite database, a reactive query layer and an event-sourcing sync engine. It is aimed at local-first apps that must work offline and merge changes across clients. **livestorejs/livestore** — LiveStore is a next-generation state management framework based on reactive SQLite and built-in sync engine. - Repository: https://github.com/livestorejs/livestore - Website: https://livestore.dev - Stars: 3,714 · Forks: 147 - Language: TypeScript - License: Apache-2.0 - Published: 2026-09-23 · Updated: 2026-09-23 · Language: en - Canonical page: https://hysenlabs.com/projects/livestorejs-livestore ## The gap LiveStore targets: client state that must survive offline and sync Most client state libraries keep a serialized tree in memory and ask you to write reducers, selectors and cache invalidation by hand. LiveStore takes a different starting point: the client owns a real SQLite database, queries run against it reactively, and changes travel between clients as events rather than as whole-state snapshots. The README frames it as a "fully-featured, client-centric data layer (replacing libraries like Redux, MobX, etc.) with a reactive embedded SQLite database powered by real-time sync (via event-sourcing)". The audience is narrow but real. You are building a web, mobile, desktop or edge app where the UI must respond to local writes instantly, where the network is unreliable, and where two devices may edit overlapping data. If your app is a thin form over a REST endpoint, this is more machinery than you need. The repository ships example apps for exactly this profile, including examples/web-todomvc-sync-cf, examples/web-email-client and examples/web-linearlite. ## Event sourcing plus materializers: how a write becomes a query result The README lists six steps in the data flow. Queries hit the local SQLite database through a built-in query builder or raw SQL. A change is committed to the store and applied immediately. Change events are persisted locally and synced across clients and across tabs. Those events are then applied to the local database by materializers. Query results update reactively and synchronously in the next render, and the sync backend propagates the change to other connected clients. The consequence is that the event log, not the database, is the source of truth. The SQLite tables are a projection that materializers rebuild from events. That design buys custom merge conflict resolution, which the README lists as a feature, and it makes offline edits first-class: an event written while disconnected is just an event that has not been synced yet. The cost is that schema changes and materializer logic are coupled. If you change how an event is applied, existing clients that already materialized the old way need a path forward, and the README does not describe a migration story for materializers. ## Installing LiveStore and running a first reactive query The README does not give an install command. It points to framework-specific getting-started guides for React Web, Expo, Node and Vue under docs.livestore.dev, so the package names and setup steps live there rather than in the repository root. What the workspace does confirm is the package layout: the scoped packages under packages/ include @livestore/livestore, @livestore/react, @livestore/adapter-web, @livestore/adapter-cloudflare and @livestore/sync-cf. If you want to run the repository itself, the compose.yaml file defines a single development service that builds from the local Dockerfile, bind-mounts the checkout at /workspace and drops you into bash. The Dockerfile pins Node 24 and Bun 1.3.13 as the known-good toolchain and installs the package manager declared in package.json, which is pnpm@12.4.1. The Dockerfile also shows the commands CI runs inside that image: ```bash ./scripts/bootstrap-minimal.sh pnpm exec tsc -b packages/@livestore/livestore --pretty false pnpm --filter @livestore/common exec vitest run pnpm --filter livestore-example-web-todomvc run build pnpm --filter livestore-example-cloudflare-todomvc run build pnpm --filter @local/docs run check ``` For a real application, follow the React Web or Expo guide for your target, since those are the entry points the README links. Expect to define a schema, register materializers, and wrap your app so components can subscribe to queries. The examples directory is the fastest reference: examples/web-todomvc-sync-cf is a TodoMVC wired to Cloudflare sync, and examples/web-todomvc is the local variant without a sync backend. ## Where LiveStore is the wrong tool The version numbers are the first limitation. The most recent release is v0.5.0-dev.0 from 2026-08-24, a dev tag. The last non-dev release is v0.4.0 from 2026-06-02. A 0.x line with dev prereleases means the API can move between minor versions, and the repository's use of Changesets (the .changeset/ directory and the changeset, changeset:version scripts in package.json) confirms that releases are cut deliberately rather than continuously. If your team cannot absorb breaking changes on that cadence, this is not the data layer for you yet. Sync is the second boundary. The README says you can "Sync with a supported provider or roll your own", and it links to a sync-provider page whose example is Cloudflare. The repository backs that up: packages/@livestore/sync-cf and packages/@livestore/adapter-cloudflare exist, and examples/web-todomvc-sync-cf is the wired example. If you need a hosted sync service from a different vendor, the README does not name one. Rolling your own means implementing the sync protocol yourself, and the README does not describe that protocol's wire format. Finally, the client-centric model means every client holds a full SQLite database. For a dataset that is small per user this is fine. For a dataset that is large and shared, the materialized projection on each device is the thing to think about before you start, and the README offers no guidance on size limits. ## LiveStore compared with Zero and other local-first stacks The comparison people search for is LiveStore versus Zero, and the difference is architectural rather than cosmetic. LiveStore is event-sourced: writes are events, events are persisted and synced, and materializers project them into SQLite. The README's own framing is that events are "instantly applied to the local database via materializers" and that the sync backend then propagates changes to connected clients. A query-sync approach such as Zero starts from the query: you declare what you want, and the sync layer keeps that result set fresh. LiveStore starts from the event and derives the tables. The practical split shows up in conflict handling and in history. Event sourcing gives you an append-only log you can replay and custom merge conflict resolution, which the README lists as a feature. It also means the database is a derived artifact, so a bug in a materializer is a data-shape bug, not just a rendering bug. If you want the database to be the primary record and queries to be the sync unit, a query-sync tool is closer to that mental model. The repository also ships a technology-comparison page under docs.livestore.dev/evaluation/, which is the place to check before deciding. ## Licence, maintenance and the cost of upgrading LiveStore is licensed under Apache-2.0, and the repository carries a LICENSE file at the root. Apache-2.0 is a permissive licence with an explicit patent grant, which matters if you are shipping a commercial product on top of it. It does not oblige you to publish your application code. This is a description of the licence text, not legal advice; have counsel review it if the patent or notice clauses affect your distribution model. On maintenance: the repository is not archived, and the last push was on 2026-09-23, so development is current. That says nothing about API stability, and the release history is the better signal. Between v0.4.0 on 2026-06-02 and v0.5.0-dev.0 on 2026-08-24 the project moved to a new dev line, which is the pattern to plan around. The upgrade cost is concentrated in two places: the schema and materializer definitions, and the adapter packages. Because the database is a projection of events, a schema change is not just a migration script, it is a change to how events are applied. Pin an exact version, read the CHANGELOG.md entry for the release you are moving to, and treat the dev tags as previews rather than as targets. ## Conclusion Adopt LiveStore when your app needs an offline-first data layer with SQL queries and cross-client sync, and when you can accept a 0.x API. Do not adopt it if you need a stable release line or a sync backend beyond the documented providers. Before committing, verify three things: that a sync provider on the docs list fits your deployment, that a platform adapter exists for every target you ship, and which package version you are pinning, because the newest release is v0.5.0-dev.0 from 2026-08-24 while v0.4.0 from 2026-06-02 is the last non-dev tag. ## FAQ ### How do I install LiveStore? The README does not give an install command. It links to getting-started guides for React Web, Expo, Node and Vue at docs.livestore.dev, and those guides are where the setup steps live. The repository itself is a pnpm workspace with the packages under packages/, including @livestore/livestore and @livestore/react. ### What is LiveStore? It is a client-centric data layer that replaces libraries like Redux and MobX with a reactive embedded SQLite database, according to the README. Changes are persisted as events, synced across clients, and applied to the local database through materializers. It supports offline-first workflows and custom merge conflict resolution. ### Is there a LiveStore alternative? The repository includes a technology comparison under docs.livestore.dev/evaluation/, which is the project's own account of how it differs from other approaches. The architectural distinction it draws is event sourcing: writes are events that materializers project into SQLite, rather than query results being the unit that syncs. ## Sources - [License: Apache-2.0](https://github.com/livestorejs/livestore/blob/main/LICENSE) - [livestorejs/livestore on GitHub](https://github.com/livestorejs/livestore) - [Project website](https://livestore.dev) - [README](https://github.com/livestorejs/livestore/blob/main/README.md) - [Releases](https://github.com/livestorejs/livestore/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/livestorejs-livestore