RxDB is a local-first, reactive NoSQL database for JavaScript applications, aimed at developers building offline-capable or realtime user interfaces who want client-side data storage and sync through their own backend rather than a hosted vendor.

What it is

RxDB (short for Reactive DataBase) is a local-first NoSQL database for JavaScript applications, first released in 2018 and written in TypeScript under the Apache-2.0 licence. Reactive means applications can not only query the current state but also subscribe to state changes, such as the result of a query or even a single field of a document. It lives in the JavaScript and TypeScript ecosystem and runs on every runtime that executes JavaScript, including browsers, Node.js, React Native, Capacitor, NativeScript, Flutter and Electron.

The concrete problem it solves is the split between client-side data and backend infrastructure. RxDB replaces the pattern of binding an application to one vendor's hosted database and SDK with a storage interface plus a sync engine. The storage interface lets the underlying storage engine be swapped out, so the same database code runs in different JavaScript environments by changing only the storage settings. The sync engine replicates with existing infrastructure: the protocol works by implementing three HTTP endpoints, and no specific cloud or backend database is required.

Key capabilities

• Reactive queries that subscribe to all state changes, including the result of a query or a single field of a document.
• Pluggable storage layer, with adapters for LocalStorage, IndexedDB, OPFS, LokiJS, Dexie.js, in-memory, SQLite, WebWorker threads, FoundationDB and DenoKV.
• Replication protocol implemented as three HTTP endpoints, plus production-ready plugins for GraphQL, CouchDB, Websocket, WebRTC (P2P), Supabase, Firestore, NATS and Google Drive.
• Schema validation through versioned collection schemas created with addCollections, using a primaryKey and typed properties.
• Query API in the find({ selector: { healthpoints: { $gt: 0 } } }).exec() style, returning results once or as a subscription.
• Feature plugin set covering attachments, encryption, compression, migration, ORM, conflict handling, CRDT, backup, replication server, middleware, logging, local documents, population and Signals.
• Database creation through createRxDatabase imported from rxdb/plugins/core, with storage imported separately from paths such as rxdb/plugins/storage-localstorage.

Who uses it and how

• Realtime multiplayer and collaborative applications that need subscriptions to query results and document fields for live UI updates.
• Offline-first mobile apps built with React Native, Capacitor, NativeScript or Flutter, where the client keeps a local database and syncs when connectivity allows.
• Electron desktop applications using RxDB as an embedded database on the client machine.
• Teams already running CouchDB, GraphQL, Supabase, Firestore or NATS backends that want replication instead of a backend replacement, by implementing the three HTTP endpoints or using an existing plugin.
• Node.js services that reuse the same database code as the client by swapping the storage setting, rather than maintaining separate data access code per runtime.

Getting started

Install with npm install rxdb rxjs --save, then follow the quickstart and install documentation at rxdb.info. No hosted service is required; the database runs against whichever storage adapter is selected for the target runtime.

How it compares

Among the tools named in its own topics and plugin list, Firebase, Firestore and Supabase supply a managed backend and cloud service, while CouchDB supplies a server database with its own replication protocol. RxDB sits on the client instead, storing data locally and replicating to those systems or to plain HTTP endpoints, which is how it avoids vendor and lock-in. The choice is about where data ownership and the sync contract live rather than about feature parity with a hosted backend.

When to use it — and when not to

A self-hoster must operate the replication backend, whether that means implementing and securing the three HTTP endpoints or running an existing CouchDB, NATS, Supabase or GraphQL service, and must also choose and operate one of the supported storage engines. Teams that want a turnkey managed backend with no client database code should not pick it, and projects that only need simple key-value persistence may find the schema, migration and replication machinery heavier than necessary. The README excerpt also defers most operational and scaling detail to the external rxdb.info documentation, so the repository itself is not the place to look for deployment guidance.

Last push to the repository is dated 2026-09-17, with 23,383 stars and 17 open issues.