Hacker News new | ask | show | jobs
by alanh 4704 days ago
I’m not a NoSQL expert, but everyone I know who is considers Mongo a joke in production. And I would never use Angular in production apps (“painfully slow” is reason enough but I have ideological differences as well). That makes saying “no” to this stack easy.
7 comments

Does "everyone you know" have recent experience running Mongo in production? Because I have, and from my perspective calling it "a joke" is borderline trolling.

I'm not trying to be hostile, but you've got to understand that Mongo is most certainly not a joke, has lots of support, and is a very appealing option in a number of cases.

> very appealing option in a number of cases.

What cases do you have in mind?

Mongo sucks. I've used it in production for millions of people. I would never recommend it ever again. It's convenient, about the same way a hooker is.
Maybe your app wasn't suited for what it's good as. A File system would suck as a relational database... that doesn't mean it sucks in general. I suspect you had the same problem with Mongo.
It's confusing to see responses like this.

We continually hear about how great MongoDB supposedly is from its advocates, with them claiming it's suitable as a general-purpose database.

Yet when somebody who has apparently used it in a production setting speaks out against it and its numerous flaws, the problem isn't with MongoDB. No way! It's a "problem" with the app "not being suited for" what MongoDB is "good at".

I don't thing any database/technology is well suited for everything. And never said as such.

But as a counter point... We don't know this was a 'general purpose' problem... so your point isn't even valid even if you were responding to something I said... Unfortunate.

Rapid iteration comes to mind (as a result of its lack of schemas). It's also great if your objects are JSON documents, and as such it's particularly suited for uses such as a backend to Backbone.

Those are two areas in particular where I would first look to Mongo.

Don't lie to yourself, it has schemas. They are just implicit. Want to write JavaScript migration scripts for changing the Schema? I sure don't. But that is not even the begining to describe how broken mongodb design is. getLastError as a way to do write confirmation?
You can call them whatever you want, but I don't need to write any migration scripts when I change the schema. Writing a migration script MIGHT be a good idea, depending on my setup, but I definitely don't NEED to.

I don't really know what you mean about the design being "broken", unless you mean that it's "different", in which case I would agree.

As for write confirmation, you have flexibility in that regard. You don't need to be checking getLastError for write confirmation[0], though if you wanted to use a broken pattern, you could.

[0] http://docs.mongodb.org/manual/core/write-concern/

The first reason sounds a lot like 'hacking things out.' That is wonderful in the early stages of development, but 'production' doesn't just getting the app live quickly. With an ORM, let's take Rails as an example, migrations make schema changes extremely fast.

As for JSON, Postgres has first class support for JSON data field types.

I haven't seen any benchmarks that make it seem like Angular is "painfully slow." AFAIK, its on par or faster than ember.js and knockout.js. What would you use instead for MV* in the browser?
Our relatively simple Angular app was regularly consuming 100% CPU for literal minutes and ate up 600MB of RAM until we dramatically reduced not-actually-that-crazy number of API calls we made on load (from less than 100, mostly prefetching data – to less than 15, pr-fetching sacrificed). It is mostly related to Angular’s “dirty checking” and ajax management. I have met others with the same problem. (Their solution? Use Backbone!)
I think its a lot to ask but would you consider making a sample application that replicates this same behaviour?
I haven't actually seen any decent benchmarks between those systems as a whole. Most comparisons seem to shy away from that (between some candidates it probably doesn't make sense to benchmark anyways). But if you've seen anything interesting on that front, I'd be thankful if you could post it. And, you're right, so far Angular hasn't let me down regarding speed.
Mongo is incredibly productive. In the "lean startup" sense it is an easy database to start with.
Exactly the discussion i had today with a colleague. Mongoose makes it incredibly easy to get started and iterate rapidly.

I have yet to experience MongoDB in a large scale production environment and the common pitfalls often cited, but let's face it - If you're Start-Up has scalability issues, it's prob a nice problem to have.

Based on my personal observations, i suspect the lack of adoption is because founders are thinking about scale prematurely - which is rather Anti Lean Startup and Anti-Pg anyway.

Sounds like the information you've been given is in the wrong context.

I've had MongoDb running on my laptop in less than 5 mins and used it locally for multiple projects without issues.

The kind of problems you mention probably occur on very heavy use but i've never witnessed it myself.

For small scale stuff and getting up and running quickly, i've not used anything as convenient as Mongo

Note: I'm on Windows.

Also consider MongoHQ - They have a really good Start-Up package.

please ignore. I always manage to click the wrong button to reply on the mobile app
Is MongoDB the right DB for every size of startup? What about the people who just want to try different projects on 1 (one!) single server?

What I've read about MongoDB, it wants to use all the memory it gets. So it's only usable if it is running on its own server. (And in the beginning of MongoDB it had to be 2 servers if you didn't want to lose data.)

Is this a false information again? Am I falling for anti MongoDB FUD again?

quick someone tell doubleclick that angularjs is painfully slow
I love Angular and have never found it to slow working with even quite complex directives and tons of filters. API responses take longer than Angular does to load.
What about asking these people: http://www.mongodb.org/about/production-deployments/ if it's a joke in production?
I saw a couple engineers from Craigslist present at a Mongo event within the last year, and they strangely acted as if Mongo were a joke—that is, they treated it like a playground, continuously talked about how and where it broke, and continuously reminded us that they didn't care about its data integrity because they were just messing around.
What's wrong with Angular? Why is it slow?