Being required to make application and schema compromises in order to scale to tens or hundreds of terabytes is a symptom of the inadequacy I was referring to. It is not a property of databases generally, it is a property of MongoDB.
I get the argument that customers should not over-engineer their database systems but in other databases a lot of that "over-engineering" comes almost for free in terms of user effort.
Also, for many types of analytics, there really isn't a concept of "cold" data. A single query should be able to access data inserted milliseconds ago and data inserted a month ago as though it were in the same table. A lot of "real-time" analytics work this way. This does not need to be done purely in-memory if the storage engine is designed well. The old OLTP/OLAP dichotomy of the 1990s has been slowly fading for a long time.
Just to clarify, I meant "compromise" in a more broad sense. Scaling databases requires continuous compromise, usually of flexibility. There's nothing unique to Mongo about this. In the relational world (actually, with Mongo too) you end up denormalizing data, which creates complexity. You may also give up joins, secondary indexes, constraints, etc.
Some DBs handle this by requiring compromise at the very beginning, which makes sense when you're going to have a huge amount of data from the get go.
There's no DB on the planet that lets you go up into the TB range without having to make some compromises (either up front or down the road).
You do have to give up the transaction theoretic elements once you get into the hundreds of nodes. Or at least, you will notice the sub-linear behavior in the scaling. Complex updates across multiple records will show some limitations on performance.
For things like joins, query selectivity on multiple columns, etc not so much. You don't even need secondary indexing or denormalization to do things like graph analysis or polygon searches on a table (in the same query even) at scale. All of the access method related operations can scale very efficiently to massively parallel systems if you use the appropriate data structures and algorithms.
MongoDB uses an approximation of the correct algorithms for gigabyte scale systems. Those algorithms are just wildly inappropriate when you start talking about terabyte scale systems. I have no investment in MongoDB negative or positive, but like all databases it is going to be lousy outside of the implicit scope supported by the design and architecture. In the specific case of MongoDB, and as someone that has designed their share of database engines, the internals are not designed to support non-small databases to any significant extent.
And honestly, a terabyte is a pretty trivial database these days. That is the kind of thing you run on a single server with ease. Smoothly scaling that to dozens of nodes as though it was a single system is something you can buy. I really don't understand the assertion that scaling to 10TB is difficult or requires anything different than scaling to 10GB. That is demonstrably untrue.
I get the argument that customers should not over-engineer their database systems but in other databases a lot of that "over-engineering" comes almost for free in terms of user effort.
Also, for many types of analytics, there really isn't a concept of "cold" data. A single query should be able to access data inserted milliseconds ago and data inserted a month ago as though it were in the same table. A lot of "real-time" analytics work this way. This does not need to be done purely in-memory if the storage engine is designed well. The old OLTP/OLAP dichotomy of the 1990s has been slowly fading for a long time.