Hacker News Reader

Comment by pedalpete | Hacker News Reader

Mongo is often quick to get people started and simple to work with. No migrations, or joins, etc. etc.

It's not for every project, but quite nice for prototyping.

It's not that you don't have migrations, it's that you move that logic to your application code. I personally find that to be a terrible trade-off. People make the same arguments in favor of mutable data structures: you benefit initially from having everything mutable, but then you start writing code to compensate for the flexible nature of it and suddenly you have a whole new set of issues.

Except people have bad tendency to not throw out prototypes and are unwilling to do the work to deal with bad decisions from the prototype time...

That sentence should be written someplace where everyone can see it everytime a project starts.

Migrations don't actually take more time than defining the schema implicitly in your application, and you don't even need to think about joins at all if it's only going to be a prototype.

MongoDB is far from "simple to work with". This is 100% marketing bullshit (along with dubious claims like it being "fast" when it never has been), trotted out by MongoDB's marketing department. Let's not forget that it has always been a commercial project.

EDIT: And to clarify, relational databases and document stores are not interchangeable. You need to pick the one that reflects your data model most accurately.

Usually that's going to be "relational", sometimes it will be "documents" - but even if it is, there are better options than MongoDB.

Not only prototyping. If the final product will have a moderate amount of users generating a moderate amount of data, there is really no drawbacks with mongoDB. The real cost is development time.

Of the mongoDB projects I've been involved with, I've always wanted to do large complex joins and filters which was just didn't perform as well as relational databases, and there is no support (as far as I know) for geo-coded data.

That's why I suggest it's good for prototyping, maybe it will work for some projects long-term, but I don't think it's the norm as mongoDb would suggest.

However, most prototypes don't end up as successes, so that's where I figure it's worth the switching cost once a go-nogo decision is made.

There are many drawbacks when using MongoDB, especially in the development time department: http://cryto.net/~joepie91/blog/2015/07/19/why-you-should-ne...

It's a completely fallacious argument. Using MongoDB doesn't save you time, it just shifts the effort towards a later point, where it will require several times as much effort to fix shit, which may not even succeed and you may end up with corrupted data.

It's really not worth it.

Reply on news.ycombinator.com