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

Was MongoDB Ever the Right Choice?

simplethread.com

Post reply on HN
Print view View original

21–30 of 224 posts

Re: Was MongoDB Ever the Right Choice?

#21

Post by gnur »

Off course it was, prototyping speed on mongodb was (and probably still is) always excellent.

Some features that don't scale are very nice to have when you don't have scaling issues. For example, if you add tags to your documents and you want to query on those tags (find all documents containing tag A and B), it's nice that's just a builtin.

I haven't found a single datastore that is as developer friendly that supports that use case, so for now, I'm sticking with mongodb for my pet project.

(if you know of a datastore that has support for this query out of the box, please let me know)

Re: Was MongoDB Ever the Right Choice?

#22

Post by isoos »

gnur wrote: post #21

Off course it was, prototyping speed on mongodb was (and probably still is) always excellent. Some features that don't scale are very nice to have when you don't have scaling issues. For example, if you add tags to your documents and you want to query on those tags (find all documents containing tag A and B), it's nice that's just a builtin. I haven't found a single datastore that is as developer friendly that suppor…

Postgresql JSONB?

Re: Was MongoDB Ever the Right Choice?

#25

Post by scottfr »

gnur wrote: post #21

Off course it was, prototyping speed on mongodb was (and probably still is) always excellent. Some features that don't scale are very nice to have when you don't have scaling issues. For example, if you add tags to your documents and you want to query on those tags (find all documents containing tag A and B), it's nice that's just a builtin. I haven't found a single datastore that is as developer friendly that suppor…

If I understand your query correctly, Google Cloud Firestore would support it.

https://firebase.google.com/docs/firestore/query-data/querie...

Re: Was MongoDB Ever the Right Choice?

#26

Post by jchw »

gnur wrote: post #21

Off course it was, prototyping speed on mongodb was (and probably still is) always excellent. Some features that don't scale are very nice to have when you don't have scaling issues. For example, if you add tags to your documents and you want to query on those tags (find all documents containing tag A and B), it's nice that's just a builtin. I haven't found a single datastore that is as developer friendly that suppor…

Someone has mentioned PostgreSQL jsonb, which basically works the same way as Mongo, although I won't argue the query syntax is easier to learn.

But also, PostgreSQL supports arrays, so you can have much more native tags as well, and it can be indexed and searched in a more traditional SQL fashion.

I have only used this with Django ORM, but I believe it's pretty straightforward if my memory is correct.

Re: Was MongoDB Ever the Right Choice?

#27

Post by _Codemonkeyism »

MongoDB with it's JSON model helped us develop features and iterate much faster than the previous MySQL/PG. So it was a huge win for use (but we had some pain with some issues).

Today we use PG everywhere with JSON, though still the library support for JSON in Mongo is often a little bit better than in PG drivers.

Re: Was MongoDB Ever the Right Choice?

#28

Post by giornogiovanna »

gfody wrote: post #19
mikekchar wrote: post #6

I always supposed that document databases were based on object databases from the early 90s... And that the "NoSQL" craze was simply a continuation of that progression. I mean there is a difference between NoSQL and no schema. The early object databases had schemas. The reason they wanted to abandon SQL was because they believed that they never wanted relational data: they just wanted a persitance layer for their bus…

Mongo's debut was well timed to ride the JSON crazewave.

Sorry for my ignorance, but what JSON craze?

Re: Was MongoDB Ever the Right Choice?

#29

Post by geezerjay »

mruts wrote: post #15
sonnyblarney wrote: post #10

I actually think NoSQL might be better for MVP and prototyping. Why? Because they can handle churn more quickly, and you don't have to worry about scale. Once the data layer starts to resonate around a solution ... then pick the right horse for it.

Why not just use a SQL db that handles json and stick everything in a couple columns? Changing databases is a lot of work, and as far as I can tell, mongo isn’t really providing much value over SQL dbs that already support schemaless json columns.

> Why not just use a SQL db that handles json and stick everything in a couple columns?

Honest question: what's wrong with just defining a domain model, adopting an ORM and a serialization framework, and simply go with a conventional RDBMS? Afaik all reference web application frameworks handle this right out of the box.

Re: Was MongoDB Ever the Right Choice?

#30

Post by matthewmacleod »

I would argue that MongoDB is not—and has never been—the best choice for solving any particular technical problem. But it had some other "advantages" over other, better solutions – in that it was easier to set up, didn't require schema definition, had a passable clustering story etc.

I have worked with at least one company that had been built using MongoDB as a primary data store from day one. This caused untold pain later on, but the trade-off is that it likely allowed the company to exist at all – the founder being more of a domain expert than a technical expert, but being able to use it to scale their idea pretty quickly without having to pay much attention to all that tedious "reliability" and "safety" nonsense :)

That said, it's not something that an experienced developer should be using for anything nowadays, and the solution might be to ensure that competing alternatives (like Postgres) can learn from why MongoDB became popular and seek to solve some of the pain points in their own implementations.

Post reply on HN