Instructor: Fauna is billed as a globally distributed, serverless cloud database management system for modern applications like those in the JAMstack. What this means is that FaunaDB is a document store with a Lambda calculus-based query language called FQL and native GraphQL support.
It is similar to Spanner and inspired by Calvin, both of which have papers written about them that have been cited hundreds of times. However, if words like lambda calculus and reading papers aren't your jam, don't worry. Getting started is easier than it sounds. You won't have to read the papers or take a course in lambda calculus to put FaunaDB to work quickly.
Practically, what this means is that you can quickly spin up a new database, offload operations to the Fauna team, describe databases using the built-in GraphQL support, and access your data from anywhere around the world quickly without sacrificing correctness constraints.
Fauna internalizes security in a way that some other databases do not, including intentional support for multi-tenant SaaS services. This support includes different token access levels like read-only, as well as access control lists, or ACLs, that are flexible enough to implement role-based access control, or RBAC, on the document level.
If you're interested in the deeper correctness constraints offered by FaunaDB, take a look at the Jepsen analysis. If you haven't seen a Jepsen analysis before, note that one of the best outcomes is that the analysis finds issues and the company or project acknowledges and solves them.
Depending on how you use FaunaDB, you can achieve snapshot isolation levels of serializability or strictly serializable. That puts FaunaDB somewhere between snapshot isolation and strictly serializable on this consistency chart.
If you're unfamiliar with consistency models, this matters because snapshot isolation guarantees order within a transaction but not across transactions, as the sub-operations may interleave with each other. Strictly serializable systems enforce a total order on the transactions in the system.
In contrast, weaker consistency models, like read uncommitted, allow one process -- we'll call it A -- to write a record to the database. When process B tries to read the same record, the value process B gets isn't guaranteed to be the original or modified value, and thus, as you can imagine, can easily source bugs.