a) has a proven, supported, easy-to-use horizontal scaling solution. PostgreSQL doesn't.
b) is ridiculously faster than PostgreSQL at per-tuple document updates.
c) has clients which are tailored for operations and data structures around documents.
d) is easier to install, configure and manage.
Those were the marketing points people mentioned in their "honeymoon phase" posts. Then after using it in production, actual benchmarks and comparisons coming in, came the regret and moving on posts. In fact, most of those mentioned moving from Mongo to Postgres, and there was a full blow "yeah, NoSQL was a dumb idea for 99% of use cases, and Mongo even more so" discussion.
In the end MongoDB was the butt of a joke, there were whole memes about it.
So this comment is like a trip down memory lane, or into an alternate universe, where it's like 2012 and these things never happened.
/s
At what cost though? Does 1 Pg server = 1 Mongo server for the same specs or do you need a lot more Mongo servers?
Postgres does have things like Citus, or even wire-protocol compatible things like CockroachDB that do scale, but those are not Postgres.
It's the same situation with MySQL vs. Vitess.
sure, citus is an extension of postgres and part of ecosystem.
Point still remains that PostgreSQL lacks a modern, built-in horizontal scalability solution.
Microsoft on the other hand is among the best in keeping such promises.
If Google had bought it, sure...
The writes aren't. There's no sharding for example. You can ever only have 1 primary writer.
I expect the replication story with Postgres will get much better over the next few years.
If you are dealing exclusively with documents I find MongoDB to be faster, better and easier to use. If my data model is hybrid or purely relational then I would use PostgreSQL.
After all these years I am still waiting for an horizontal scalability solution for PostgreSQL that is up to the level of a modern database. It's 2023 and for many of us in enterprise environments it's a mandatory NFR.
But it seems like you're not interested in a having an actual technical discussion.
You mean like the "technical" bullet points that could just as well be marketing copy?
In my opinion Citus is still only a hack which is only useful if for some reason you can't move away from Postgres but you have reached the limit of what you can get out of a single machine.
I can implement that in MongoDB such that a query can be done in O(1) whereas implementing this in a relational database requires n joins which in turn requires n foreign key indexes and n row fetches. In many cases this approaches O(n). I have personally seen improvements of 10-100x for this use case when n is large.
Also there is a reason that the standard now in enterprise companies are data lakes and not EDWs. Because the cost and effort to model all of your data is prohibitive especially when 99% of the data ends up never being queried.
It was terrible.
It was not fast, a regular SQL db would have been much better, due to bugs in our code, the data in mongodb was not uniform, which led to failures in the code when the document didn't have the expected format.
Cherry on top is that they were mostly growing documents, which is a very slow operation, that would have been done very fast with a many-to-many table in SQL instead.
It supports schemas though right? https://www.mongodb.com/docs/manual/core/schema-validation/
The horizontal replication story in Mongo is just a different game. And because it's so reliable, that ends up being how you solve not just availability and scalability but also engine upgrades and config changes.
I migrated a bunch of production transactional databases on Mongo Atlas from a GCP cluster to an AWS cluster, with zero read/write downtime, by just walking through simple cluster reconfiguration steps. Add some nodes in AWS... move the write master... remove some nodes from GCP. It was stress free and easy.
The same trick with replication on Postgres was a nail biter every time we did it.
does mongodb support ACID transactions? I think this is one of the key question in making decision.
MongoDB’s claim of “full ACID transactions” which “maintain the same data integrity guarantees you are used to in traditional databases” could be misleading. We recommend that users who are accustomed to serializable behavior evaluate critical transactions carefully, to identify whether running at snapshot isolation could violate application-level constraints. MongoDB may wish to revise their marketing language to use “snapshot isolated” instead of “ACID”. https://jepsen.io/analyses/mongodb-4.2.6
;->
(personally i like the schema-lessness)