7 ms·

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

by tete 12y ago

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.

Nitramp 12y ago
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 http://aphyr.com/posts/284-call-me-maybe-mongodb
- jpgvm 12y ago
  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.
- craigching 12y ago
  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.
  - nemothekid 12y ago
    Just because you haven't had a failure yet, it doesn't make the test any less true.
    - craigching 12y ago
      Three years? Numerous customers? That's good enough for me so far.
      - Nitramp 12y ago
        Have you actually tested a net split situation, or a crash, or what it'd take to recover?
        craigching 12y ago
        Yep, sure have. And you still need backups of your data, that's just good sense.
        craigching 12y ago
        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.
craigching 12y ago
> 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!
- yangyang 12y ago
  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/ http://2ndquadrant.com/en/resources/bdr/, https://wiki.postgresql.org/wiki/BDR_User_Guide https://wiki.postgresql.org/wiki/BDR_User_Guide) based on the aforementioned logical changeset support in 9.4.
  - kennu 12y ago
    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/ 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.
    - yangyang 12y ago
      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.
personZ 12y ago
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.
- notastartup 12y ago
  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".
  - iksose 12y ago
    ASP & PHP servers don't have exceptional performance but they're 98% of the web
  - general_failure 12y ago
    My understanding is that people pick node.js because of simplicity and not for speed.
    - notastartup 12y ago
      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.
jeffdavis 12y ago
"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.
zaphar 12y ago
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.

by tete 12y ago

Nitramp 12y ago

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 http://aphyr.com/posts/284-call-me-maybe-mongodb

jpgvm 12y ago
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.
craigching 12y ago
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.
- nemothekid 12y ago
  Just because you haven't had a failure yet, it doesn't make the test any less true.
  - craigching 12y ago
    Three years? Numerous customers? That's good enough for me so far.
    - Nitramp 12y ago
      Have you actually tested a net split situation, or a crash, or what it'd take to recover?
      - craigching 12y ago
        Yep, sure have. And you still need backups of your data, that's just good sense.
        craigching 12y ago
        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.

craigching 12y ago

> 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!

yangyang 12y ago
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/ http://2ndquadrant.com/en/resources/bdr/, https://wiki.postgresql.org/wiki/BDR_User_Guide https://wiki.postgresql.org/wiki/BDR_User_Guide) based on the aforementioned logical changeset support in 9.4.
- kennu 12y ago
  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/ 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.
  - yangyang 12y ago
    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.

personZ 12y ago

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.

notastartup 12y ago
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".
- iksose 12y ago
  ASP & PHP servers don't have exceptional performance but they're 98% of the web
- general_failure 12y ago
  My understanding is that people pick node.js because of simplicity and not for speed.
  - notastartup 12y ago
    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.

jeffdavis 12y ago

"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.

zaphar 12y ago

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.