[daleharvey]

I work on PouchDB, in terms of those points:

"great client-side performance": PouchDB is more than fast enough for most use cases, its just a wrapper over indexedDB. (there are areas we can improve, particularly performance of map reduce / mango queries).

"native models that are extremely easy to use": Not sure what that means, PouchDB and CouchDB use json, its native and easy to use in JavaScript

"conflict-free sync (not conflict resolution!)": Certainly going to have to take a look at this, any conflict free sync protocol I have seen put a lot of limitations on how data within your application is structured but conflict resolution certainly is something that can be improved within Pouch / Couch.

I do think there is a bunch we can (and are) improving in PouchDB and its great to see alternatives, will be looking into this further now. But I certainly do not agree that (C|P)ouchDB are not suited for mobile <-> web sync, thats the primary use case I work on Pouch for.

[nolanl]

(I also work on PouchDB.)

For "conflict-free sync," according to the docs, this appears to be last-write-wins along with a special case for deletes: https://realm.io/docs/realm-object-server/#conflict-resoluti... . (Incidentally Couch/Pouch also has a special case for deletes, but it does the opposite behavior by default – deletions lose to updates.)

There's also some language in here about how "insertions in lists are ordered by time;" I'd be curious to know how they coordinate clock times across nodes. Ditto for "last update wins" – important to know how "last" is determined.

In general, I tend to be skeptical of systems that hinge on last-write-wins, but LWW is definitely a model that works in a lot of cases where you're not too concerned about the possibility of losing data, and it's also a simpler mental model for the app developer.

[astigsen]

Realms approach to conflict resolution is very different from what you see in products like Couch. Realm is an _object_ database, so in contrast to document databases where conflict resolution happens very coarse grained at the document level, in Realm it happens at the object level (and actually all the way down into individual properties).

This essentially means that the entire object graph is treated as one big CRDT [0], transparently handling conflict across individual objects, properties and relations.

When talking about ordering by time, both in the context of LWW and insertions in lists, we are talking about vector clock time, not necessarily device time (or though that is taken into account as well).

[0] https://en.wikipedia.org/wiki/Conflict-free_replicated_data_...

[gritzko]

An-object-graph-as-a-CRDT is a really interesting concept. So far, I am not aware of any literature formalizing/studying it. I can only recall the recent CRDT JSON paper by Kleppmann et al, which is significantly less ambitious. Is your approach documented?

While reading the announce, my first guess was some recursive per-field LWW, but you mentioned vector clocks. That is intriguing.

[pfraze]

LWW is a tradeoff. You'll be better off selling it as an automated-resolution option on top of manual resolution, instead of an innovation over manual resolution. (MV registers are a CRDT as well!)

[relics443]

"native models that are extremely easy to use"

This means native code (specifically not JSON). So in Java you would be dealing with POJOs, etc...

[WA]

A bit OT, but I have to compliment the person who wrote the docs[1] for PouchDB. They're quite entertaining and easy to understand. Well done!

[1]: https://pouchdb.com/guides/

[nolanl]

Thanks, I'm that person. :) I tried to write it as a "missing manual" for Couch/Pouch, and had a lot of fun in the process! It needs some updates for newer stuff, though: pouchdb-find, custom builds, Chrome DevTools storage UI improvements, etc.