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.

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.

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...

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.

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.

At what cost though? Does 1 Pg server = 1 Mongo server for the same specs or do you need a lot more Mongo servers?

/s

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)

https://github.com/mongodb/mongo

Edit: ah it's source-available, not open source.

I mean, at least you get access to MongoDB source code, so that is something.

I remember working on a project that used Clusterpoint years ago and the problem was that it was basically an abandoned piece of software due to the company behind it no longer releasing new versions. It was running, yes, but getting data out of it and migrating to something else sure took work and was very annoying because a lot of functionality had been built around it.

So in regards to something so critical as databases and data storage solutions, I'd err on the side of picking things that are open source, or have compatible alternatives with permissive licenses.

If someone were to build their own business around MongoDB (say, offering it as a service) and then SSPL came along, they'd be done for, even if just because of getting caught up in things going on between the org and large cloud vendors or something. Same with how you have to be careful with AGPL, so something like MinIO might be a non-starter in some cases.

Mongo is a thriving database so I’m not worried about it being abandon.

With this, I can totally agree! And as long as it's not AGPL, you should be fine using it for most regular development stuff, even for closed source projects.

that's until provider starts abusing power: increasing rates, close source completely, etc.

I’m really more interested in getting shit done today rather than worrying about 100000 possible future cases. This is how you succeed.

https://www.ferretdb.io/

https://news.ycombinator.com/item?id=23271085

For the idiots downvoting.

2018 was version 11. Right when PostgreSQL JSONB support was beginning to get good.

This authors post has nothing to do with pro/cons of mongodb, and is entirely around a new query engine and computer science. And instead we've devolved into a discussion on the pros and cons of PostgreSQL vs MongoDB.

I get it. People don't like certain tools. But it would be nice for the rest of us to be able to actually discuss the topic at hand without all of the tangential critical noise.

The sub-questions about FOSS and font choice are annoying, in fact I removed my replies on them because I didn't want to feed the problem.

Other than that, I have never seen a proper justification to use schema less db, good for prototyping and get started, not incredible as a long-term solution.

You say "prototyping", but I would generalize that to "faster evolving" in the long term. Of course, not without tradeoffs.

I personally have zero issues writing a custom marshaller when needed for any the schema-less document collections I have. Constraints your application has on the data are a superset of db schema anyways.

[1] https://www.mongodb.com/docs/manual/changeStreams/

[2] https://blog.sequin.io/all-the-ways-to-capture-changes-in-po...

Client libraries are made to do this failover and retry under the hood. Queries are more often made as upserts instead of assuming transactions, eg ObjectId rather than auto increment and so on. Even non upserting operations like $inc are safely retried if handled by queries and not application code.

It's magic to see it happen, with no extra code, the application just keeps running even when one server is down. Starting it up again and it reconciles with no hands-on.

I would love to see a postgres that does this, because relational data is often more useful than the document model.

Please, for sake of the people you want to hear your words. DO NOT USE A SANS SERIF MONOSPACED FONT FOR ANYTHING BUT CODE.

I get it. We stare at text (code) formatted in this kind of font all day long, and many of us find fonts that we truly enjoy. But, most of our monospace sans-serif fonts are designed to make sure individual characters aren't misread. We don't read prose the same way we read code. There is far more pattern recognition going on than actual parsing of individual letters, and monospaced fonts break that. We can debate the aesthetics of serifs but they actually do help provide context clues to the pattern recognition systems in our brain.

Convincing you all to start using serif fonts on prose is not a battle i'm likely to win, but maybe I can convince you to only use monospaced fonts for your terminal, and your code.

Please.

All modern browsers have this.

Contemporary fonts have much less variance in the width of characters, except for a couple of outliers like the i. From there to a completely monospaced font is not as big a leap as you make it seem. For me, I'm fine with monospaced fonts for prose.

Also, the reduced character width (as a monospaced font inevitable has to be spaced at what the widest chatacters, such as w, require, means that you have to use a smaller font size to get the same amount of info per scroll/line/page whatever, again compromising readability.

Here's a comparison between the posted site, and the same site with the font size bumped up 4px, proportional (just browser default, I didn't cherry pick) and the ridiculously wide line spacing reduced.

Even with all that, the easier to read version is quite a bit more compact. Could likely bump the font size 2 more px and still be smaller.

https://i.imgur.com/DBFI2RU.png

I don't want say this in a way that comes off as insulting, but I'll just say it and please don't take it as a put down: if my kid came to me and expressed this much frustration and difficulty because of a sans sarif or monospaced font I would be concerned they had a problem with their vision or an issue processing what they saw, and I might research and/or take them to get checked out.

You probably just don't have a strong sense of aesthetics. Some people notice design-y stuff and some people don't. A lot of people do notice fonts, or misaligned margins, or whatever. And a lot of people don't. The latter category are probably never going to be good designers or artists or whatever. People are different.

