Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PostgreSQL Outperforms MongoDB in New Round of Tests

blogs.enterprisedb.com

Post reply on HN
Print view View original

91–100 of 171 posts

Re: PostgreSQL Outperforms MongoDB in New Round of Tests

#91

Post by poolpool »

mikegioia wrote: post #88
collyw wrote: post #82

Earlier quoted context omitted.

Sure, but how many people genuinely have data that big?

Well one thing we store is HTML content and "MS Word" like document data. We also store hundreds of revisions for all of those documents. I wouldn't want to use an RDMBS for this because (a) its not relational, but also (b) backup/replication/load distribution would be too painful. A system like CouchDB can be spread out over n-machines, any of them write-capable.

This is exactly what SharePoint does on top of boring, battle tested SQL Server.

Re: PostgreSQL Outperforms MongoDB in New Round of Tests

#92

Post by jpgvm »

Nitramp wrote: post #79
tete wrote: post #65

Did I miss something? MongoDB was never ever faster than Postgres. That's nothing new. Most of these things are clear when one reads the MongoDB docs: MongoDB stores Metadata, (nearly) uncompressed on a per document basis, so of course it uses way more diskspace. It doesn't store the data in any efficient way either. Also it's pretty much unoptimized, compared to Postgres which has been around for a really long time…

Is MongoDB's distribution and scaling story really nicer? A cluster story that's easy to set up but then doesn't actually work (loses data, fails in potentially catastrophic ways) sounds not all that useful. http://aphyr.com/posts/284-call-me-maybe-mongodb

MongoDB clustering is nothing short of disastrous.

