|
|
|
|
|
|
by kilburn
2658 days ago
|
|
|
Translation: There are two "modes" of operation of this product: "regular" and "SPOT collections". In regular operation mode, the system will lose concurrent writes and cannot enforce ACID (the classical one) transactions. Your data is however highly available, eventually consistent and copied around the globe for faster access. With SPOT collections you get ACID transactions but lose the distribution advantages. That is, the system's properties are akin to what you get with a postgres/mysql cluster. It is an interesting product, but IMHO you should only go there if/when: your users are truly all over the world, and your system (or that part of it) requires few or no ACID transactions (think twice because this is a big one). PS: This seems to be a "productified" version of the gun [1] database (not that this is a bad thing!). Am I right? [1] https://github.com/amark/gun |
|
|
We think we provide the flexibility of both very strict acid behavior using spot collections Along with the strong eventual consistency model for everything else. Important to understand that as a developer you don’t need to deal with any of it - it’s handled for you once you have marked a collection as a spot.
This is not related to gun in any way. We love what gun does and it’s approach and they do some very clever things (including work on the end device). We sit as a back end database as a service in 25 global pops and process dB operations (and code expressed as functions or containers) at the closest location (by latency or geo physical location) to the user or device using an app or api rubbing against us.
we wrote our own operational CRDT engine And streams to solve this.