This is wonderful work, and it is the foundation for yet more wonderful work in the future. However, as much as i am a huge PostgreSQL fanboy and a dedicated MongoDB peanut-thrower, i worry that the caption applied to this post is misleading.<p>Once this work is released, PostgreSQL will be faster than current versions of MongoDB at carrying out queries for documents which look for a given value at a given path (or perhaps more generally, values satisfying a given predicate at paths satisfying a given predicate).<p>But that has never been one of MongoDB's important strengths, has it? The operations for which MongoDB is optimised are inserting documents, retrieving document by ID, and conducting map-reduces across the whole database. Yes, it has the ability to query by values in leaves, and it can use indices to make that faster, but that's a bit of a second-tier, bag-on-the-side feature, isn't it? If that was the main thing you needed to do, you wouldn't have chosen MongoDB, right?
This is impressive but not really surprising given the quality of PostgreSQL database. Quote:<p>"We added performance comparison with MongoDB. MongoDB is very slow on loading data (slide 59) - 8 minutes vs 76s,
seqscan speed is the same - about 1s, index scan is very fast - 1ms vs 17 ms with GIN fast-scan patch. But we managed to create new opclass (slides 61-62) for hstore using hashing of full-paths concatenated with values and got 0.6ms, which is faster than mongodb !"
Great work and research; horrible submission headline.<p>The news here is that, in addition to the huge market for traditional DBs, postgres is going to compete in a serious way on MongoDB's home turf. As that becomes more apparent, it will validate postgres's flexability/adaptability and cast doubt over special-purpose database systems and NoSQL.<p>MongoDB still has a story around clustering, of course. But that story is somewhat mixed (as all DB clustering stories are); and postgres is not standing still on that front, either.<p>(Disclaimer: I'm a member of the postgres community.)
See also the PostgreSQL as a Schemaless Database slides (includes several benchmarks vs MongoDB): <a href="http://thebuild.com/presentations/pg-as-nosql-pgday-fosdem-2013.pdf" rel="nofollow">http://thebuild.com/presentations/pg-as-nosql-pgday-fosdem-2...</a>
Can I index fields within a JSON document in PostreSQL? Can I query them?<p>I.e. can I do something like SELECT json_field FROM data WHERE json_field.age > 15 ?
Which is not surprising, as this is 'real' database. I read review of MongoDB internals and it sounded not very positive. While you can create NoSQL quickly, to do it well with any db, it takes time which PostgreSQL definitely has.<p>Just to be clear, MongoDB is fine db for certain scenarios and I am using it in production.
If you want to find more of the detail and background around this which came from a talk by the author of the blog post then you check out his slides at <a href="http://www.sai.msu.su/~megera/postgres/talks/hstore-dublin-2013.pdf?utm_source=postgresweekly&utm_medium=email" rel="nofollow">http://www.sai.msu.su/~megera/postgres/talks/hstore-dublin-2...</a>. One of the key things not in the blog post but addressed in the slides is that there will be a new index type that really pushes the performance gains even further.
Implementing our doc store on Postgres a while ago in lieu of switching to MongoDB suddenly seems like a very good call.<p>We had nothing against Mongo (frankly haven't gone into deep analysis of how it would turn out). It was simply the db we already had at hand and we knew it well and trusted it.
context: <a href="http://www.postgresql.org/docs/9.1/static/textsearch-indexes.html" rel="nofollow">http://www.postgresql.org/docs/9.1/static/textsearch-indexes...</a> (GIN and GiST are index types)
It would be great if they could run these benchmarks with mongodb using TokuMX.<p>I think tokutek's fractal trees would make an exciting data store for postgresql, but benchmarks are difficult to find... Who is perceived to be faster these days generally? Mysql+innodb, mysql+tokudb or postgresql?