This looks cool! We actually built something conceptually similar to this for the Nylas N1 mail client (https://github.com/Nylas/N1) and open sourced it with an (unfortunately) very similar name: https://github.com/bengotow/electron-RxDB.

Curious if the author has made any optimizations around the observable queries to prevent small changes to the database from re-running everything? We had to do a bunch of optimizations so that changes would only cause queries to re-execute when absolutely necessary. Our case might be extreme though - the mail client has several GBs of mail data in SQLite and 50+ observable queries for different parts of the UI.

We've been doing performance with http://gun.js.org/ as well on reactive push-based data sync, here are some of our results: https://github.com/amark/gun/wiki/100000-ops-sec-in-IE6-on-2... .

I would be very interested in chatting with more people (I see the Realm comment as well) about this stuff. Maybe we could do a podcast on JS databases and perf. (Here are my JS perf findings: https://www.youtube.com/watch?v=BEqH-oZ4UXI )

We did something similar using Realm (granted it was in a native mobile app, but I think they have a node port now) and it really kicked ass performance wise even with a boatload of observable queries.

I wish whoever posted this would explain what it really is, especially addressing how it compares to alternatives regarding scope and performance...

Yep. Theres a big need for something like Firebase but with support for arbitrarily fancy queries.

Take a look at PouchDB and Hood.ie

This project appears to be built atop PouchDB fwiw!

How do you handle the fast producer (query result) - slow consumer problem without any kind of backpressure? I would love to see an implementation based on channels (js-csp , core.async..).