5 ms·

Right here. =) http://blogs.enterprisedb.com/2014/09/24/postgres-outperforms-mongodb-and-ushers-in-new-developer-reality/ http://blogs.enterprisedb.com/2014/09/

• zobzu 12y ago
  The tldr: Ingestion of high volumes of data was approximately 2.1 times faster in Postgres MongoDB consumed 33% more the disk space Data inserts took almost 3 times longer in MongoDB Data selection took more than 2.5 times longer in MongoDB than in Postgres
• tracker1 12y ago
  Now if only I had a baked in solution for a replica set, with hot master failover and command forwarding in PostgreSQL like I get with MongoDB. Quirky bolt-on solutions, and those requiring a contract with EnterpriseDB or others need not apply. I really don't mean for this to be as snarky as it sounds... I'd really love these features in PostgreSQL along with PLv8, I'd rather use that than MongoDB... unfortunately having a good in the box solution for MongoDB over PostgreSQL is a bigger breaking point than lack of Joins in my use case.
  • eknkc 12y ago
    Same here, we use MongoDB with 3 member replica sets even for small deployments. It's easy, built in, works fine with all official drivers. I'd love to use PostgreSQL but we don't have resources to manage a decent replica set installation with all the sysop burden..
  • moe 12y ago
    with hot master failover and command forwarding [...] like I get with MongoDB. Failover is documented to not work very well in MongoDB (data loss): http://aphyr.com/posts/284-call-me-maybe-mongodb http://aphyr.com/posts/284-call-me-maybe-mongodb On the postgres side RepMgr makes dealing with replication quite easy: https://github.com/2ndQuadrant/repmgr https://github.com/2ndQuadrant/repmgr See also this recent thread on the PostgreSQL mailing list: http://postgresql.nabble.com/Fully-automatic-streaming-replication-failover-when-master-dies-td5788393.html http://postgresql.nabble.com/Fully-automatic-streaming-repli...
    • Xylakant 12y ago
      I'd be careful quoting the aphyr post in that context. PG also had some failures, even in the non-replicated setup: http://aphyr.com/posts/282-call-me-maybe-postgres http://aphyr.com/posts/282-call-me-maybe-postgres Failures are just a property of distributed systems, some fail in ways that are better for you, some fail in ways that are worse, but sooner or later they all fail. It's a tradeoff which one you choose.
      • moe 12y ago
        PG also had some failures MongoDB loses acknowledged writes in its supposed "highest consistency" mode. PostgreSQL does not. That's a pretty fundamental difference, don't you think?
        • Xylakant 12y ago
          MongoDB was tested in a replicated setup, PG not, that's a pretty fundamental difference. Loosing acked writes in a master-slave replication with failover would be expected with a sufficiently large replication lag even for PG. MongoDB is about the last database I'd pick for any given scenario, but I acknowledge that there are people that have a usecase where it might be a good fit because the tradeoffs work out for them.
          • moe 12y ago
            Loosing acked writes in a master-slave replication with failover would be expected with a sufficiently large replication lag even for PG. Bullshit.
• arthursilva 12y ago
  I don't like this benchmark. But as long as you don't heavily rely on updates or big documents I'm sure Postgres is at least competitive with Mongo.
  • arthursilva 12y ago
    Why the downvotes? Apparently people didn't care to check the source code before drawing conclusions ...