I'm not sure what experience you have, but I've run both their Enterprise licensed database on prem as well as migrated to Atlas and there have never been any licensing issues preventing vertical scaling of databases. One of our clusters on Atlas right now has machines larger than 256GB of RAM -- you're more limited by what your cloud vendor has available than Atlas.

>It means you can't have case-insensitive searches or keys (e.g. foo@bar.com is treated differently than Foo@bar.com). You also can't rename databases.

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

no, that means you can sort on a max of 32 fields per sort request, like fieldOne, fieldTwo, fieldThree...

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 thought all those points died along with the hype ("MongoDB is web scale"), as all were wrong.

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.

PostgreSQL will be horizontaly scaling if you can avoid joins and index range locks. But the thing is you don't want to, or why do you need SQL database then. I found MongoDB good for cases when you need a lot of upserts, your data model is looks like document and you don't need joins. Like you store events data for further processing or collect stats or counters with tags/indexes.

> MongoDB:

does mongodb support ACID transactions? I think this is one of the key question in making decision.

Thanks. Just what I was looking for.

e) MongoDb is web-scale.

;->

(personally i like the schema-lessness)

It's completely understandable. This is a significant and interesting upgrade to MongoDB that naturally gets people interested in a, "Hmmm… maybe I should take another look at MongoDB" way. Before wasting time, it seems sensible to use this forum full of experts to ask whether it would be worthwhile, and what the advantages or disadvantages would be. I didn't sense any negativity in the question, and it was the exact question I had in my head too. After skim-reading the article I went straight to scrolling down the comments to look for this exact question.

Same as it ever was. Someone posts a new JS framework, and the top 50 comments are about how bad JS is, and why don't we do RUST with WASM instead? Someone posts about a new Go release, and the top 50 comments are about how terrible Go is, and why don't we use a real language instead? Mongo... same thing.

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 original question was fine, asking what's the reason to use MongoDB. Like, it got a new query engine, please convince me to try using it / how does the new engine compare to Postgres.

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.

I remember adding changestreams a few years back to my project, they were amazing .

Schema-less is a bit wrong term, since you always end up with one but, indeed, schema-on-read vs schema-on-write discussion for individual use cases is far from a settled thing, even though the zeitgeist is that schema-on-write won sometime in the 70s.

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.

This isn't just a server property. It need to be implemented across the whole vertical, including client libraries and how queries are constructed in the application. With mongo it all is, and it's there out of the box.

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.

3 year… almost 4 years ago you commented about a few years ago. So not really relevant.

For the idiots downvoting.

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

My question exactly. No sense building a house on someone else's land. Too many projects I've worked on were shattered because of technology that stopped being offered or got too expensive to justify.

There is FerretDB. But they are not fully compatible to Mongo yet.

https://www.ferretdb.io/

Because just about no one cares and I want to burn down a backlog quickly and often mongo enables that. Developer productivity is far more valuable that open source purity.

Isn't mongodb open source?

https://github.com/mongodb/mongo

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

Also, but main point for MongoDB 10 years ago was the JSON. But now?

This is completely false and has nothing to do with the article. DynamoDB and MongoDB might both serve JSON but they're used for wildly different things. DynamoDB is a key value store whereas MongoDB is much more than that.

> Our most recent report on MongoDB 3.6.4 focused on causal consistency and linearizability in sharded collections. We found that sharded clusters appeared to offer linearizable reads, writes, and compare-and-set operations against single documents, so long as users ran with read concern linearizable and write concern majority. However, any weaker level of write concern resulted in the loss of committed writes. MongoDB’s default level of write concern was (and remains) acknowledgement by a single node, which means MongoDB may lose data by default. Although the write concern documentation does not make this clear, the rollback documentation states:

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

Disagree. Reading monospaced prose sucks big time. For those of us with a little bit of vision deficiency the vary character widths are helpful.

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 wouldn't be bothered about it in this case (I'm much more offended when the font size or margins are stupid), but to use your phrase "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..."

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.