Live data from Hacker News

Why you should never, ever, ever use MongoDB

cryto.net

21–30 of 33 posts

Re: Why you should never, ever, ever use MongoDB

#21

Has anyone had any success migrating from MongoDB over to Postgres? My team and I decided to try out MongoDB for a new app we wrote because the data model seemed to fit the idea of a schema-less document quite well. But many months later, Mongo has caused a few more headaches than its been worth and we are slowly leaning towards using a more traditional data model. I was thinking that one approach might be first to j…

That’s plausible for sure.

The company I worked for until recently maintains a core data store in Mongo, but mirrors the content into a Postgres database for use by other, newer applications (which don’t modify the data).

We built a tool which streams the MongoDB Oplog into tables containing a JSONB column for the document - https://github.com/mudge/oplogjam - and it has been pretty good to work with. Sefilitely am approach than can work well in my experience, though!

Re: Why you should never, ever, ever use MongoDB

#22
post #14

This article is very old (in internet years) and Mongo moves very fast. So most of the things in the article are way, way out of date. Very smart people working at Mongo understand where they need to get and how to get there, and they are well along the path. Bad old code is being replaced with better new code, limited mainly by backward compatibility bother. It is still the case (and will remain for a long time -- a…

I guess I just don’t get why you’d use this over Postgres if it has such a heritage of unreliable behavior and still doesn’t give you actual performance benefits. If you need a document store use Couchbase, CouchDB 2.0 or Postgres blobs. If you need a cache use memcache. Why Mongo, especially after the latest licensing headache?

Re: Why you should never, ever, ever use MongoDB

#23

> ... is not ACID-compliant All the other points are interesting, but I'm really tired of people bringing up this fact as a slam against NoSQL databases. Not everyone needs ACID compliance.

Not being that is one thing, but (at least in the past?) they implemented updates as non-atomic delete and insert, which is just crazy bad. It's one thing not to be ACID but having a query not return some entry at all because it's being concurrently updated is... an interesting design choice. Edit: link https://blog.meteor.com/-654b6594a827

Hence why CouchDB’s append-only approach had always been the better choice. Why Mongo ever became more popular still boggles my mind.

Re: Why you should never, ever, ever use MongoDB

#24
TLDR All databases corrupt data, and mongodb is reasonably performant, and also easier to scale than most.

I have had instances of data corruption in production servers with both OracleSQL and MySQL. Several sql databases take forever to fix bugs (e.g. the crappy handshake in MySQL took 5y to get fixed).

MongoDB is actually the best database I have ever used in production, in question of both performance AND scalability. So I call your bluff there, no data, no fact.

Re: Why you should never, ever, ever use MongoDB

#26
post #25

> ... is not ACID-compliant All the other points are interesting, but I'm really tired of people bringing up this fact as a slam against NoSQL databases. Not everyone needs ACID compliance.

Not only that but mongo is acid compliant now

It is ACID if you add all the query flags to say you want that. The majority of users don't, because it costs performance, which is in many / most? applications more important than correctness.

Re: Why you should never, ever, ever use MongoDB

#27

Earlier quoted context omitted.

Not being that is one thing, but (at least in the past?) they implemented updates as non-atomic delete and insert, which is just crazy bad. It's one thing not to be ACID but having a query not return some entry at all because it's being concurrently updated is... an interesting design choice. Edit: link https://blog.meteor.com/-654b6594a827

Hence why CouchDB’s append-only approach had always been the better choice. Why Mongo ever became more popular still boggles my mind.

I think that's because MongoDB makes far more claims around performance around big data than CouchDB does. CouchDB has always focused a lot more on features like having a built in REST-like API, replication, Fauxton, fault-tolerance, etc. There was also a lull where CouchDB wasn't seeing very much development, but that's changed since before the arrival of version 2.0. I wish CouchDB would see a little more popularity than it has, as I've found it(along with PouchDB) to be handy in a lot of projects.

Re: Why you should never, ever, ever use MongoDB

#28
If you need a document-based approach there are a few options you might want to consider (and certainly not table-based relational db). I've migrated part of our project to Couchbase (not CouchDB or others) and beside a technical comparison... I've appreciated the ease of onboarding for new hires to this technology, scalability and maintainability... all aspects that become critical in the long run. If your project involves mobile clients, I'm sure your devs will appreciate the easy to use SDKs packaged with features (I personally loved the fine grained offline sync with backend and/or between two local DBs)

A technical comparison is here, but it's on the couchbase site so it could be biased https://www.couchbase.com/comparing-couchbase-vs-mongodb

Re: Why you should never, ever, ever use MongoDB

#29
I'd definitely recommend Couchbase, I feel it's a more robust and feature complete NoSQL document store for most use cases. It's easier to set up, and write performance is much higher than MongoDB in most configurations due to the master-master architecture. The N1QL query language is the most robust NoSQL query language out there, and it's SQL based so very easy to use. Additionally, in the last year, Couchbase has added a complete Full-Text Search system as well as Analytics, which is SQL-based MPP analytics querying with no ETL (think built-in Hive/Hadoop on JSON documents).

Re: Why you should never, ever, ever use MongoDB

#30
Couchbase, a similar document database, has many advantages over MongoDB such as being able to query with a flavor of SQL as well as clusters having P2P nodes that share the same services and structure. This means you get a familiar query language and you don't have to worry about configuring and managing different node types in your cluster. A while ago I wrote a guide for quickly and easily migrating your data and application code from MongoDB. http://labs.couchbase.com/mongodb-to-couchbase-cookbook/
Post reply on HN