gqewogpdqa

I like both databases. Saying that MongoDB is a subset of PostgreSQL is not right, IMO. They are both powerful databases. For legacy off-Oracle or off-SQL Server migration, PostgreSQL sure is an easier place to start (though you still likely have to re-write/re-tune your application). For new apps, you could start with either.

The idea that PostgreSQL is a superset of MongoDB is incorrect. As some examples, PostgreSQL doesn't shard, have multi-region, multi-cloud, enforce JSON schema, data governance, full JSON support, etc.

That said, PostgreSQL does do a lot of things MongoDB doesn't do.

The two products have a big feature overlap - both are great databases. I think you could build a modern app on either one. If you want to build in modern languages faster and have a more available system out of the box, I'd suggest MongoDB. If you have legacy skillsets, legacy apps, or just love relational, I'd suggest PostgreSQL.

Hmmm. Isn't customer churn public? Anyways, my guess is that the product is 1) much easier to use (less bells and whistles) 2) mongodb provides more configuration etc without charging for it.

Totally agree. It should have been called “Scalability and availability (even degraded) first, with as much durability and consistency as possible”. After all, that was the motivation behind the “NoSQL” movement, when databases like Oracle just couldn’t scale, even at infinite cost, so things like Amazon went down for Christmas 2006 (?) and Amazon decided to write DynamoDB. A different set of requirements created a different product. And then MongoDB came along, initially to power DoubleClick, after relational had failed there too. Neither one had anything remotely to do with SQL but with the lack of scalability in the backend relational databases - a problem that still plagues single-primary-writer relational databases to this day.

And then other non-relational databases came along, like Couch and Cassandra and Scylla - all focused (again) on things other than “SQL vs something else”.

And now they are all adding transactions and secondary indexes and all that stuff - but starting from a much more solid base of a distributed architecture rather than the antiquated monolithic architectures of the relational leaders. Those same relational leaders (Oracle, SQL Server, MySQL, and even the current leader on the dance card, PostgreSQL) are all multi-million line monoliths which are incredibly hard to distribute, scale, and make available and operate at scale - much less easy to develop and improve.

The name is just so sad

Not really true. MongoDB natively supports sharding, multiple indexes, high availability, arrays, sub documents, array traversal, etc - all able to be accessed in your native language with get/set functionality (or via MQL if you want). While PostgreSQL is a really powerful database, the JSON support is really painful to program against.

What are the characteristics that make it more relational than non-relational?

Indeed! That would be a great confirmation.

Lots of databases have transaction bugs which they hurriedly rush out patches to. MySQL, Oracle, SQL*Server, even the cloud databases like DynamoDB, CosmosDB, Aurora. Looks like MongoDB fixed this one.

I like thinking about the best tools for the job, or "jobs to be done" as Clay Christensen would put it. But why wouldn't you use MongoDB for things that require ACID? MongoDB has had cross-collection ACID transactions since 4.0 (years ago) and in-collection transactions (less useful, of course) since a long time before that. PostgreSQL is indeed a pretty awesome database. That said, the JSON support is just so very painful. It's nice that it supports indexes on JSON, though, once you get through the syntax. Thanks for your post.