These web frameworks are all about reducing learning curves and making developers productive as soon as possible. MongoDB is easy to learn and will be fine for some percentage of use cases. The developers behind these web frameworks are often not coming from an enterprise systems / traditional RDBMS background and are not necessarily aware of the devops trade-offs between MongoDB versus traditional RDBMS.

I work for a software vendor and and this is a fairly typical scenario for customers of our dbShards product, who often have an app that starts to get traction and then requires a more reliable and extensible back end database that is easier to apply schema changes to without downtime.

For us, it boiled down to multi-master writes, and global replication (multi-datacenters). Cassandra worked best for our use case. Moreover, as others have pointed out, high availability with fault tolerance is another major reason. CAP theorem is real, and there are trade-offs to be made in several use cases.

Still with Cassandra you loose trnsactions and you can't start "small", as small as you could start with postgresql. A 10000 user service works well with a database running on 512mb ram, while cassandra needs at least 1gig (running lower could work there also, however mostly you will run into longer gc pauses than, it's really hard to trim the jvm down to less. I mean there are some ways to do it but it's way harder than just using something different).

and mostly people start with as low as 10.000 people. Scaling means starting from 1 going to X. and postgresql is well enough for most stuff. You don't need multi-master replication for most stuff. people mostly don't need write scalability. and for stuff that needs some writes they could easily cache that. (see instagram)

Just off the top of my head:

- First class support for sharding & replication

- Pluggable storage engine

- Capped collection (i.e. tailable table/collection)

- A query language which doesn't boil down to string concatenation (easier to manipulate in a language of your choice, but harder for human friendly adhoc query writing)

Not that postgresql doesn't offer any of the above in some form or another. Just that MongoDB does seem to make 1 & 2 & 3 easy to deploy & manage

Mongodb easy; PostreSQL hard. The latter requires extensive planning, which slows you down when features need to go out now.

Oh no! Someone needs to model their data before writing code??? The horror!

You're going to pay for getting the data model right eventually. The only question is - do you want to pay for it now or later? If you push it off until later, it's generally more painful to make changes. Or, you have to maintain a sub-optimal model for as long as the application exists.

I take it you must be new to software development.

Because I have never seen or heard of a situation where the data model has been designed upfront and never changed along the way. And you seem to be turning this into a black/white scenario. In almost all cases you do your best effort upfront and then iterate.

The advantages of these NoSQL/Schemaless style databases is that you can do this migration in your app instead of in your app+database. And unfortunately schema/data migration tools for databases really aren't that great - even after all these decades.

The disadvantage of NoSQL is that you do the migration in your app rather than in your database. This requires all programs that touch the database to know about every historic migration that ever happened, since there is still data in the database that uses the old schema.

With a SQL database, there is one source of truth: the current schema. It is not necessary to maintain historic information about all previous versions of the schema in every program that uses the database; they only have to know about the current version.

One problem with these schema-less style databases is that you still actually have a schema. You just don't have a good reference for what it is anymore since it's trapped in your code, likely in multiple files.

It is short-sighted to load everything in the application, because at best utilizing the data in another context is going to involve a major (possibly painful) code refactor. You are more tightly coupling your data to your application stack, which isn't the best idea in my experience.

As an aside, Postgres supports multiple schemas for a given database, so it is trivial to support multiple versions of a single table, provide legacy support via views, etc.

> why are they choosing it over PostgreSQL

Because it's fast, portable and easy to use. Pretty much what most developers want.

People can bring up the tired "oh but you will lose your data" jokes but it really isn't that much worse than anything else on the market. They all have bugs at some point. And I really don't see how PostgreSQL is any more reliable or has a larger expertise pool/tooling etc. If you were talking about MySQL/Oracle I would agree but not PostgreSQL.