A comparison to PouchDB would make a great reference point to help people understand the use case. From what I can see in 2 mins of reading it looks like it's more relational which should be a plus, but then on the downside there's much less of a story on the sync side, with remote persistence ending at offering you interfaces to persist your data but not an actual data store that works. By comparison, PouchDB connected to a server side CouchDB makes an amazing combo.<p>I didn't have much trouble binding PouchDB into a Vue reactive data store so the reactive part didn't seem as novel to me. What does seem novel is supporting a proper relational schema for this, whereas all the other options I know in this space are schemaless / key-value type approaches.<p>I wonder if t might be a high-value / low effort proposition to come up with an out-of-the-box setup with something like PostgREST that would then work end to end? This was the super compelling part for me with the Pouch/Couch combo, as with a couple of configs and barely any code your browser localStorage is suddenly sync'd and saved remotely in real time which is mind blowing when you first experience it.
This looks really cool, love seeing more innovation in this space!<p>At first glance this seems to be mostly targeted towards single-user apps where each user would have their own database that can be sync'ed to a remote server, but still isolated from data for other users, similar to the CouchDB+PouchDB model?<p>At least it looks that way since I couldn't see anything around authorization and conflict resolution. Not that there's anything wrong with focusing on this use case, a lot of apps can function perfectly fine this way.<p>A few other interesting new players that use an optimistic local update + server validated mutation model to support collaboration:<p><a href="https://replicache.dev/" rel="nofollow">https://replicache.dev/</a><p><a href="https://clientdb.dev/" rel="nofollow">https://clientdb.dev/</a>
Ah, I was whining in the surrealdb thread for new advances in this space over couch/pouch (which we have been using for over a decade). Would be great to see comparisons, especially in areas where couch/pouch are bad and new solutions are better. We have not moved anywhere yet because couch/pouch, when you are used to it development wise, is automatic. You do nothing and it works. Other solutions we tried require way too much domain knowledge (which we have but don't want to think about when doing things we think should just automatically work, like synching; like replicache which is just too much work for us on our existing datasets) or are very hacky, as in, lose data and require you to write code to fix that.
Nice work. I love anything that makes local-first easier. I’ve been paying close attention to Dolt for this. In a perfect world I’d have the gut semantics from Dolt and EdgeQL from EdgeDB.<p>This focuses on the reactive feature - the ability to set listeners and get alerts. There seem to be some nice React integration, but haven’t built with React enough to immediately see what that unlocks.
I’m developing a local-first app and a game with Electron and I am using my own “data store” by simply storing serialized JavaScript object literals in localStorage. It works, but at times it’s a bit annoying and tedious to use, so I’ll definitely check this out.<p>My only other frame of reference for something similar is TaffyDB, though It would not call it “reactive”.
Pretty cool. I do a lot of game dev and have searching for solutions like CastleDB but built in the NodeJS ecosystem. This looks like it could check a lot of boxes for me.<p>What I want is to be able to define my tables with something like JSON schema, and automatically have the typescript typings available when querying. The data would be serialised to Git friendly json, and there would also be support for different media types which get saved and organised in the local file system.<p>For me, a game developer who wants to be very hands on with bespoke tooling/editor functionality, I only want a simple foundational base, something along the lines of Airtable, with the workflow centred around Git.
I looked into building something like this for a React Native app. (Actually I first considered the practicality of making a reactive version of sqlite... I decided it would be too complex and not something I'd want to use without upstream support).<p>We ended up doing something a bit more traditional/basic/manual, but this looks nice. It would definitely have been in consideration if it'd been available at the time, and I'll keep it in mind for future projects.
I've been looking for something like this but sadly I can't use it because I can't rely on JS. I wish there was some decent local-first event based db that was language agnostic. Very few projects are reactive/streaming.<p>If anyone's interested my current workaround is piping JSONL between my processes (and into files) and it works pretty well, but lacks more advanced features.
Respect to the authors of course, however I am not sure if it helps solving common data sync problems to introduce one more datastore with it´s own special query language. Maybe I am misunderstanding the use case.<p>I like <a href="https://orbitjs.com/" rel="nofollow">https://orbitjs.com/</a> very much - it puts the focus on the right area.
Personally built similar but incomplete solutions in my projects way more times that I’d like to admit.<p>Could you elaborate on your roadmap on CRDT / real time collaboration? If it’s in plan and will be executed correctly I’m completely sold.<p>Anyway, congrats, looks awesome.