[dcolkitt]

I'd caution people outside hyper-growth startups from drawing that much from this chart. People in that ecosystem have very different utility functions than most software engineers.

Comparatively, I'm sure a chart with database swapped out for language would show a huge over-representation of NoSQL products like Mongo and Couchbase. Yet for the overwhelming majority of projects the right answer is just use a solid SQL product like Postgres.

Again, for SV hyper-growth startups the calculus is different. Mongo has tons of downsides and pitfalls. But the one thing it has going for it is, you can get started fast without having to think about it. Just throw shit in a giant nested key-val map and pull it out later. You don't have to design schemas or provision ahead of time. Change the JSON on the fly, and if you hit performance issues, just throw more hardware at it. Move fast and break things.

For 99% of projects that kind of attitude comes back to bite you in the ass. For every hour that you save today, you'll end up spending ten hours in a year or so from now when you're eventually forced to detangle a crusty sloppy mess.

But for a unicorn-aspiring SV startup, that tradeoff works. Almost any startup would gladly spend a hundred man-hours in a year or two, to get back one man hour today. And that works, because the growth rates are astronomical. In a few years, you'll hopefully be a billion-dollar unicorn with tons of resources to throw at the minefield of quick and dirty technical decisions you made at the seed stage. (More realistically, you simply won't be around anymore, at which point the pitfalls in waiting also don't matter.)

The point is don't necessarily pay too much attention to the decisions made by YC startups. This is true even for regular startups with more prosaic aspirations. (Some of us are more than happy to own $10 million companies, and aren't aiming for billionaire or bust.) If your business model is rooted in 1000% hyper-growth rates, that encourages many tradeoffs that are otherwise deeply pathological.

[tyre]

I couldn’t imagine doing anything in MongoDB or understand why that is desirable.

We have used Postgres from day 1 in March and are now 1200 people. Managing growth with a JSON blob sounds absolutely insane.

You need _more_ guarantees, not fewer.

[adoxyz]

Have you evaluated MongoDB to see why it's desirable?

Ignorance of a technology is a poor excuse to crap on it. I've used many different technologies over my 15 year career. SQL Server, MySQL, Postgres, MongoDB, Firebase, etc. Each worked well enough, each had it's drawbacks. I'm not here to tell you MongoDB is a silver bullet for every specific use case, but from personal experience I haven't run into an instance where it was a hindrance.

Disclaimer: I currently work for MongoDB.

[SQueeeeeL]

My big issue with MongoDB is similar to this Potts quote

“I have no problem with god - it's his fan club that scares me.”

MongoDB works fine in niche situations of trying to store large blobs of JSON with extremely different elements. But for the vast majority of cases, data is highly relational. So Mongo is just a crutch that companies like because of the lower skill ceiling. Most of these startups can't be bothered to pay high enough to recruit people who payed attention during their databases lecture. In the long run, it just creates a jumbled mess of db code.

[mtnGoat]

Every project I've worked in, got rid of mongo once they grew to any reasonable size due to cost and maintenance overhead. It's not a hindrance for small projects, but becomes a pain at scale in my experience. Based on that I'd never use it again for anything I plan to scale, gutting it out later is a pain. Might as well build it right the first time.

[Scarbutt]

Not saying you should use it but to reaffirm GP points, the most valued company in that list, Stripe, started with MongoDB: https://www.mongodb.com/blog/post/mongodb-powering-the-magic...

And this is a financial company.

[jd_mongodb]

The common misconception is that MongoDB stores JSON blobs. The JSON you see is converted seamlessly to BSON and is type encoded. This allows use to apply indexes at any level in the object and use complex query expressions at any level in the object.

[Alex3917]

> Managing growth with a JSON blob sounds absolutely insane.

There are cases where it's better when you're using a JSON blog inside SQL. Consider the common scenario where the pure SQL solution would be having 1 abstract model with 50 children that inherit from it, and are only each different by one or two fields.

Having one SQL model that gets queried in one way and in one place, but has 50 different JSON validators, is a lot easier to understand and work with than having 50 different SQL models that get queried in 50 different ways and places.