Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Did So Many Startups Choose MongoDB?

nemil.com

Post reply on HN
Print view View original

121–130 of 164 posts

Re: Why Did So Many Startups Choose MongoDB?

#121

Post by bdcravens »

dizzystar wrote: post #29

I think the short answer is the same today as it was back in those days. A person once put it to me simply: "programmers are afraid of databases." It was a perfect mixture of this unfounded fear with an advertised simple solution. Add the idea that there is no need for a DBA, encourage developers to see Mongo as a magic data storage and nothing more, and you have the perfect product for those who don't feel the need…

> programmers are afraid of databases.

Maybe it's an age thing (or the product of "bootcamps"), but I don't think that's true. I'm 40, and when I was learning, you connected to and wrote SQL against the database. These days I still spend a significant amount of time writing SQL, both for ad hoc queries and for complex queries / performance optimization.

> Add the idea that there is no need for a DBA

With many cloud database offerings this is essentially true. As for things like indexes, etc... developers targeting Mongo need these as well.

> encourage developers to see Mongo as a magic data storage and nothing more

In modern frameworks, this tends to be true no matter what the data store is.

Re: Why Did So Many Startups Choose MongoDB?

#122

Post by squeaky-clean »

rosser wrote: post #58
squeaky-clean wrote: post #30

Earlier quoted context omitted.

If you actually need certain features like a document store, then Postgres is less mature than MongoDB in that regard.

I'll take "less mature" over "data loss" every day and twice on Sunday. Whatever else you might say about Postgres, that community cares about the integrity of its users data, over pretty much every other consideration. I don't think the same can be said of Mongo, or any other "NoSQL" anything.

That's exactly my point. Postgres JSON support is "relatively new" (quoting OP) compared to Postgres. So clearly MongoDB is better right?

Except it's not and age of the product is a bad qualifier.

The MongoDB hate hype train is even worse than the MongoDB hype train ever was.

Re: Why Did So Many Startups Choose MongoDB?

#123

Post by busterarm »

felipeccastro wrote: post #118

It's not just because of hype that teams choose Mongo. The flexibility of a schemaless db is pretty helpful in a startup scenario, where the requirements drastically change all the time. Yes, migrations work for RDBMS too, but with Mongo you only write migrations for data changes, not schema changes - which means a lot less migrations. The option of having documents with embedded objects/lists makes it a pretty natur…

I'm not entirely convinced that MongoDB is better suited or a natural mapping to DDD concepts in practice, it's just more convenient for developers who want to build things fast.

My thoughts on this pattern are to still use a robust, reliable db (Postgres) behind a message queue for the event store. Postgres does almost all of the things I need with the reliability that I need while letting me sleep at night.

An event store absolutely must be the most reliable part of the infrastructure, IMO.

Re: Why Did So Many Startups Choose MongoDB?

#124

Post by mi100hael »

felipeccastro wrote: post #118

It's not just because of hype that teams choose Mongo. The flexibility of a schemaless db is pretty helpful in a startup scenario, where the requirements drastically change all the time. Yes, migrations work for RDBMS too, but with Mongo you only write migrations for data changes, not schema changes - which means a lot less migrations. The option of having documents with embedded objects/lists makes it a pretty natur…

Schema migrations during rapid growth are usually of the ADD COLUMN type which is cheap & easy. Data migrations are about the same amount of effort either way. If anything, requiring explicit schema migrations forces you to think more carefully about your schema design decisions and saves headache down the road, as the article mentions Etsy (and many others) encountered.

Re: Why Did So Many Startups Choose MongoDB?

#125

Post by felipeccastro »

busterarm wrote: post #123
felipeccastro wrote: post #118

It's not just because of hype that teams choose Mongo. The flexibility of a schemaless db is pretty helpful in a startup scenario, where the requirements drastically change all the time. Yes, migrations work for RDBMS too, but with Mongo you only write migrations for data changes, not schema changes - which means a lot less migrations. The option of having documents with embedded objects/lists makes it a pretty natur…

I'm not entirely convinced that MongoDB is better suited or a natural mapping to DDD concepts in practice, it's just more convenient for developers who want to build things fast. My thoughts on this pattern are to still use a robust, reliable db (Postgres) behind a message queue for the event store. Postgres does almost all of the things I need with the reliability that I need while letting me sleep at night. An even…

