Is this at the cost of fast writes or flexible schema? The pitch video doesn't seem to mention any cons, yet seems to avoid mentioning the type of data or mutations supported. I guess I'll go read their publications.
It's at the cost of playing by the rules of CRDTs. Making CRDTs consequence-free is ongoing research.
What do you mean by that?
I found possibly related language on this page the other day [0]:
CRDTs are "[t]ypically not suited for editing application with consequent UI."
Can you point me in the right direction? My googling got me nowhere. Thanks.
[0] https://irisate.com/collaborative-editing-solutions-round-up...
In general there are tradeoffs to CRDTs and not everyone loves those tradeoffs. As time goes on we find CRDTs that make better tradeoffs.
For example, the earliest examples of CRDT sets grew linearly with the values added to the set, without regard for deletion. For all time. That's a pretty steep cost.
[1](https://github.com/SyncFree/antidote/blob/842874ca5ecffe947e...)
You can likely build something SQL-like to form complex queries coordinating related objects, but the efficiency of such queries is not a given. You can likely manually build something like an index to speed up lookups using e.g. the map primitive. With a plan for a complex query, you're on your own.
Another likely problematic part is PK generation. You can of course use a counter, but I'm not sure how efficient will it be with burst inserts. For that, you'd have to come up with client-generated PKs that are unlikely to clash, e.g. UUIDs.
There is a lot of research still going on in the back, including indexing, access control, verification tools for apps, and some other really cool stuff.
Efficient support for queries is non-trivial, indeed.