freels

To be clear, read-write transactions are applied in a consistent order derived from the transaction log. Read-only transactions can rely on the fact that read-write transactions are totally ordered, and execute without global coordination while still providing a guarantee of serializability. Wall clock time is used as a suggestion only, in order for the database's logical timestamps to track as close to real time as possible. We will have more information about how Fauna meets its consistency guarantees in a future blog post.

It's variable, and the client can provide it. By default, we use the greater of wall clock time or the highest timestamp transaction timestamp the node serving the query has seen.

Thanks, we realize the docs still have a long ways to go and are working to improve them as fast as we can. This is a good summary.

We're definitely aware that the lack schema definition is a problem for certain use-cases, and solving this is on our roadmap.

FaunaDB has a per-database replicated transaction log. Once a transaction has been globally committed to the log, it is applied to each local partition that covers part of the transaction. By this point, the transaction's order with respect to others in a database and results are determined. While writes require global coordination to commit, reads across partitions are coordinated via a snapshot time per query, which guarantees correctness.

In short, writes require a global round-trip through the transaction pipeline; reads are local and low latency.

A more apples-to-apples comparison with Cassandra would be FaunaDB transactions and Cassandra's atomic batch mutations, or its PAXOS-based lightweight transactions as opposed to single-cell writes tested in most Cassandra benchmarks.

YMMV, but we've found the performance of Cassandra writing out similar-sized multi-row atomic batches at QUORUM to be similar in this hardware configuration.

FaunaDB transactions are quite a bit more powerful, as they can span multiple keys, use conditionals and read-modify-write logic, and still resolve with serializable semantics.

FaunaDB's query language makes it straightforward to do it the first way. All queries are serializable, so any preconditions checked would gate transaction commit as you would expect, and read-modify-write style transactions work.

edit: here's an example in our Scala DSL:

  Let {
    val amount = 50
    val balanceA = Select("data" / "balance", Get(Ref("accountA"))
    val balanceB = Select("data" / "balance", Get(Ref("accountB"))
    If(Gteq(balanceA, amount),
      Do(
        Update(Ref("accountA"), Obj("data" -> Obj("balance" -> Subtract(balanceA, amount)))),
        Update(Ref("accountB"), Obj("data" -> Obj("balance" -> Add(balanceB, amount)))),
        "Transfer Success"
      ),
      "Insufficient Funds"
    )
  }

For the same reason you can't start making adhesive bandages and selling them as Band-Aids, even though many people call them that: Both are proper names for a specific regional brand of sparkling wine and grana, or hard cheese, respectively.

From what I understand, a lot of this caffeine is sold to soda makers as a byproduct of the decaffeination process used on coffee beans.

Does this mean the end of soda as well?

For longer periods of outdoor use, a low-power built-in text interface would be useful. Especially if the battery lasts longer than my phone's.