"just more convenient for developers who want to build things fast" - that's a compelling advantage for Mongo, isn't it?

I agree a robust, reliable db is super important - but isn't Mongo too, at this point? Even if it wasn't back in 2012? I thought most of the reliability issues and bad defaults were fixed by now...

Re: Why Did So Many Startups Choose MongoDB?

#126

Post by enjoiful »

sidlls wrote: post #79
manishsharan wrote: post #64

I think Enterprise folks do not appreciate the flexibility afforded by NoSQL . For my startup I started off on PostGres SQL with Hibernate and it worked great ... until we first met our paying customers. They needed data elements that I had not envisioned and so we ended up doing Schema updates.. again and again . Since we used ORM (hibernate), that also meant new hibernate code generation . After a while this became…

Database migrations are a thing. Many languages' database libraries have built-in or bolt-on schema migration tools for this very purpose.

Django's ORM and migration tools are amazing.

Re: Why Did So Many Startups Choose MongoDB?

#127

Post by nasalgoat »

We chose it because the lead developer liked it, and when I did my research I didn't find any glaring issues because it was too new.

The lead dev had never actually used it, but liked the idea of not having to come up with a schema and he really liked JSON as he was very familiar with it.

By the time we were done, we were easily one of the top 5 users of MongoDB at scale and it was responsible for 9 out of 10 of our outages due to various bugs or optimization issues.

Re: Why Did So Many Startups Choose MongoDB?

#128

Post by busterarm »

felipeccastro wrote: post #125
busterarm wrote: post #123

Earlier quoted context omitted.

I'm not entirely convinced that MongoDB is better suited or a natural mapping to DDD concepts in practice, it's just more convenient for developers who want to build things fast. My thoughts on this pattern are to still use a robust, reliable db (Postgres) behind a message queue for the event store. Postgres does almost all of the things I need with the reliability that I need while letting me sleep at night. An even…

"just more convenient for developers who want to build things fast" - that's a compelling advantage for Mongo, isn't it? I agree a robust, reliable db is super important - but isn't Mongo too, at this point? Even if it wasn't back in 2012? I thought most of the reliability issues and bad defaults were fixed by now...

My (in)experience with Mongo leaves me with a certain existential dread that I just can't shake. Also for that sort of thing these days I'd be more likely to use ElasticSearch than anything (this absolutely terrifies me actually, but I'm seeing companies do this) and eat the extra infrastructure expense. Serves the same function and gives me insanely powerful tools to process the data without having to write any code.

In my planning for problem domain changing, personally I'm going to be writing a (relational) schema for the new data model anyway, which will be Postgres, and playing my event store over it and doing one-way writes to it going forward anyway. I'd rather reduce the mental maintenance overhead of two different databases to one.

Re: Why Did So Many Startups Choose MongoDB?

#129

Post by felipeccastro »

busterarm wrote: post #128
felipeccastro wrote: post #125

Earlier quoted context omitted.

"just more convenient for developers who want to build things fast" - that's a compelling advantage for Mongo, isn't it? I agree a robust, reliable db is super important - but isn't Mongo too, at this point? Even if it wasn't back in 2012? I thought most of the reliability issues and bad defaults were fixed by now...

My (in)experience with Mongo leaves me with a certain existential dread that I just can't shake. Also for that sort of thing these days I'd be more likely to use ElasticSearch than anything (this absolutely terrifies me actually, but I'm seeing companies do this) and eat the extra infrastructure expense. Serves the same function and gives me insanely powerful tools to process the data without having to write any code…

Interesting. I've always thought event store was an interesting pattern, but not something as a default architecture for typical business apps, probably because of the added complexity in maintenance.

If you're building your relational db based on the event store, I'd imagine even something simpler like Mongo would do it, but I agree that having a single db to maintain is an important advantage.

Re: Why Did So Many Startups Choose MongoDB?

#130

Post by everdayimhustln »

thisisit wrote: post #103
matthewowen wrote: post #68

Earlier quoted context omitted.

Have you ever worked on a significant project using MongoDB? I did. I wouldn't use it again. But reliability just wasn't an issue. There was a time when there were insane defaults that made this an issue, but that's a long time ago.

Any idea about Memsql? We are evaluating it at our company and all the info is kind of fuzzy.

For those actually needing scalable, resilient nosql, CouchBase ia worth evaluating.
Post reply on HN