Comment by tete | Hacker News Reader

Comment by tete | Hacker News Reader

Parent Full thread

Did I miss something? MongoDB was never ever faster than Postgres. That's nothing new. Most of these things are clear when one reads the MongoDB docs:

MongoDB stores Metadata, (nearly) uncompressed on a per document basis, so of course it uses way more diskspace. It doesn't store the data in any efficient way either.

Also it's pretty much unoptimized, compared to Postgres which has been around for a really long time so it's kinda slow.

Many functions in MongoDB are actually implemented in JavaScript, not C. So that's also a factor, even when I guess it's not the big one here.

MongoDB has a lot of limitations that can really bite yo (document size even though that's the smallest (gridfs), how you can do indices, even limitations in how your query can look like, etc

The only thing that's good about MongoDB is that it's nice for getting something up and running quickly and that it's a charm to scale (in many different kinds), compared to PostgreSQL. If PostgreSQL had something built in(!) coming at least close to that (and development has a strong focus there) it would be perfect.

For all these reasons many companies actually have hybrid systems, because sometimes one thing makes sense and sometimes the other.

The benchmark seems strange, cause there are many SQL and NoSQL databases that are faster and that's a kinda well-known fact. I think everyone who ever had to decide on a database system has known that, even without a benchmark.

This makes it kinda look like an advertisement (look at the company behind the blog).

Using PostgreSQL 9.3 with JSON for a while now and it's great. Also I know it is possible to scale PostgreSQL and it's really nice. Still a lot more complexity involved (again, depending on the use case).

Just use the right tool and please let's stop with such shallow comparisons, because I think it kinda harms the reputation of database engineers and system architects - and the authors of such comparison. When you look for real comparisons and example use cases, typical patterns or just some help one always stumbles across these things and they tend to quickly be out of date too, cause all well-known databases have a lot of active development going on.

The entire narrative behind MongoDB in the first chapters of its evangelism was performance, partly due to its document-oriented approach (things are quicker in some scenarios when you get rid of relations, and it was contrast against the many tables approach), which is something that you can only very recently do in pgsql, and partly due to implementation choices like the dangerous default lack of fsync.

Early evangelism for Mongodb was overwhelmingly one that hyped performance over all others. It was, somewhat infamously now, webscale.

So now pgsql (since 9.2, but vastly improved in 9.3) can also do the things that MongoDB does, better, if you want to do the document approach (which is a serious debate unto itself). That is news and is interesting.

As for scaling out, I would argue that 9.3 offers more realistic, robust options than MongoDB does.

I'll pose the inappropriate question. Unless you are going to do it right (RethinkDB) why write a brand new database at all (MongoDB?)

money, of course. position yourself well and investors come a-callin. buy yourself a lambo.

I wonder if Node.js will follow the same fate...get a nice dose of reality check.

It is mistakenly evangelized as also being faster, leaner, scalable, more concurrent than anything out there. Some clients would pay extra to redo CRUD using Node.js because it's "Asynchronous and We wanna Pay For Speed and Scalability".

My understanding is that people pick node.js because of simplicity and not for speed.

Wow. That's interesting, I really did not find asynchronous programming easy, with basic things like hooking up to database requiring you to go deeper into a chain of callbacks, forcing you to rely on duct tape solutions like futures or whatever they use now to work around the limits of Javascript, or having to write stuff in Coffeescript.

But some devs swear by it, I just fail to see what the advantages are.

ASP & PHP servers don't have exceptional performance but they're 98% of the web

Is MongoDB's distribution and scaling story really nicer? A cluster story that's easy to set up but then doesn't actually work (loses data, fails in potentially catastrophic ways) sounds not all that useful.

http://aphyr.com/posts/284-call-me-maybe-mongodb

MongoDB clustering is nothing short of disastrous.

If anything I hope databases like RethinkDB and even multi-master PostgreSQL if we ever see it learn from the most crucial mistake here - rolling your own consensus. (This goes for databases other than MongoDB, I don't meant to single it out here)

Stick to proven algoritms, ZAB, Paxos, Raft.

Mongodb is easy to setup as a single instance, but it is definitely no easier to setup for horizontal scaling compared to alternatives. I'm still not aware of anything that's both simple to setup and maintain for horizontal scaling in practice (not theory).

Cassandra is, but you're forced into a very simplistic data (sharding) model. (And probably Riak is too, but haven't used it.)

Cassandra is easier to scale than mongo, and yeah Riak is even easier, but they're still not easy unless you don't care as much about consistency and you can wait, and if your app is more about writes than reads.

It depends on your workload, but MongoDB has worked extremely well for us, we've never lost data. I love aphyr's posts on databases, but you can't use them as a blanket for everything.

Just because you haven't had a failure yet, it doesn't make the test any less true.

Three years? Numerous customers? That's good enough for me so far.

C'mon you know that isn't fair reasoning, you could say the same about running backups. Just because someone hasn't seen the need for backups for three years after numerous customers doesn't mean thats a good enough reason to not keep backups.

I'm not saying you shouldn't use Mongo, but to say Aphyr's assessment of database shouldn't be considered in all deployments isn't wise.

I'm not saying Aphyr's work isn't useful, it's the right tool for the job. For our needs and uses, it's been spectacular. I want to use Postgres, but it's HA isn't something I'm willing to expose to my customers. So I'm actually using MongoDB in anger ... and it's doing spectacular.

So let me leave off with our use case. We have few writes, little need for sharding (our largest customers run on a single node and keep the hot data in memory), we use acknowledged writes (MongoDB can be journaled you know), and our customers are willing to have three + nodes in an HA scenario. The HA is simple to configure. So far in three years we have no data loss.

What more information can I provide to make up for the downvotes?

As an aside, downvotes to me should be used for those that contribute nothing to a conversation. If you disagree with what someone says, state your disagreement so that we all, including me, can benefit from your better experience.

Have you actually tested a net split situation, or a crash, or what it'd take to recover?

Yep, sure have. And you still need backups of your data, that's just good sense.

Nitramp, I'm sorry you disagree with my experience. But instead of downvoting, why don't you contribute to the conversation with your own experience? At least my experience is taken from the real world and not from something I read on the internet.

Ok, granted, my experience is an anecdote, but downvoting me without disputing what I'm saying? Pure cowardice. At least counter with your own anecdote, don't downvote. Or let me know why I'm being downvoted, simply disagreeing shouldn't result in a downvote, that just kills the conversation.

"Just use the right tool and please let's stop with such shallow comparisons"

A lot of people may have thought, prior to this benchmark, that MongoDB was the right tool for all high performance JSON-related tasks.

> it's a charm to scale (in many different kinds), compared to PostgreSQL. If PostgreSQL had something built in(!) ...

This! A million times! I agree 100% that Postgresql is better than MongoDB in every way except in ease of replication (that's really my only need) for HA. We needed an embedded database in our product and I wanted so bad to use Postgres, but we needed HA and we needed our customers to be able to set it up. This was so important to us that we took the otherwise inferior solution.

Now, that said, I bring up the replication/HA issue every time one of these "postgres is better than mongodb" articles comes up. The last time I posted a Postgres developer responded to me that they're laying the groundwork for a good answer and that it's coming. I can not WAIT for that day!

Streaming replication is really not hard to set up in PostgreSQL. It is cluster-level; if you want to replicate a single database you'll need to use a 3rd party solution like Slony or Burcado (logical replication built on features in 9.4 will improve this).

2ndQuadrant have developed Bi-Directional Replication for 9.4 (http://2ndquadrant.com/en/resources/bdr/, https://wiki.postgresql.org/wiki/BDR_User_Guide) based on the aforementioned logical changeset support in 9.4.

I think your comment summarizes why this stuff so hard on traditional SQL; one doesn't even know where exactly to start. In MongoDB, you just turn on replication according to http://docs.mongodb.org/manual/replication/, which means basically adding one directive to mongod.conf and typing in the IP addresses of the nodes. MongoDB handles everything else for you. I'm not claiming that it's better or reliabler, just that it's really easy to set it up in 5 minutes.

I would suggest that if you've reached the point where you need streaming replication (rather than, say, a cron job uploading database dumps to s3), you've reached the point where you need to do your research.

You do have a point. PostgreSQL undoubtedly has many more knobs and do you do end up having to learn a fair bit to do stuff like replication.

I'd rather spend more time understanding things up-front and have a reliable solution rather than flick a switch and have something which initially works but I'm not too confident in. That's fine for initial development I suppose, but not in production.

It only takes an hour or so to google and read up on what the different ways of replicating data are in PostgreSQL, their advantages and disadvantages.

Are we really that scared of 'research'?

I get the feeling that a sizeable proportion of NoSQL users don't have much knowledge of relational databases at all, never mind replication. If you just want to persist some JSON data you already have, I suppose it is quite a large leap to start reading about relational algebra, ACID, undo/redo logs, SQL, and so on.

> Are we really that scared of 'research'?

You've missed the main point of why we use MongoDB. We use it embedded in our product and it's up to our customers to configure HA if they need it. Sure, we document the process for configuring it, but the simpler it is, the less likely a customer is going to have a problem with it.

I would agree with you if it were a database that we maintained in-house, yeah, it's certainly doable. But my main point is that this has to be done in the field at customers who are just trying to use our product.

You are absolutely right, it is as simple as adding the replSet name to your configuration, rs.init(), rs.add() for each other host that will participate in the replica set. Exactly the point.

It depends on what your measuring. I work on a project that gained significant speed improvements moving to MongoDB simply due to packing and unpacking the data. MongoDB BSON serialization was way faster than the ORM when building up the data objects after fetching from the database. In our workload that operation actually dominated the workload not IO.

This article is interesting because Postgres document store options may make it competitive to us when compared to MongoDB.

Reply on news.ycombinator.com