RxDB – a real-time database on top of PouchDB

The concept or RxDB, being able to iterate observables of your change stream, is great. Centering on schemas and typescript is as well. The broadcast channel based leader election also solved the common issue with Pouch where you can’t respond to real-time changes and update your UI if a separate tab was watching too.<p>It’s wise of them to also support pulling data from GraphQL. I built the first version of NoteBrook on top of couch&#x2F;pouch, and the biggest pain points were:<p>1. Pouchdb was before async&#x2F;await and typescript. The typings can be inconsistent, and it’s very difficult to properly manage the lifetimes of local databases because of the promise chaining.<p>2. A database technology for Real time replication Needs ACLs on a per-document basis. I built provisioning scripts to manage separate databases per user, as suggested, and it’s very cumbersome. It prevents me from lots of data sharing models like promoting one record to public view, or sharing a record with another user in a different tenant.<p>3. Personally I feel that the naming &#x2F; marketing of the product is poor. It does not feel professional ( couch, futon, fauxton, pouch, couchbase) do not feel like professional grade products I can depend on to run a business.<p>I think it would be good for RxDB to support its own backend technology and move away from PouchDB, and in the meantime, de-emphasize the relationship with PouchDB. The RxDB product doesn’t require you to use PouchDB and at this point it’s got a lot of buzz around it and doesn’t need that tie to PouchDB to continue.<p>I feel an ideal library would offer a real-time and offline client db, user auth, and billing, tied to a backend database of my choosing (eg. Postgres, MariaDB). The data layer should allow me to specify the durability requirements of each write (down to the specific entity type) and enforce an atomic commit on all related records in one transaction at the level of the most strict entity in the commit. It should be trivial to shard because the syncing protocol the clients use itself should be available to the server. Multitenancy should be built in. It should support real-time ephemeral in memory data for collaboration&#x2F;chat scenarios, with optional durability that’s eventually consistent. Schema definitions and migrations should be built in to the product.<p>If you have similar ideas and are interested in working with me on this project, or hearing more, drop me a line.

Looks amazing. I always loved how Rx composes with IO on the client side, this looks like the missing half. I hope it survives.<p>For people who are soon to be choosing a stack for their projects, please be careful. In 2015, we adopted RethinkDB which had very similar ambitions as RxDB and was open source. Unfortunately, RethinkDB is now abandoned (kinda). Many promising subscribe-able databases are still experimental. If you are thinking long-term, you may want to consider more boring options.

I love the idea of couchdb, but the ecosystem centers too much on pouch, which doesn&#x27;t have consistent maintenance. If Ibm was smart they&#x27;d sponsor it in a big way.

I&#x27;ve experimented with RxDB in a side project of mine, a spaced-repetition web app that is designed to be usable offline, with background sync between clients. The offline-first requirement meant using something like IndexedDB to store state client-side, which is where RxDB comes in.<p>Overall I like the library. It makes the hard task of interacting with IndexedDB a lot more pleasant. The GraphQL support is also a nice touch. Coupled with something like Hasura, it took me like a day to get sync working.<p>My one criticism with RxDB specifically is that the documentation around writing queries can be a bit hit-or-miss.

Title probably ought to be &quot;a <i>reactive</i> database&quot;. Though, used properly, you should be able to reduce latency it doesn&#x27;t make any guarantees.

Saw RxDB before but it feels too heavy for my small projects. Would try that if it can support leveldb&#x2F;sqlite as storage backend in the future.<p>My typical approach is directly logging onto fs with replaying upon restart for small projects, with fs based json store &#x2F; leveldb for more demanding tasks. For non-trivial scale projects, RethinkDB is a fair choice.

What&#x27;s the advantage of this over triggers in a relational database? Or even notify&#x2F;listen in PostgreSQL? (assuming these triggers are connected to the API, of course).<p>I guess it&#x27;s probably a matter of scale, but I really don&#x27;t know.

I don&#x27;t see any authentification related suff like pouchDB have, like create an user with password hash, auto handle cookie in the browser, restrict document to user or group.

But is it really &quot;realtime&quot;? I thought something should have consistent millisecond or even microsecond latencies to be called realtime, but it&#x27;s probably not possible for JavaScript application.

How is this different from Firebase RTDB? And perhaps more importantly, does it address the scalability and consistency issues associated with Firebase RTDB? Google introduced Firestore to Firebase specifically because RTDB has limited usability for larger real world applications that go beyond &quot;sync device state to DB&quot;.<p>Even the offline first paradigm is fundamentally flawed in general and certainly when it comes to offline data manipulation. Either you can afford to mutate your data on the local device and sync it when possible, in which case you clearly don&#x27;t need subscriptions to real-time mutations of remote data because within that scope you are the source of truth. Or, you&#x27;re interested in mutations of real-time data from multiple clients in which case you need to deal with conflict resolution (mutually exclusive changes of data) which is not reliably possible with this model and scalability (linear increase in pub&#x2F;sub * increasing query cost = exponential scaling).<p>Are there any large projects or companies that currently have this in production?