
Ask HN: Why use MongoDB? - victormx
I have given three chances to mongodb. Not fill my expectations, in the end for me there will be a need for a join or complex queries. I have tried to use it in 4 projects and does not convince me. Can anyone give me a reason other than replication to use it
======
mattkrea
What language are you writing your project(s) in?

If you are using Node you should use Mongoose and then you may see why some
people love Mongo. Complex queries and joins (not technically called joins I
guess) are incredibly easy to accomplish with that module[1]. Personally, I
have migrated back to MySQL since I was unable to convince my colleagues that
Mongo would last long-term and frankly I am not 100% confident either for the
kind of business applications that we need[2].

[1]:
[http://mongoosejs.com/docs/populate.html](http://mongoosejs.com/docs/populate.html)

[2]: payment processing industry handling billions of records

~~~
victormx
I used java, node and .net, this question it's because i love mongodb,I like
mongodb and many of its features but I have not found a use for my projects
and so far I'm only seeing mongodb for small projects or simple queries. I
have not used mongoose because i do not like ORM, but I'll do some testing on
it

~~~
mattkrea
I would strongly recommend it.

My experience with ORMs has not been pleasant either but Mongoose was very,
very nice.

------
untog
I've found it useful in storing and querying JSON documents. Basically,
scraping an API (for me it was an OpenTripPlanner instance I had set up) and
then being able to query any property in the data very easily.

But I didn't use joins, nor was this anywhere near a production server. From
my understanding, if you have a heavy requirement for joins then you just
shouldn't be using MongoDB in the first place. It isn't a traditional
relational database.

~~~
victormx
I have come to the same conclusions, for that reason I asked this question,
one of the reasons that i like mongodb is that data is in JSON

~~~
neilk
Postgres is getting there, with JSON columns. You can do hstore if you like
key-value, or mix it with plain old SQL tables. This combination works well
for me.

~~~
glimcat
I use Postgres HSTORE via Flask-SQLAlchemy. As far as my code knows, it's
dict() all the way down.

And if I want to attach non-kv data like last_updated, or have foreign key
relationships between one dict() and some other stuff like the corresponding
user record's primary key - it's already in an RDB.

------
rgo
Our enterprise on-premise software package runs on Mongo, before it used to
run on relational dbmses. Here's why we changed:

\- flexible document schema reduces migration complexity greatly, really
important when we have our software deployed on many customers sites. \-
flexible schema is also important to our product because we support custom
forms and fields. \- the ability to store and search nested data \-
replication is easy to setup \- easy to maintain, good export formats \- no
dependence on customer's DBAs \- no more frustrating explain-plan debugging of
underperformant joins \- text search (simple yet useful) \- regex support \-
fast, up to 3x faster than SQL based engines for our use cases. \- works well
as a cache \- decent also as a work queue with tailable capped collections.

Our biggest complain: the lack of transactions combined with data
denormalization pitfalls is a PITA to work around in code.

Overall just a great db for when you need a flexible schema.

------
wturner
I just use Mongo as a big JSON / BSON storage locker for node/express stuff
I'm learning. The apps all involve DOM manipulation and using HTML client
API's where div id's and their positional data are stored as JSON/BSON in
Mongo ( then looped through and pulled back out when the user wants them ).
Mongo seem really convenient for this kind of thing. I've done one similar
project with PHP/MYSQL before and the workflow seemed a bit more 'heavy'
compared to Mongo whichs thus far feels a bit more in alignment with this work
style( I'm also using node/express which is a bit complimentary ). So I guess
my comment is more validation that its good for making small toys. Ha!

------
joeclark77
I would think it's useful for any kind of data where it's "write once, then
read only" and there's a standard sequence (key) you'll use for almost every
query. A blog, for example, or a twitter-type feed. In those cases, you're not
doing complicated interactions with the data, just "SELECT" everything in
order and display it. In those kinds of applications, consistency and
atomicity doesn't matter much, and a NoSQL database might give you lower
latency.

------
canatan01
You should use the DB you need. Sometimes SQL is best, sometimes nosql. For
me, the prime reason to use mongo is if I have data that I cannot structure
before hand.

~~~
myblake
I'd also argue that being able to be more adaptive with how data is structured
can be good for a project where things change very quickly. If you have
something where the data model is of simple to moderate complexity and
persistence is required, the smaller overhead of changing things on mongo vs
having to update a SQL schema can be worthwhile. (For reference my specific
use case was using rails with activerecord vs mongoid here).

