Or is NoSQL destined to be a passing fancy? I doubt Tamhas thinks this, although his posts on the topic would indicate he thinks not much of it. Which is fine, although it does seem to defy the evidence we have.
I have some expertise with a non-Mongo nosql DBMS system, general experience in multiple others, and I would heed tamhas much more carefully than you have.
What has traditionally been regarded as “NoSQL” can be divided into several different classifications, Mongo falling into the category of document store. But there are 4 leading contenders (Cassandra/DataStax, a column store; Redis a key-value store; Couchbase, a document store; and Riak, which has a key-value and timeseries product but the parent company Basho has recently gone bankrupt). You also have Marklogic, which is a larger, but somewhat niche player.
Further there are nosql-like systems like search engines (Elasticsearch or Lucene/Solr) and distributed transaction logs like Confluent/Kafka. Some cases even call for graph databases like Neo4j or Titan which are more related to efficiently querying edge/vertex sets taking advantage of mathematical symmetries in these structures than any type of storage. They may be compete in some architectures, or may coexist in others.
You should also be aware that there are constant new entrants (Scylla, RocksDB, CockroachDB, et al), some have been acquired already (Foundation to Apple), and may large tech companies have closed source internal databases (Manhattan at Twitter).
That also DBaaS platforms like Microsoft Cosmos, Google Spanner, Amazon DynamoDB, et al. that all have different technical characteristics, beyond what I will go into here, but for one example Spanner is supposed to have “solved” some distributed state synchonization problems involving GPS satellites and atomic clocks.
Finally, you can have many nosql characteristics in traditional relational systems (sharding, replication/failover, document storage and indexing) that might offset the typical operational complexity of many nosql systems. Honestly, on the low end the k-v vendors probably overlap with plain old caches that support sharding (memcached, ehcache).
All the questions about technology selection end up revolving around intended use and operation characteristics. The fundamental problem is tuning for the intrinsic tradeoffs in CAP (consistency, availability, and partition tolerance… generally speaking, databases can “choose two”). Ie you might select differently if you are writing a recommendation, fraud detection, metric collection, messaging, payment processing, or ad tracking systems. No single vendor is going to capture all the nosql tam.
Anyway, hopefully it’s clear that it is a very complicated landscape of competing, well funded companies. db-engines is something many people want to have good placement in (same as they would with Gartner) but it shouldn’t be overly relied on (also same as Gardner). MongoDB was extremely efficient in developer relations and providing an easy on-ramp, but as a result you have things like the 2017 ransomware attack based on the Shodan scans indicating 10s of thousands of unsecured MongoDB clusters because you have so many are being run in situations that are probably smaller scale and, as a result, harder to monetize. I think that manifests in their relatively high db-engines rank versus relatively low margins and revenue on the balance sheet.
Also, you should take the MDB multi-document ACID-compliance claims with a grain of salt. It is a month old announcement of a technical beta.
As a stock, their float is small. Look at the float % short vs short ratio. They have a lockup expiring. They are easy to move and will probably be volatile. The competitive landscape is tough. I would keep an eye on burn rate just as much as revenue growth. On the other side, they’re ubiquitous enough to be part of their own technology stack acronym (“MEAN”) and are undeniably popular. If I had to, I’d be net long, but certainly not 100%. I’m currently neither.