long overdue.
NoSQL databases are great for storing arbitrary JSON-like structures, retrieving them by ID and occasional queries/aggregations on the inner fields of those structures.
NoSQL is absolutely not suitable for most business logic and the lack of a schema is actually a major drawback. It feels like a solution (because inserting invalid data will succeed on NoSQL compared to a conventional DB which will reject it based on constraint violations, missing fields or mismatched column types) but in reality you're just kicking the problem down the road and it will come back to bite you because your application now has to be able to deal with this inconsistent data (and in most cases that isn't accounted for with dealing with NoSQL, and the result is predictable).
I've been on a project where the main database was MongoDB and while it worked fine for the most part, we'd get exceptions when the application tries to read some records (most likely from earlier on in the business' lifetime) that had missing keys and would predictably explode. This isn't the fault of MongoDB by itself - the whole point of it is to be able to deal with unstructured data - but the fact that someone chose to use it while they actually needed structured data and constraints to ensure only valid data is inserted in the DB, which traditional relational databases do provide. Of course, it's easier to blame MongoDB rather than admit "we've been stupid and shouldn't have chosen the wrong tool for the job".
It's a poster boy for making a shoddy product and then trying to paper over the deficiencies with sales and marketing.
Part of this marketing includes creating a super easy, slick set up for beginners and just burying the grenades for beginner users to discover later when they're already locked in.
NoSQL is indeed appropriate sometimes, but Mongo never is.
In your case you didn't pick the wrong tool - your type system and interfaces to the DB (ORM) were probably lacking.