What's the difference between this and AWS' DynamoDB, or Aurora if you prefer RDBMS? A HTTP endpoint as the DB API? Seems like a lot of extra overhead, unless you're hosting a "client-only" webapp (which would previously have used Firebase, IIRC).
Also, this confuses me:
> FaunaDB can tolerate the loss of a minority of physical datacenters in a cluster without interruption. According to the CAP theorem, FaunaDB is a CP system.
CP means that consistency is favored over availability, yet "without interruption" tells me they favor availability over consistency during a partition.
If a partition leaves a quorum in contact with each other, why would it cause an interruption? CP means nodes not within a quorum become unavailable, and if a quorum no longer exists the whole system is unavailable. AP means minorities stay available at the risk of inconsistency.
> If a partition leaves a quorum in contact with each other, why would it cause an interruption?
You can have a split that still has a group of machines with quorum: a 3/2 split would leave three nodes with quorum, and two without.
Clients which attach to the non-quorum machines would lose the ability to read or write if it's CP, yet the clients connected to the quorum machines would retain the ability to read and write. So it would be a partial outage, until some way is found to identify quorum members and route clients back to that quorum (making the assumption that clients could talk to any node in a partition).
Looks like the fact it automatically scales horizontally: with Aurora, you can only scale vertically (in terms of memory and compute), and DynamoDB requires you to manage throughput yourself (not a big deal; there are services to automatically raise and lower it based on usage).
Without interruption -for a minority of nodes-. Meaning it's using a quorum to achieve consensus. In the event of partition (which looks the same to the remaining nodes as a 'loss'), the majority side will still allow reads/writes. Meaning if you can't talk to the majority, you can't read/write; hence, not AP. If it maintains distributed consistency provided there's a quorum (Raft, Paxos, etc), it's CP.
> Looks like the fact it automatically scales horizontally
I'd be curious then what the cost for doing a lookup of data not on your current node would look like. Do you re-connect to a different node which does have the data, or is it transparently piped back to your current node on request? Is that request broadcast, or is there some form of index maintained on each node of who has what data, how is the cross-talk structured... I'm a bit of a DB nerd, so the answers to these interest me.
> Meaning it's using a quorum to achieve consensus.
I missed the sly usage of "minority" there. I was expecting a quorum based architecture based on the rest of the documentation.
It seems dishonest to imply that there is "no interruption" at all on partition, since that's obviously not the case.
The operations model is similar to most cloud databases, with metered usage. You just configure your app to use the database, and the scaling is handled for you.
FaunaDB has a strong consistency, a relational data model and rich queries. This makes it more like a traditional SQL operational database, except it scales.
We are focussed on winning customers, but we've been happy to see we can turn heads at large scale shops running real installations of the usual suspects. We'll publish something like what you are asking for soon.
In these evaluations we are running on production data so we can't share them directly.
What do you think about something like this for generating a reasonable data set?
Also, this confuses me:
> FaunaDB can tolerate the loss of a minority of physical datacenters in a cluster without interruption. According to the CAP theorem, FaunaDB is a CP system.
CP means that consistency is favored over availability, yet "without interruption" tells me they favor availability over consistency during a partition.