Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
Compare cell phone plans using Wirefly's innovative plan comparison tool ×
Databases Software Technology

PostgreSQL Outperforms MongoDB In New Round of Tests 147

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.
This discussion has been archived. No new comments can be posted.

PostgreSQL Outperforms MongoDB In New Round of Tests

Comments Filter:
  • by DoofusOfDeath ( 636671 ) on Friday September 26, 2014 @10:19AM (#48002259)

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

    • by mwvdlee ( 775178 ) on Friday September 26, 2014 @10:24AM (#48002305) Homepage

      "Web-scale" is "big enough to hold a Wordpress database"?

    • Re:It doesn't matter (Score:4, Informative)

      by i kan reed ( 749298 ) on Friday September 26, 2014 @10:28AM (#48002351) Homepage Journal

      I was about to get wooshed, and post something about how "web-scale" isn't any kind of meaningful standard, but then I thought better of it, looked it up, and found it's MongoDB's tagline.

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

      • by DoofusOfDeath ( 636671 ) on Friday September 26, 2014 @10:40AM (#48002503)

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

      • by Warbothong ( 905464 ) on Friday September 26, 2014 @11:06AM (#48002803) Homepage

        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... [sourceforge.net]

        > tinySQL is a SQL engine written in Java.

        Is the name meant to be ironic or something?

      • by plopez ( 54068 ) on Friday September 26, 2014 @11:16AM (#48002919) Journal

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

        • by astro ( 20275 )

          This comment just made me shudder with the painful memories of writing web applications in Cold Fusion that used ADO to talk to MS Access files as the DB backend in like 1998. Ugh.

          • This comment just made me shudder with the painful memories of writing web applications in Cold Fusion that used ADO to talk to MS Access files as the DB backend in like 1998. Ugh.

            You think that's bad? I was doing this in 2008.
            (First task was to get them the fuck out of access and onto an actual SQL server.)

        • Statement no one is going to argue with to justify myself:
          Access isn't a database, and access users aren't developers.

        • I'm an Excel user, you insensitive clod!

      • I really, really hope nobody is using SQLite for a production web database, but sadly I know somebody probably is.

        • by mi ( 197448 )

          I really, really hope nobody is using SQLite for a production web database, but sadly I know somebody probably is.

          I was considering it, actually — for when the web-server and the DB must be on the same host for budgetary reasons.

          What's wrong with it?

          • Why not embedded Firebird? Sounds much less hazardous to me.
            • by mi ( 197448 )
              It is not my application. It does support SQLite (among others), though.

              But let's not change the subject — nor answer a question with a question...

          • The performance degrades (or at least, doesn't scale well) once you have multiple processes accessing the same database, as you would be on a web server. It's a great tool, don't get me wrong, and I can definitely see the use case for a test environment. But even on a single-server system, you're better off with an actual database process.

            • by ls671 ( 1122017 )

              It reminds me of msql (miniSQL) that was single threaded so a long request would make the others wait. In another topic, MS-SQL server login was single threaded back in 2000 although the server could handle parallel requests I think. I assume it must have been fixed by now. You could deny all other users from login just by telnetting to the MS SQL port and sit there, put into a loop when the connection timed out and almost nobody could login to the server.;-)

              https://en.wikipedia.org/wiki/... [wikipedia.org]

            • It seems the real use for SQLite (besides teaching) is for cases where you simply don't have multiple processes accessing the same database, or if they do occasionally, performance isn't a big concern. One big example I can think of is storing configuration variables for applications. That's not something you want to have a full-blown database like PostgreSQL running for, but it can be handy to use SQLite so you have more power than you'd get with flat files.

              • Oh, exactly. I used SQLite for a game database - RPGs have a lot of stats and such, and SQLite was a million times faster than the hand-rolled CSV parser I was using. And I love how focused it is on reliability and correctness and standards compliance. It's just not built for certain things - it will work as a web database, and one of the frameworks I use even ships with it as a testing option, but it's not a good pick for production use.

    • Re:It doesn't matter (Score:5, Informative)

      by SQL Error ( 16383 ) on Friday September 26, 2014 @10:31AM (#48002397)

      Ah, memories. That had us rolling on the floor at my office at the time.

      For those who missed it, or want to relive it: http://www.youtube.com/watch?v... [youtube.com]

      • by ndykman ( 659315 )

        Yea, that was great, but Redis did actually turn into a useful tool compared to Memcached.

    • Obligatory reference [youtube.com]. Makes me laugh every time.

    • /Oblg. Mongo DB Is Web Scale [youtube.com] :-)

  • by Anonymous Coward

    Is it web-scale?

  • by ranton ( 36917 ) on Friday September 26, 2014 @10:29AM (#48002369)

    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.

    • Re: (Score:2, Interesting)

      by Anonymous Coward

      Also, the point of scaling databases horizontally isn't just being able to distribute large amounts of data, but to distribute large amounts of queries.
      I think a lot of people here like to point and laugh at NoSQL and particularly Mongo because they fail to consider the aspect of distributing QUERIES, which is where NoSQL shines compared to *SQL.

      Yes, you can scale sql horizontally, but anyone who doesn't have a deep understanding of the internals of the *SQL engine of choice and has tried to scale them hori

      • Re: (Score:3, Interesting)

        by Anonymous Coward

        So, setup replication, yeah it's little more work to do with Postgres than with Mongo, but it's not hard by any means nowadays and you get more flexibility and performance and queries that can actually do things, seem like good deal to me.

    • And then let it be reviewed.

  • Anybody who's worked on both already knows that NoSQL-based solutions simply don't live up to the hype.
    • by Sarten-X ( 1102295 ) on Friday September 26, 2014 @12:55PM (#48003909) Homepage

      I've worked extensively on both kinds of systems over the past decade. Under a particular workload that is exactly what an RDBMS is designed for, an RDBMS has the best performance? Wow, who would have bet on that one?

      Then again, I've had workloads (my go-to example is writing several billion records in a matter of hours for statistical analysis, with live intermediate results) where a NoSQL solution had the best performance.

      NoSQL isn't some rebellion against traditional databases. Engineering isn't a contest. Rather, NoSQL, column-stores, distributed warehousing, or any other term you'd like to throw out all just point to an additional option for how to manage your data. Pick the right choice for your project, and use it. Don't worry about "web-scale" or "ACID compliance" talking points unless your project needs them. For the past few decades, we've been forced into the assumption that data must perfectly normalized, arranged in tables, and must be queried as relations. For some projects, massaging the data into that form will damage your performance far more than your database engine ever will, so a different engine makes a better choice.

      Stop listening to hype, deserved or not, and use the right tool for the job.

      • by badboy_tw2002 ( 524611 ) on Friday September 26, 2014 @01:42PM (#48004395)

        "Engineering isn't a contest."

        But...but...I have a hammer. I KNOW how to use a hammer. A hammer is the best! FUCK YOU SCREW! TAKE THAT SCREW! Job complete!

      • You forgot a crucial point, this is Slashdot. When you said "Engineering isn't a contest" you violated the Way of Slashdot.

        On Slashdot, it's all about people with deeply held irrational opinions who make unsupportable claims. Additionally, they express themselves in rants and slander, and rational discourse is considered a sign of weakness. If you want to find people who think, you're in the wrong place.

      • Then again, I've had workloads (my go-to example is writing several billion records in a matter of hours for statistical analysis, with live intermediate results) where a NoSQL solution had the best performance.

        Was that even transactional? That almost sounds like a use case for Kx or similar stuff.

        • Was that even transactional?

          Nope.

          The live results were restricted to simple queries (mostly for internal reporting), but the workload to be performed ultimately was more straightforward map-reduce algorithms. Everything (live and final) was statistics, so missing a few records due to lacking ACID wasn't ever a real concern.

          That almost sounds like a use case for Kx or similar stuff.

          It's been a while, but I believe Kx was considered during the initial research phase. Ultimately Hadoop and HBase fit our needs better.

  • by EmperorOfCanada ( 1332175 ) on Friday September 26, 2014 @10:31AM (#48002407)
    I tried MongoDB and I even tried to like it. I do love NoSQL but what I came to realize was that MongoDB was trying to tell me how to solve my problems instead of just storing my damned data.

    But the real problem with MongoDB was that nearly everything, while appearing simple, required a google search to figure out how to do it. A mark of a very well designed API is that you soon start guessing the commands and your guesses are really close or right on. But with MongoDB I found that nothing really made sense. Only after carefully crafted "debate team" arguments could any unusual aspect of MongoDB defend itself. Whereas redis is the opposite, it just works. Or even simpler systems like Memcache, that couldn't be simpler, when read the API for either of those they just made sense. There is no layer upon layer upon layer of complexity. It is data goes in, and data comes out.

    In fact redis would be a good example of ease of use mixed with advanced capabilities. The basic commands are things like get, append, save, while more advanced commands are more esoteric such as PEXPIREAT which has to do with timestamp expiries. So you can happily use redis like a simple minded fool and it is wonderful. Or you can dig in deeper and only mildly shake your head at some of the command names. But with MongoDB it is just a pain in the ass from the first moment you truly have even vaguely complicated data.

    But back to PostgresSQL. The JSON related features are mildly complex but appear to be solving the most common problems. Also by using PostgresSQL it solves the entire debate of relational vs NoSQL. Use PostgresSQL and you can just do both without giving it a second thought. And I for one can certainly say that I have data that demands NoSQL and I have other data that demands relational; all in the same project. But oddly enough the technique that I use is MariaDB for the relational and redis for everything else. This is ideal for me as the relational data is very simple and won't need to scale much whereas the redis stuff needs to run at rocket speeds and will be the first to scale to many machines.

    But as for MongoDB, it has been deleted from all machines, development and deployment and will never be revisited regardless of this weeks propaganda.
  • MEAN (MongoDB, Express, Angular.js, Node.js)

  • The tipping point (Score:4, Informative)

    by tyggna ( 1405643 ) on Friday September 26, 2014 @10:45AM (#48002567)
    I've done research against these database programs, and this is really really old news for anyone who has done testing. If you have a single machine, then Oracle is the best performing database, followed by Postgres. When you need more than 4 dedicated servers hosting a database, then mongo can handle about 180% of the volume that oracle can, and about 220% the volume of postgres, and about 110% the volume of Casandra.
    As soon as you need more than one machine to host your database (which usually happens around 1000 active users on your website at any given time, depending on your application), consider switching off of an SQL database.
    • by Anonymous Coward

      same applies for either disconnected operations (Couch) or multi-data center deployment for HA.

    • Re:The tipping point (Score:4, Informative)

      by CastrTroy ( 595695 ) on Friday September 26, 2014 @11:31AM (#48003101) Homepage
      Unfortunately is often very difficult to switch database engines, especially if you are switching to NoSQL. I've been on one project where we switched from SQL Server to MySQL, and it didn't go too bad, but that's because the majority of the SQL in the project was standard select, insert, updates and deletes. Had there been a lot of stored procedures, or use of other non-standard SQL the project would have probably taken a lot longer to accomplish.
    • My understanding is that it's easy to spread READ ONLY postgres load accross multiple servers. WRITING is a bottleneck with postgresql though because it enforces consistency, while other DBs like couch kick the consistency can down the road to the application. But I haven't seriously looked into it in years.
    • Have you seen Postgres-XC? It's pretty much built for this purpose.

      http://postgresxc.wikia.com/wi... [wikia.com]

    • If you have a single machine, then Oracle is the best performing database, followed by Postgres. When you need more than 4 dedicated servers hosting a database, then mongo can handle about 180% of the volume that oracle can, and about 220% the volume of postgres, and about 110% the volume of Casandra.

      This, this, a million times this. A recent employer needed to be able to sustain 250,000 inserts per second. Not 24/7, mind you, but at random prolonged intervals throughout the day. The "PostgreSQL is the fast" chart shows it handling 10,600 bulk load operations per second or 1,700 individual inserts per second. That would be about 1/150th of the insert load we needed to handle.

      I'm a huge fan of PostgreSQL - when it's appropriate. If you need strong relational and consistency guarantees, there's nothing I'

      • by Anonymous Coward

        The thing is, excluding minor variations in ACID implementations and guarantees, you are limited by your storage hardware regardless of what technology you use. Cassandra was able to outperform PostgreSQL because you compared many servers running Cassandra against one server running PostgreSQL. Cassandra makes data access between many servers easy (once you get used to its specialized API), but you could have done the same on multiple servers with their own PostgreSQL server by sharding your data among th

        • you are limited by your storage hardware regardless of what technology you use.

          Well, right, but I think we set our expectations too low in some cases. For example, the data item {"key": "foo", "value": "bar"} serializes to 30 bytes of JSON. With a few bytes to act as record separators, a hard drive with a 100MB/s write speed should be table of recording about 3,000,000 items per second. There's a lot more overhead than that, of course! But in the document we're discussing, PostgreSQL was averaging about 1,700 inserts per second, or about 170,000 times slower than the hypothetical maxi

  • The best one. Ah. (Score:2, Interesting)

    by Anonymous Coward

    "MongoDB, the leading document database and NoSQL-only solution provider,"

    According to who?
    What happened to all the rest of them, like CouchBase or Riak?

    I will admit bias, though. I like my db's eventually consistent.

  • by aglider ( 2435074 ) on Friday September 26, 2014 @11:01AM (#48002741) Homepage
    Whoever did serious performance tests against PostgreSQL already knew!
    • by rtaylor ( 70602 )

      Actually, they didn't. The benchmarking was done as the JSONB feature in Pg is brand new and they wanted to see how it stood up to the competition (being much much slower is a sign that something could be improved).

      Being faster on a single node was a surprise.

  • ... a pronounceable name for the PostgreSQL software, one that does not require a FAQ entry to instruct in the correct pronunciation.
  • by Anonymous Coward

    Candygram for Mongo!

  • Not surprising... (Score:5, Interesting)

    by rgbatduke ( 1231380 ) <rgb@phy.[ ]e.edu ['duk' in gap]> on Friday September 26, 2014 @12:23PM (#48003619) Homepage

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

  • Where Postrgres and MySQL were used for web applications and they performed very well.
  • Look at the "MongoDB 2.4/PostgreSQL 9.4 Relative Performance Comparison" and see that MongoDB's bars are much higher than PostgreSQL's, with labels like "276%" and "465%". That looks like MongoDB is much better, right? Oh, oops! Apparently that's how much slower MongoDB is.
  • Just in my experience, the introduction of HStore and JSON data types in Postgres has pretty much nullified the advantages I'd get from using a NoSQL DB. Sharding, high availability, etc are all there with a little work (and help from the many 3rd party projects in the Postgres "ecosystem"). Every now and then I find myself tempted to run a project using a NoSQL DB, but the trade offs (lots of memory, lack of ACID compliance, nascent querying languages, etc) bring me back to Postgres.

    Of course there are

Some of my readers ask me what a "Serial Port" is. The answer is: I don't know. Is it some kind of wine you have with breakfast?

Working...