In the context of databases the terms “relational,” “schema,” and “normalized” have specific meanings. Relational databases have specific properties and guarantees that have nothing to do with SQL. Mongo doesn’t get “more relational” by supporting joins any more than Postgres gets less relational supporting JSON types.
And conversely leaving keys, constraints and foreign keys to goodwill and application layers makes traditional SQL-centered databases less relational, while draconian validation of JSON trees makes traditional "NoSQL" databases almost relational.
Sure. What you describe -- leaving keys, constraints, foreign keys to goodwill and application layers -- is fairly common. I'm not sure if that comes from ignorance or a fanatical devotion to OOP. When OO runs into the relational model (the so-called object/relational impedance mismatch) OO seems to "win" in the sense the RDBMS gets turned into dumb backing store.
I think it's obvious why this particular use (or misuse) of relational databases fails to scale, or gets hard to manage across multiple clients of the database possibly written in different programming languages. I have seen the same consistency guarantees implemented in Java and Python application code when the RDBMS could be doing that, and then hearing "SQL databases" blamed for the inconsistencies and scaling problems.
