Actually, it's a really poor in-memory cache, since it pages back and forth to disk constantly.

No one's arguing that disk paging is high-performance. In fact, MongoDB themselves explicitly recommend that you keep your working set size below physical memory size.

Our data is 1/10th of available memory and MongoDB still pages back and forth to disk constantly.

This is what happens when you rely on the OS to handle paging.

> But it is a pretty good in-memory cache that can persist to disk, which is a valuable technical niche

It's not a niche at all. Those are standard OS primitives.

MongoDB arrived in the gap between MySQL sucking and SSDs becoming common enough that in-memory performance wasn't essential to get simple workloads to go.

MongoDB has quite poor in-memory performance due to its simplistic locking strategy. I personally think MongoDB only had the best marketing of any NoSQL database.

MongoDB is also incredibly ease to install, use, manage and understand.

But hey none of those are important to developers. We are just stupid sheep controlled by marketing.

Because when you chuck it over the fence to ops, it's not your problem any more, right?

Yeah, memory-mapped files and journaling are standard OS primitives. I would say auto-sharding, replication, indexing, and complex schema-less querying are not.

In my experience, MongoDB arrived with NoSQL/BigTable to fill a different set of needs than RDBMS's. Relational databases are great but not all applications need full ACID or transactions. Sometimes applications require greater data modeling flexibility. Other times, pain-free scaling/distribution are important.

MySQL is great when those features are required, but even when you put SSDs under MySQL, it's still MySQL.

> I would say auto-sharding, replication, indexing, and complex schema-less querying are not.

Agreed; that was part of my point. Distributed KV stores are a genuine novelty over classic RDBMSes and open an important line of attack for some classes of problems.

> Relational databases are great but not all applications need full ACID or transactions.

Also agreed. As a relational bigot, however, I only begrudgingly give up those guarantees. My point about MongoDB striking at a very particular moment is important: if SSDs had been widespread in 2005, I believe NoSQL alternatives simply would not have anything like the momentum they do now. Very fast random access is a seismic shift in the algo-economics of database systems.

> even when you put SSDs under MySQL, it's still MySQL.

One of my pet peeves is that many people take the limits of MySQL for the limits of RDBMSes. It's a bit like taking the limits of small cars as the limits of all wheeled vehicles.

It so happens that I am working a project where the central model is a graph; so even an arch relational pom-pom waver like me is considering picking a NoSQL solution for it.

Cheers. And didn't mean to trigger a pet peeve, I was just continuing the example. The point was more "even when you put SSDs under an RDBMS, it's still an RDBMS".

MongoDB is a great database if you have a domain model that is more document driven.

And who on earth uses MongoDB for caching ? I've never heard of a single company doing that.

Sorry, I guess, that you haven't heard of teams caching denormalized data in MongoDB...

MongoDB uses memory-mapped files across all available memory to manage data, it sacrifices ACID for speed, and its capped collections sacrifice undefined size for more speed. Its client drivers originally defaulted to fire-and-forget semantics, emphasizing its performance-oriented design. Such performance orientation is suitable for cache or cache-like needs. The general point is that its place in a system is different than that of the typical "database", whether it's SQL/RDBMS, ACID-compliant, or even document.

I'm fully aware of the MongoDB's trough of disillusionment status in the community hype cycle. 10gen brought this on by setting unrealistic expectations early on, through poor documentation and marketing. Calling it a database, a term laden in the mind of the professional developer with expectations of ACID compliance and proprietary languages, was a shortcut that ignored its atypical performance-first roots, and all of the trade-offs that followed from that. I've read more comments from people with a lack or faulty understanding of MongoDB to surmise that it's stalled in the trough because the name confuses developers. "In-memory cache with persistence" is a also shortcut, but one that is a little more circuitous and strikes a better balance.

I would stick to in memory cache solutions like redis, memcache over mongo

Depending on your needs, mongo has a much nicer interface than redis... Not to mention supporting indexing in the DB instead of having to DIY your own... I used it at a site that did mostly classified listings, and the performance was a lot better than the SQL RDBMS that was being used for search/display.

Yes, I agree. But regarding my comment, the use case was caching with persistence. Redis has some persistence options (pure snapshot or pure journal), but they just aren't its primary use case and aren't nearly as mature or performant as MongoDB's memory-mapped filing. Also Redis is key-value so requires manual indexing, i.e. much more up-front developer effort.

Memcached doesn't have persistence.

you can write a "cache that persists to disk" in a few lines of C code. ever hear of memory mapped files ?

That with a little bit of Fortran can get you in a big world of hurt.

I'm confused. You do realize that MongoDB uses memory mapped files for managing and interacting with all data...

Yes, I realize this. My point is that it's not a "technical niche", it's something nearly anyone can do, and has been able to do, for decades.