PostgreSQL goes after MongoDB; benchmarks show PostgreSQL in the lead

in science on 2014-09-25 21:11 (#2SXX)

PostgreSQL, the much-loved opensource relational database, is ramping up its nosql game with a new developer kit that gives access to NoSQL features that beat MongoDB in benchmarks.

The PostgreSQL Project, which EnterpriseDB supports, added NoSQL-style JSON processing features back in 2012. Now, the company is encouraging further work around that feature set by providing a developer kit to make it easier for programmers to leverage PostgreSQL's JSON functions and build applications around them. ... The PGXDK (Postgres Extended Datatype Developer Kit) is designed to allow developers "to use Postgres for the kinds of applications that until recently required a specialized NoSQL-only solution," as EnterpriseDB describes it. A sample application is also included to make it easier for developers to get a leg up on working with the product. The whole package will be made available through AWS as a machine image (PostgreSQL has long been a staple Amazon offering).

Vibhar Kumar has published a set of benchmarks here that show PostgreSQL eating MongoDB's lunch when measured in use of diskspace, bulk loading, and INSERTs.

Quick, Dirty (Score: 0)

by Anonymous Coward on 2014-09-25 22:03 (#2SY1)

Very quick and dirty test. He says right off the bat he's comparing default out of the box performance. There are so many possible tunings and usage scenarios that the only fair way to test is after tuning by experts in each product. While interesting, this test seems to mean nothing?

Re: Quick, Dirty (Score: 2, Interesting)

by evilviper@pipedot.org on 2014-09-25 22:31 (#2SY4)

Performance out-of-the-box shouldn't be underestimated. Not every database is a huge and mission-critical task deserving hours of your DBA's time to tune. In fact the overwhelming majority of database uses are quite the opposite, just some mundane back-end tasks for storing and collecting data.

If tuned performance was important to people, MySQL would never have caught-on as the M in LAMP... Instead, MySQL got popular because any idiot could install it and it would seem to work at decent speeds right away. You only got a rude awakening much later...

Re: Quick, Dirty (Score: 1, Interesting)

by Anonymous Coward on 2014-09-26 00:59 (#2SYB)

Well yeah, except their primary use case (literally, it's the first use case listed) is BIG DATA. It's fair to say that if you're routinely pushing and parsing terabytes of structured data, you probably can and should take a day or two to get the database optimized, no?

That's why an OOB test doesn't really seem to apply here. Mongo is supposed to be enterprise stuff. Anyhow, glad to see PostgreSQL is still in the game, and agreed it's too bad MySQL is still unavoidable.

Re: Quick, Dirty (Score: 2, Informative)

by evilviper@pipedot.org on 2014-09-26 01:24 (#2SYC)

Well yeah, except their primary use case (literally, it's the first use case listed) is BIG DATA. It's fair to say that if you're routinely pushing and parsing terabytes of structured data, you probably can and should take a day or two to get the database optimized, no?

No. You're simply stuck in a mindset of high-value databases. Try low-value data, on a large scale, instead... Turn up your syslog logging to the maximum amount of debug, then expand that out to hundreds and hundreds of heavily loaded servers, then log it all to a central system, desperately trying to write that to a database for eventual aggregation and reporting... Consider something like an IDS or other monitoring on high-speed data networks, trying to keep track of data usage, in detail, on those gigabit speed lines all-around the clock.

Or just consider the cost of an extra server (with SSDs) versus the cost of hours of a DBA's time... For non-critical data in general, you're going to expand the cluster, rather than spend time and effort to tune things.