So to sum up, foreign keys (and other DB-level constraints such as CHECK constraints)
do scale—when you have little data, then their upfront cost may appear high and application-level validation trivial, but when you have lots of data over lots of tables, checking for all the possible invariants from the application becomes a huge burden.
IMHO it is the lesser evil to denormalize data from a normalized source, be it in separate tables or a separate DB / schema (as long as a single source of truth is maintained) than to put non-normalized data front and first. It is always simpler to assemble normalized data into denormalized documents than doing the reverse (parsing documents, picking apart unstructured and poorly structured field values).
This is why I believe document and graph DBs are fine when they are ancillary to a relational DB.
Foreign keys do incur a cost indeed and insofar are subject to scaling headaches, but it does not seem possible to avoid that cost if what you want is data integrity.
