PostgreSQL Outperforms MongoDB In New Round of Tests

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.

Comments

"Small" amount of data

[ranton]

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:"Small" amount of data

[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 horizontally can testify to what a nightmare it is. At least that is my experience.

Re:"Small" amount of data

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

I dipped my toe in MongoDB

[EmperorOfCanada]

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.

The best one. Ah.

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

Not surprising...

[rgbatduke]

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