What makes you think these proclivities about font choice are universal then? Maybe you are just insisting on what you find aesthetically appealing, while many people would equally validly feel the opposite?

There's an age-old debate of how much "good taste" is subjective, but in this particular case, it's someone hammering a nail in with a wrench. Some will be bothered, others not, but it's definitely the wrong tool for the job.

The example of not liking lights in certain places isn't a very good one. It's an attempt to elide all "things people don't like" into subjectivity, but there are actually things that are better and worse. You would agree that website design can be better or worse, right? And that some people would have a better eye for good or bad design? With me so far? I'm saying you're probably not one of the people out on the end of the spectrum that's best able to recognize good and bad in design, but I hope you recognize that good and bad design exist, and that people vary in their ability to recognize it.

    I think the inference that goes like 'if I can recognize something, there must be a corresponding faculty for that ability to recognize' is so remarkably bad that it is called a 'howler' in philosophy classes.

    Well lets consider it anyway.  Lets say you really are just the absolute best at having an aesthetic sense.  What is aesthetics?  It's knowing what looks good.  What does it mean to look good?  I means other people think it looks good too.  Ipso facto, having a sense of aesthetics must be extremely common, since whatever the largest group of people agree looks good is what 'looks good' to people.  So congratulations on your very common ability I guess.

    Or maybe you are more of a snob, and your aesthetic sense is so rarified other people can't even begin to appreciate the things you think look good or bad.  Lots of things you think are very beautiful would be called ugly by the vast majority of people, and what you think is ugly might generally be considered beautiful.  Nobody understands other than the other elite aesthetes, which you recognize because they agree with your judgements.  I could say something snide about how everyone has some group of people that agree with their judgements, and all that makes one group or another elite is that they say they are, but I'll just say congratulations, and point you in the direction of a modern art museum.

Not to make it personal, but if you are going to claim some kind of innate design ability, you should remove the link to your website from your profile.

Since 5.0 the default write concern is majority, if that's what you were referring to.

https://jepsen.io/analyses/mongodb-4.2.6

[0] https://www.mongodb.com/docs/manual/reference/write-concern/...

From [0] it looks like it was available from 5.1, also interesting is that you can't choose which engine to use, so I suppose it only works on subsets or queries that meet certain conditions.

This isn't the first time I hear something to the effect of "LLVM JIT is great, but it introduces a lot of query latency". I wonder if there are other JIT engines more suitable for compiling potentially small/simple queries.

[0] https://www.mongodb.com/docs/v7.0/reference/sbe/#std-label-s...

https://github.com/bytecodealliance/wasmtime/blob/main/crane...

https://blog.benj.me/2021/02/17/cranelift-codegen-primer

https://jason-williams.co.uk/posts/a-possible-new-backend-fo...

https://news.ycombinator.com/item?id=25130528 30% faster rust build time

There are other specialized JIT compilers that are essentially purpose-built to provide very low latency; for systems like MongoDB which are rarely used for serious analytical processing, you'd probably want to use one of these instead.

[1] https://www.mongodb.com/docs/manual/reference/operator/aggre...

[2] https://www.mongodb.com/docs/manual/reference/method/ObjectI...

There's no limit on number of sortable documents. Use an index to sort and it'll also be fast and use no extra memory. If you want to do an in memory sort there are memory limits, but you can also tell it to overflow to disk.

I've removed that part of my comment. Appreciate the correction.

MongoDB Atlas is a surprisingly good managed database product. I'm not a huge fan of someone else running my databases, but I think it might be the best one you can run across any cloud. If you like MongoDB (and, ignore the memes, there is a lot to like nowadays), and are OK paying a bit more to have someone run your database, I'd strongly consider Atlas.

[0] https://www.mongodb.com/community/forums/t/for-mongodb-enter...

[1] https://www.mongodb.com/community/forums/t/for-mongodb-enter...

[2] https://www.linkedin.com/pulse/mongodb-sizing-guide-sepp-ren...

MongoDB doesn't like to push the product because profit margins are way lower than Atlas.

Cloud Manager is basically an agent you install on a MongoDB server, which provides a cloud-UI for 1) database configuration, 2) indexes, 3) monitoring/stats, 4) fully managed backups + restoration, and 5) simple GUI for reading/updating objects. Basically everything Atlas does, but the servers are in your AWS account.

I think when we evaluated migrating to Atlas, the cost would have been 3-4x more compared to the equivalent memory/CPU self-hosting on AWS with Cloud Manager.

The query syntax is also a massive pain IMHO. Especially when you get into nesting expressions. E.g. I can never remember if it's `{$id: $regex{'/pattern/'}}` or `{$id: ${regex: '/pattern/'}}` or `{$id: $regex{ pattern: '/pattern/' }}` or something totally different.

SQL is still superior.

Can't you just query for a lowercase version of the input and sanitize data going into the DB so it's only lowercase? I'm not a mongo user but that doesn't seem like a dealbreaker to me