TinyBase: a reactive in-memory store with persistence and sync for local-first apps

The problem TinyBase targets: state that survives a reload and a second device

A local-first app has to answer three questions at once. Where does the working copy of the data live while the user types? Where does it go when the tab closes? How do two devices agree on what the data is now? TinyBase packages those three concerns into one library: an in-memory store, a set of persisters, and a synchronizer. The package description in package.json calls it a reactive in-memory data store with persistence and synchronization for local-first JavaScript and TypeScript apps.

The audience is narrow and specific. If you are building a React, Solid, or Svelte interface over a small or medium dataset that should work offline, TinyBase is aimed at you. The topics list on the repository includes react, solid, svelte, local-first, crdt, and sync-engine, which matches the peer dependency list: react, react-dom, solid-js, svelte, yjs, and @automerge/automerge-repo all appear there. It is not a general-purpose database server. There is no daemon to run, no port to open, and no query planner.

How the store, persisters and synchronizers fit together

The architecture visible from package.json is a core with optional adapters. The core is the in-memory store, and everything else is a peer dependency that you install only if you need it. Persistence adapters named in the peer dependency list include @sqlite.org/sqlite-wasm, better-sqlite3, @capacitor-community/sqlite, expo-sqlite, react-native-mmkv, react-native-sqlite-storage, @libsql/client, @electric-sql/pglite, and pg. Sync and collaboration adapters include yjs, @automerge/automerge-repo, @vlcn.io/crsqlite-wasm, electric-sql, @powersync/common, @supabase/supabase-js, partykit, partysocket, and ws.

That list is the clearest statement of intent in the whole repository. TinyBase does not ship one storage engine and ask you to accept it. It ships a common store interface and lets the environment decide what sits underneath: IndexedDB in the browser, SQLite on a device, Postgres or PGlite on a server, Yjs or Automerge when you want CRDT semantics rather than last-write-wins. Because these are peer dependencies rather than regular dependencies, a React web app does not pull in better-sqlite3, and an Expo app does not pull in pg. The cost is that you assemble the stack yourself, and a missing peer dependency is a runtime error rather than an install-time one.

Installing TinyBase and wiring your first store

TinyBase installs from npm. The package is named tinybase, and the repository's package.json records the version as 9.7.1 with the MIT license. The install command below pulls the core package. The README does not give a separate install snippet for the framework bindings, but the peer dependency list shows react, react-dom, solid-js, and svelte as optional peers, so you add the one your app already uses.

npm install tinybase

The repository's package.json also declares "type": "module", so the package is ESM. The README does not include a runnable store example, so the exact createStore, setRow, and getRow call shapes are not reproduced here; the API reference lives on tinybase.org. What the repository files do establish is the dependency boundary. If you are on Expo or React Native, the relevant peer dependencies are expo, expo-sqlite, react-native-mmkv, and react-native-sqlite-storage. If you are on the server, the relevant ones are pg, postgres, @libsql/client, or @electric-sql/pglite. If you want CRDT sync, the relevant ones are yjs and @automerge/automerge-repo.

The install you should plan for is therefore two steps, not one. First install tinybase, then install the adapter package for the environment you are targeting. The repository does not document a single universal setup path, so expect to read the adapter-specific documentation on tinybase.org before wiring persistence. A missing peer dependency shows up at runtime rather than at install time, which is the practical consequence of the peer-dependency design.

Where TinyBase is the wrong tool

The peer dependency list is long, and that length is itself the limitation. TinyBase is a store plus a set of adapters, not a batteries-included database. If you want to install one package and have persistence work, you will not get that here. You will install the core, then decide between IndexedDB, SQLite, PGlite, Postgres, LibSQL, or a CRDT backend, and each of those has its own deployment story.

There is also a real question about dataset size. The package description says in-memory, and the name says tiny. An in-memory store loads its working set into the JavaScript heap. For a task list, a settings panel, or a few thousand rows of user data, that is fine. For an analytics table with millions of rows, the memory cost is the constraint, and a server-side database with query planning is the right answer instead. TinyBase gives you a reactive object graph, not a query optimizer.

The CRDT story is similarly delegated. The topics list includes crdt, and the peer dependencies include yjs and @automerge/automerge-repo, but TinyBase itself is not a CRDT document format. If your sync requirements are merge-heavy (collaborative text, offline edits that must merge without conflict), you are choosing Yjs or Automerge and using TinyBase as the store around them. If you need conflict-free merging as the core primitive, a CRDT-first library is a better starting point than a store that adds CRDT adapters.

TinyBase compared with a CRDT-first library

The natural alternative for a local-first JavaScript app is a CRDT-first library such as Yjs or Automerge used directly. The difference is what sits at the center. In Yjs, the document is the primary object, and everything else (awareness, providers, bindings) hangs off it. In TinyBase, the store is the primary object, and CRDT libraries are peers you attach when you need them. That means TinyBase gives you a table-and-cell model with reactive subscriptions, which maps more directly onto application state than a shared document does. Yjs gives you a merge model that is correct by construction for concurrent edits, which maps more directly onto collaborative editing.

If your app is a form, a dashboard, or a list of records where the last write usually wins, TinyBase's model is closer to the problem. If your app is a shared text editor or a whiteboard where every keystroke must merge, starting with Yjs or Automerge and treating the store as a derived view is less work than the reverse. The peer dependency list shows both paths are available inside the same project, which is the honest answer: they are not mutually exclusive, but only one of them should be the source of truth.

Maintenance, releases and the MIT license

The repository is not archived, and the last push was on 2026-09-20. Recent releases listed are v9.7.0 on 2026-09-03, v9.6.0 on 2026-08-30, and v9.5.1 on 2026-08-15. The minor version numbers move, and the release cadence is frequent enough that you should read releases.md before upgrading rather than assuming a patch release is inert.

The upgrade cost is tied to the peer dependency list. TinyBase declares narrow version ranges for its peers, for example react ^19.2.8, svelte ^5.57.0, better-sqlite3 ^13.0.3, and zod ^4.5.4. When you upgrade TinyBase, you may also have to upgrade the adapters you installed, because a peer range that moves can push you onto a new major version of React, Svelte, or a database client. Budget for that.

The license is MIT, recorded in both package.json and the LICENSE file. MIT is permissive: it allows commercial use, modification, and redistribution with the license text preserved. It does not grant patent rights explicitly and it comes with no warranty. That is a general description of the license, not legal advice; check with your own counsel if the distinction matters to your organization. The peer dependencies carry their own licenses, which are not the same as TinyBase's, so a dependency audit should look at the whole tree rather than just the top-level package.

Editorial conclusion

Adopt TinyBase if you are building a browser, React Native, Expo, or Svelte app that needs a reactive in-memory store with optional persistence and sync, and you are willing to install only the peer dependencies for the backends you actually use. Do not adopt it if you need a server-side relational database with query planning or a full CRDT document model out of the box. Before committing, verify that your target backend appears in the peer dependency list, check the release notes for the version you install, and confirm that the store, persister, and synchronizer APIs match the shape your app expects.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. tinyplex/tinybase on GitHub