Live data from Hacker News

“MongoDB is dead. Long live Postgresql”

github.com

71–80 of 160 posts

Re: “MongoDB is dead. Long live Postgresql”

#71
post #65

I'm no MongoDB expert, but recently started to look into this db. Can anyone tell me (from experience, not from promo materials) - for which use cases MongoDB is good fit and for which ones it's not? It's clear that it can't fit for everyone. That's why it would be good to know in advance, for what it most likely to find and for what it's most likely not to fit.

http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

Re: “MongoDB is dead. Long live Postgresql”

#72

Seriously, another case of using Mongo incorrectly? I want to believe all the Mongo hate, but I can't because I always find out that the actual problem was one or more of: * didn't read the manual * poor schema * didn't maintain the database (compactions, etc.) In this case, they hit several: " Its volume on disk is growing 3-4 times faster than the real volume of data it store;" They should be doing compactions and…

MongoDB therefore, is not a general purpose database. I recommend http://www.amisalabs.com

Re: “MongoDB is dead. Long live Postgresql”

#73
post #39

Earlier quoted context omitted.

Mongo's disk format is extremely wasteful, the database files are gigantic. That is a real problem and there is no way to compact this to anywhere near the size something like Postgres would have for the same data. Mongo is very bad at managing used memory. In fact it doesn't actually manage memory since it just mmaps its database file. It also touches disk much more often than would be reasonable, especially for how…

And let's not forget the fact that it has a per database lock, which is a really strange choice for a document database.

The guys at MongoDB are working on moving this to a more fine-grained lock in the future. In practice, it's not usually a problem but it'll be less so going forward.

Re: “MongoDB is dead. Long live Postgresql”

#74

Seriously, another case of using Mongo incorrectly? I want to believe all the Mongo hate, but I can't because I always find out that the actual problem was one or more of: * didn't read the manual * poor schema * didn't maintain the database (compactions, etc.) In this case, they hit several: " Its volume on disk is growing 3-4 times faster than the real volume of data it store;" They should be doing compactions and…

What about locking? I heard that Mongo has a locking with only DB-granularity.

The guys at MongoDB are working on moving this to a more fine-grained lock in the future. In practice, it's not usually a problem but it'll be less so going forward.

Re: “MongoDB is dead. Long live Postgresql”

#75
post #2

I'm nearly sure one day someone will write a MongoDB compatibility layer on top of PostgreSQL

I hope so. I've become so used to Mongoid's API and I've never really liked the "invisible" properties of Active Record.

Yeah, it would be cool if AR came with a `field` method that could be made non-optional through configuration, and enforce that only those fields are accessible.

Re: “MongoDB is dead. Long live Postgresql”

#76

Maybe I am just incredibly lucky, but mongodb has worked fine for ridewithgps.com - we are sitting at 670gb of data in mongo (actual DB size, indexes included) and haven't had a problem. Replica sets have been fantastic, I wish there was another DB out there that did auto-failover as cleanly/easily as mongo does. We've had a few server crashes of our primary, and aside from 1-2 seconds or so of errors as requests com…

> using mongo as a very simple key/value store for data that isn't updated frequently, which could easily be replaced by flat file storage, is painless. YMMV with other use cases.

This is our use case as well and MongoDB has been fine. We had some initial pain as we learned the product but it's great for this use case. Currently sitting around 1TB of data.

Re: “MongoDB is dead. Long live Postgresql”

#77
post #46

The title is a bit misleading. This is basically an announcement of a fork of Errbit that has Postgres support. Additionally, the fork was announced as an issue on errbit with no discussion or as an official pull request. I would not consider this good etiquette. If you fork your project (especially without discussing the intention first), adding a bug to the original project isn't a very nice thing to do. An officia…

Open source should encourage forking and easing the transmission of community from one fork to another.

Re: “MongoDB is dead. Long live Postgresql”

#78
post #12

Earlier quoted context omitted.

> That's sensible when you consider that postgresql used to be a SQL layer over postgres. Were they ever actually separate layers? I thought that PostgreSQL was a rename of Postgres that happened shortly (one-two versions) after they swapped query languages from the Ingres-derived QUEL to SQL.

Postgres95 had both if I remember. Sorry was nearly 20 years ago now - bit rusty :)

Or was it PostgresME?

Re: “MongoDB is dead. Long live Postgresql”

#79

Lets just say that PostgreSQL answers the criticisms of relational databases that led to NoSQL. The complaints all boiled down to saying that the RDBMS forced you to do things one way and that it was cumbersome. PostgreSQL evolved and fixed the most annoying issues like JSON support and schemaless key-value store support. That's the way open source is supposed to work. Now folks are learning that throwing out the bab…

This story has played out before. Last time, it was Object Oriented databases. What happens each time is that the traditional RDBMS's pick up a few of the features, and then we keep using them until the next contender comes along.
Post reply on HN