Typically relational DBs provides referential integrity such that deleting a particular row that is referenced from another table through a foreign key relationship is not allowed to ensure referential integrity (i.e. references will always refer to an existing row)
Your documentation seems to have conflicting information:
Fauna supports the fully-denormalized document model, but referential integrity can be enforced in both transactions and indexes, thereby relieving application developers from implementing complicated logic to guarantee correctness.
The Ref function does not verify that the schema_ref , or the document_id within the schema_ref , exists. This means that you can use Ref to create a reference to a non-existent document in a non-existent collection.
AFAIK, this is not out of the box behaviour. The Delete() function will not check for any references.
However, it is possible to write a UDF that checks for references and then abort if necessary. Since everything done in a single query is atomic, this could effectively replicate a ON DELETE RESTRICT in psql. Just remember to only use the UDF exclusively for deletion.
Expanding on this idea, many if not all other features of traditional DBs can be manually implemented as a UDF, as well as custom logic not possible at all as a single SQL query.
Of course, this comes with increased read/write/compute operations.
@ssttevee thanks for the response. I see how ACID allows us to implement the relational semantics of Postgres. I guess as FaunaDB becomes more mature these feature might come included as part of the query language.