Literally speaking, "NoSQL" as much for databases as "NoHTTP" means for application protocols. It says literally nothing other than it's not something else.

It could be key-value database or it could be a graph database. It could have a schema or it could be schemaless. It could support one index or it could support multiple. It could have a permissions system or it could be single-user. It could have a server process or it could be embedded.

The author is thinking of the MongoDB and CouchDB variety.

RethinkDB certainly has schema. Indices have to be defined in order to get_all (=select) and join. My JSON docs are quite flat and use foreign keys heavily to facilitate queries & joins. Guideline: if you find a doc with a member list in your design you should probably separate the member list into it's own table with a foreign key back to the parent doc and use joins to re-aggregate data. So I am normalizing the data just as I would for a relational DB. But I'm getting the benefit of using the same language for queries as the rest of the code - it's all Python. No more of that prepared statement JDBC shenanigans. And I get the massive benefit of RethinkDB's change feeds. So no need to build and maintain caches in all my server components. That's a big win.

If your database has schemas, multi-entity ACID transactions and joins, then it's almost certainly a SQL database. A NoSQL database is one that misses one of this features. For example, ArangoDB provides multi-entity ACID transactions and joins, but is schemaless.