If anything I hope databases like RethinkDB and even multi-master PostgreSQL if we ever see it learn from the most crucial mistake here - rolling your own consensus. (This goes for databases other than MongoDB, I don't meant to single it out here)

Stick to proven algoritms, ZAB, Paxos, Raft.

Re: PostgreSQL Outperforms MongoDB in New Round of Tests

#93

Post by craigching »

tete wrote: post #65

Did I miss something? MongoDB was never ever faster than Postgres. That's nothing new. Most of these things are clear when one reads the MongoDB docs: MongoDB stores Metadata, (nearly) uncompressed on a per document basis, so of course it uses way more diskspace. It doesn't store the data in any efficient way either. Also it's pretty much unoptimized, compared to Postgres which has been around for a really long time…

> it's a charm to scale (in many different kinds), compared to PostgreSQL. If PostgreSQL had something built in(!) ...

This! A million times! I agree 100% that Postgresql is better than MongoDB in every way except in ease of replication (that's really my only need) for HA. We needed an embedded database in our product and I wanted so bad to use Postgres, but we needed HA and we needed our customers to be able to set it up. This was so important to us that we took the otherwise inferior solution.

Now, that said, I bring up the replication/HA issue every time one of these "postgres is better than mongodb" articles comes up. The last time I posted a Postgres developer responded to me that they're laying the groundwork for a good answer and that it's coming. I can not WAIT for that day!

Re: PostgreSQL Outperforms MongoDB in New Round of Tests

#94

Post by craigching »

Nitramp wrote: post #79
tete wrote: post #65

Did I miss something? MongoDB was never ever faster than Postgres. That's nothing new. Most of these things are clear when one reads the MongoDB docs: MongoDB stores Metadata, (nearly) uncompressed on a per document basis, so of course it uses way more diskspace. It doesn't store the data in any efficient way either. Also it's pretty much unoptimized, compared to Postgres which has been around for a really long time…

Is MongoDB's distribution and scaling story really nicer? A cluster story that's easy to set up but then doesn't actually work (loses data, fails in potentially catastrophic ways) sounds not all that useful. http://aphyr.com/posts/284-call-me-maybe-mongodb

It depends on your workload, but MongoDB has worked extremely well for us, we've never lost data. I love aphyr's posts on databases, but you can't use them as a blanket for everything.

Re: PostgreSQL Outperforms MongoDB in New Round of Tests

#95

Post by craigching »

hnhipster wrote: post #42

This is very interesting. Around when MongoDB was quickly becoming the cool thing to do I'd ask people about why it is better than just storing things in Postgres. People would have answers that would be grammatically correct but would not make any sense. That being said, I find it weird that now it is cool to make fun of MongoDB. Some people on this thread have even said they want to know if a service is using Mongo…

> People would have answers that would be grammatically correct but would not make any sense.

You mean like this?

http://www.mongodb-is-web-scale.com

;p

Re: PostgreSQL Outperforms MongoDB in New Round of Tests

#96

Post by yangyang »

mikegioia wrote: post #89
vertex-four wrote: post #80

Earlier quoted context omitted.

At the end of 2013, Stack Overflow worked on one SQL server (plus a redis server for caching). The rest of Stack Exchange runs on another SQL server.[0] For the most part, for most projects, worrying about multi-master replication is going to be pointless. You can always put some data in a distributed K/V (or document) store and point to that from your SQL if you need to. [0] http://nickcraver.com/blog/2013/11/22/wha…

What I meant was a data-size that was too large for a machine. Adding arbitrarily large JSON to your table could expand the data-size to be too big for one machine, or even too big for block storage. Plus you might not want it all in block storage. My point is that an RDBMS can be better served storing the relational data alone with a separate DB Engine for the potentially massive JSON data.

Why does the format the data is stored in matter more than the data itself? JSON or columns in rows - it's not fundamentally different.

Re: PostgreSQL Outperforms MongoDB in New Round of Tests

#97

Post by personZ »

tete wrote: post #65

Did I miss something? MongoDB was never ever faster than Postgres. That's nothing new. Most of these things are clear when one reads the MongoDB docs: MongoDB stores Metadata, (nearly) uncompressed on a per document basis, so of course it uses way more diskspace. It doesn't store the data in any efficient way either. Also it's pretty much unoptimized, compared to Postgres which has been around for a really long time…

The entire narrative behind MongoDB in the first chapters of its evangelism was performance, partly due to its document-oriented approach (things are quicker in some scenarios when you get rid of relations, and it was contrast against the many tables approach), which is something that you can only very recently do in pgsql, and partly due to implementation choices like the dangerous default lack of fsync.

Early evangelism for Mongodb was overwhelmingly one that hyped performance over all others. It was, somewhat infamously now, webscale.

So now pgsql (since 9.2, but vastly improved in 9.3) can also do the things that MongoDB does, better, if you want to do the document approach (which is a serious debate unto itself). That is news and is interesting.

As for scaling out, I would argue that 9.3 offers more realistic, robust options than MongoDB does.

Re: PostgreSQL Outperforms MongoDB in New Round of Tests

#98

Post by mikegioia »

yangyang wrote: post #96
mikegioia wrote: post #89

Earlier quoted context omitted.

What I meant was a data-size that was too large for a machine. Adding arbitrarily large JSON to your table could expand the data-size to be too big for one machine, or even too big for block storage. Plus you might not want it all in block storage. My point is that an RDBMS can be better served storing the relational data alone with a separate DB Engine for the potentially massive JSON data.

Why does the format the data is stored in matter more than the data itself? JSON or columns in rows - it's not fundamentally different.

It has nothing to do with the format. I'm using JSON as an example of something that could be large. I'm only talking about separating the "could become massive" columns/data/whatever from the "small, relational data".

Re: PostgreSQL Outperforms MongoDB in New Round of Tests

#99

Post by bostik »

davidw wrote: post #21
Argorak wrote: post #16

Earlier quoted context omitted.

Hate to say so, but many are switching to MongoDB because it's the current new kid on the block. I found that many companies have incredibly bad, not use-case driven reasons to pick their DB. Not that MongoDB is a bad database, but it has it's fair share of issues. Granted, this is the case for every database, but if you pick any database without being aware of those, you end up in a world of pain. (Context: I consul…

That was my only experience with MongoDB - "let's try this, for this experimental project, to see what it's like", without taking into account its characteristics. After that the project grew, I was brought in and needed to do some reports, which were a huge pain in the ass without proper SQL and joins. I don't intend to have anything to do with people using MongoDB unless they have a really, really good reason for d…

A friend of mine came up with the perfect use-case for MongoDB.

His company installs and monitors sensors in civic infrastructure: roads, train tracks, bridges, ... These sensors provide constant data streams which need to be stored somewhere before processing. Any raw data older than 2 weeks is worthless, and if 2-3% of data is lost before written it's not much of a problem. More data is coming in all the time any way.

For them MongoDB is the perfect transient cache. Sensor data is processed and the results stored elsewhere. Easy to expand. Flipping between installations is just a matter of toggling load balancer, an once an offline cache has been processed, it can be nuked and put back as a fresh system.

So, for a setup where easy size expansion, fast mostly-reliable writes and ease of use are the primary design constraints, mongo fits in suprisingly well. It's a fascinating use-case.

Re: PostgreSQL Outperforms MongoDB in New Round of Tests

#100

Post by Argorak »

bostik wrote: post #99
davidw wrote: post #21

Earlier quoted context omitted.

That was my only experience with MongoDB - "let's try this, for this experimental project, to see what it's like", without taking into account its characteristics. After that the project grew, I was brought in and needed to do some reports, which were a huge pain in the ass without proper SQL and joins. I don't intend to have anything to do with people using MongoDB unless they have a really, really good reason for d…

A friend of mine came up with the perfect use-case for MongoDB. His company installs and monitors sensors in civic infrastructure: roads, train tracks, bridges, ... These sensors provide constant data streams which need to be stored somewhere before processing. Any raw data older than 2 weeks is worthless, and if 2-3% of data is lost before written it's not much of a problem. More data is coming in all the time any w…

From what that sounds like, I agree. This is a complex problem description with a pointer where the database provides solutions.
Post reply on HN