Slashdot Mirror

← Back to Stories (view on slashdot.org)

PostgreSQL Outperforms MongoDB In New Round of Tests

Posted by Soulskill on from the there-can-be-only-lots dept.

New submitter RaDag writes: PostgreSQL outperformed MongoDB, the leading document database and NoSQL-only solution provider, on larger workloads than initial performance benchmarks. Performance benchmarks conducted by EnterpriseDB, which released the framework for public scrutiny on GitHub, showed PostgreSQL outperformed MongoDB in selecting, loading and inserting complex document data in key workloads involving 50 million records. This gives developers the freedom to combine structured and unstructured data in a single database with ACID compliance and relational capabilities.

9 of 147 comments (clear)

  1. It doesn't matter by DoofusOfDeath · · Score: 5, Funny

    Because Postgres isn't web-scale. I want web-scale.

    1. Re:It doesn't matter by DoofusOfDeath · · Score: 5, Funny

      I'm afraid you were still semi-wooshed. I was actually making a reference to this.

    2. Re:It doesn't matter by Anonymous Coward · · Score: 5, Informative

      the linux kernel doesn't even have to load it into RAM, it goes from disk to network directly.

      Oh really? so your network card is a bus master and can initiate transfers from other peripherals without using DMA?
      I assure you, the Linux kernel still loads the file into RAM. Your RAM is fast compared to SATA or Ethernet, it's an excellent staging ground for such transfers. But obviously you don't need to load the entire file before you start sending it out, there are tricks that let the kernel deal with it by tracking the DMA status of the ethernet card and using memory mapped files.

    3. Re:It doesn't matter by Warbothong · · Score: 5, Funny

      I can only think of one database that isn't "webscale", and that's TinySQL, which I still use for personal web projects regardless.

      I hadn't heard of TinySQL, so I just Googled it. From http://sourceforge.net/project...

      > tinySQL is a SQL engine written in Java.

      Is the name meant to be ironic or something?

    4. Re:It doesn't matter by plopez · · Score: 5, Funny

      "I can only think of one database that isn't "webscale", and that's TinySQL, which I still use for personal web projects regardless."

      You've just made all those MS Access developers cry.....

      --
      putting the 'B' in LGBTQ+
  2. "Small" amount of data by ranton · · Score: 5, Interesting

    I am confused. If they are testing the performance of ACID and BASE database systems, why did they use a data load that can easily fit on a single computer? The data size for both databases was under 150 GB which can easily sit on a single hard drive let alone a single server. Why would a BASE database have any edge over an ACID one for a data set that does not require distribution between multiple servers?

    It is still important to see how much faster a more established DBMS is than a relative newcomer for smaller loads, but I still feel this comparison is a bit lacking.

    --
    -- All that is necessary for the triumph of evil is that good men do nothing. -- Edmund Burke
    1. Re:"Small" amount of data by Anonymous Coward · · Score: 5, Informative

      Have you used a version of PostgreSQL that is not 10 years old? The vacuum process performs some necessary work asynchronously from your transaction, so that you can have higher concurrency and scalablity. The modern autovacuum does not have locking problems.

  3. Re:Replication anyone? by Anonymous Coward · · Score: 5, Funny

    Can PostgreSQL do replication? Not really.

    That's news to me, I guess the data on our read servers just magically appear and what more magically appear to be the same data we need there.

  4. Not surprising... by rgbatduke · · Score: 5, Interesting

    ... because of the way MongoDB actually stores records and parses them. It is more or less a simple tree or linked list, and hence doing almost anything involves decending branches to the leaves. This is horrendously inefficient in many contexts, while still being perfectly lovely in others. Just doing a match, though, can involve a non-polynomial time search. Maybe they've improved this from when I was trying to use Mongo to drive modelling, but I doubt it as it would have involved substantially changing the way the data is actually stored and dereferenced. I had to cheat substantially in order to get anything like decent performance, and any of the SQLs outperformed it handily.

    Note well that it was strictly a scaling issue. For small trees and DBs, it probably works well enough. For large DBs with millions of records and substantial structure, it is like molasses. Only worse.

    rgb

    --
    Even when the experts all agree, they may well be mistaken. --- Bertrand Russell.