We built a distributed DB capable of running across 100s of global locations

Great work. Building a distributed database isn't easy at all and takes considerable effort. I'd like to see more on failure scenarios. Here's a few preliminary questions I have (admittedly, I haven't read the entire post, apologies if my queries are answered already):

What is the SLA for durability and availability of the db?

- how are scenarios like edge locations going down for multiple minutes handled? Are the writes lost?

- how many replicas of data at a single edge location?

- Are there limits on the table size (how does one enforce this in a multi-master mode)?

- what's the SLA on replication time to say, at least 50% edge locations, and then to 100%?

Are DDL operations allowed? If so, how are the conflicts handled?

If data is stored in LSMs underneath, how are geo location queries handled? Is there an index/materialised view? If so, how long does that take to generate?

What's the TPS/QPS supported for the KV interface?

- Is there a scenario where a set of operations at X TPS across edge locations might then take a long time to converge globally?

It'd be great if you can list down scenarios where the db can lose write to 'true conflicts' in a FAQ somewhere.

- For instance, what happens in a create-delete-create scenario where a table is created at one edge location, deleted at another, created at a third edge location; all the while when there's writes and reads happening globally?

Thanks.

Where do I create an account?

I would say it’s fairly easy to read. Easier to read than the article. Don’t shoot the messenger.

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

So, does it actually have CRDT operations? Doesn't seem like any of the interfaces expose them. Can you use a convergent counter, for example?

Also product page [1] has some weird claims. There is no such thing as "Strong Session Consistency", this is just another name for weak consistency guarantees. And Strong Eventual Consistency, which is a thing, requires using mergeable conflict-free operations that you don't seem to expose? The "smart operation ordering using intent prioritization" is also neither strong eventual consistency nor strong consistency.

[1] https://www.macrometa.co/product