I personally don't really like the term NoSQL. What does it mean? "Everything else but SQL"? What is SQL then, anyway? Can we say that KSQL, Elasticserch SQL or Hive are SQL?
Instead, we can clearly classify database engines by their breed. Like, Cassandra is a key-value store, as well as Redis and DynamoDB. MongoDB is a document database. Elasticsearch is a document-oriented search database. MariaDB or PostgreSQL are RDBMSes.
After we have done this simple and way more precise classification, we can find out if the tool suits the job. Do you need queries? You'll have a hard time querying key-value stores. But it's very easy to query MongoDB, but you have to pay attention to your document schema. If you used ORMs before, you probably would be quite happy using MongoDB, unless you overuse relations between tables. Do you need to index and search a massive set of documents with somewhat loose schema? Then, you can try Elasticsearch or maybe even be happy with MongoDB full-text search, but no key-value store will ever provide you with such a capability.
You can still combine the high transaction throughput of Cassandra with a queryable model by making change-feed processing, projecting data from Cassandra to another database that has better support for queries. In that case, you will have to deal with some eventual consistency but it might be a tradeoff that is acceptable.
My point here is: please don't fall to a trap of "SQL vs NoSQL" discussion. These terms are vague and bias-prone. Sometimes saying "I could do it with SQL in 5 minutes" mean "I know how to do it with PostgreSQL in five minutes, maybe using Oracle will take me an hour, and with MongoDB, it will take 30 minutes but it will be easier to maintain. And there's no way I can use Redis". Such a reasoning has much more value.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I personally don't really like the term NoSQL. What does it mean? "Everything else but SQL"? What is SQL then, anyway? Can we say that KSQL, Elasticserch SQL or Hive are SQL?
Instead, we can clearly classify database engines by their breed. Like, Cassandra is a key-value store, as well as Redis and DynamoDB. MongoDB is a document database. Elasticsearch is a document-oriented search database. MariaDB or PostgreSQL are RDBMSes.
After we have done this simple and way more precise classification, we can find out if the tool suits the job. Do you need queries? You'll have a hard time querying key-value stores. But it's very easy to query MongoDB, but you have to pay attention to your document schema. If you used ORMs before, you probably would be quite happy using MongoDB, unless you overuse relations between tables. Do you need to index and search a massive set of documents with somewhat loose schema? Then, you can try Elasticsearch or maybe even be happy with MongoDB full-text search, but no key-value store will ever provide you with such a capability.
You can still combine the high transaction throughput of Cassandra with a queryable model by making change-feed processing, projecting data from Cassandra to another database that has better support for queries. In that case, you will have to deal with some eventual consistency but it might be a tradeoff that is acceptable.
My point here is: please don't fall to a trap of "SQL vs NoSQL" discussion. These terms are vague and bias-prone. Sometimes saying "I could do it with SQL in 5 minutes" mean "I know how to do it with PostgreSQL in five minutes, maybe using Oracle will take me an hour, and with MongoDB, it will take 30 minutes but it will be easier to maintain. And there's no way I can use Redis". Such a reasoning has much more value.