If I understand correctly No SQL does not mean ‘Non Sequential’ but rather “Not Only Sequential” so Mongo should be able to do both.
Even though it might be better/more efficient at one type. Is this correct?
It means a non-relational database, so it does not work like an SQL that is a relational database.
This enables easier programming and iterations and scaleability, but also is not inherently organized like a relational database has to be by its very nature. Thus set practices in programming should be followed with a non relational database such as Mongo.
What Mongo has uniquely done (and no, Mongo has not always been the best performing database, and sometimes it has been, but that is part of the point it does not matter, anymore than it mattered for Windows, that it is the best performing, as long as it performs well enough) is create the best non-sequential database from the ground up (that is what Mongo will tell you) and enabled the key relational functions that a relationship database has as well.
The two major features that are totally unique to a non-relational database that Mongo bring is ACID multi-document, and the aggregation pipeline.
ACID enables Mongo to act with the flexibility of non-sequential, but with the security and and record keeping capability of an SQL; aggregation pipeline enables analytical functions to take place directly within the database, which is a feature only Mongo has out of non-relational databases, and it is a large advantage in terms of speed and ease and functionality.
You can look up some of the abstractions and functionality that Mongo has built in as part of the aggregation pipeline, it is the CIO’s favorite feature. He gives demonstrations about it use, and is trying to promote it because first it is unique and second he believes its functionality and ease of use is superb to the point of amazing people he shows it to.
In any event, NoSQL = non-relational vs. relational, but MongoDB has managed to cross over and create the functionality of a relational without the rigidity and limitations of a relational database (keep in mind that old time developers state that these limitations are positives because it requires organization when building - but what they do not say is that the same organization can be more easily created in a NoSQL if best practices are used - it can create problems if developers get lazy or haphazard).
Probably more than you want, but I will sum it up with no technical terms, Mongo does things that traditional databases do, but with far easier development, far easier iteration (meaning you can continually make changes to it with no problems), far greater horizontal scaleability (meaning you don’t need ever faster and more powerful computers, instead, just spread it out infinitely over cheap computers or servers in the data center or cloud), and at far better cost.
More than this, because of these features, MongoDB enables applications to be built (such as the MetLife example) that were literally IMPOSSIBLE to be built before Mongo. Things that sound not so difficult, like combining database information from a company and turning it into one consolidated CRM for the company. With a relational database - NOPE (after years of trying). With Mongo - yep, in just a few weeks.
Mongo has become the leading such database, it is the database with the most functionality (even if it is not the best at every metric - who cares), Mongo is adding features and improving faster than any other NoSQL database, and except for niche uses, MongoDB management tells us that they are no longer seeing any relevance in their competition when they compete for business with enterprises. Meaning that enterprises are now choosing between Mongo or something relational, and when they decide the relational database won’t cut it (which is becoming more and more often) they turn to Mongo and no one else.
This does not mean, such as Apple OS, or SyBase, that some developers will brag about how Couchbase is clearly better or Cassandra is faster, etc., sure, probably true. But none of them are being considered modern GENERAL PURPOSE database for mission critical applications at the enterprise C-Level. That is where the real money is, and that is where the industry standard is being set. If you have a niche application that does not require C-level input, you can choose Cassandra for it. Who cares. There is not much money to be made in those applications, and your only competitive advantage in such niche use cases is being the fastest or best performing, and that is fleeting. The industry standard general purpose modern database does not need to be the fastest or best, but just good enough.
Tinker