Err because things like this didn't even exist until 10 minutes ago and aren't production-ready. I don't really understand people who keep saying this. Postgresql supports JSON, but it doesn't have all of the code to go on top of it so that you can use it like mongo. As in, so you can do projects.find or projects.insert instead of a bunch of sql.
Then there are all kinds of other issues related indexes and the differences between mongo and PostgreSQL and so on.
There's an unwritten rule here on Hacker News that says that you are supposed to bash any piece of technology that received praise when it was originally introduced on HN, but is now 3 years old or older. The moment in time when something transitions from new and shiny to old and unfashionable is generally characterized by a comment of the lines of "Why would anyone use x when you can use y?".
Conversely, the more recent a piece of tech is, the more likely it is go into production right away, with people only starting to question their decision after the 3 year new-and-shiny barrier is broken (but usually not because of its faults, but because something newer and shinier can now replace it).
well, in mongo's case, there has been some rather strong criticism leveled at it over time.[1][2][3] some aspects have probably improved, but (as i don't follow mongo) i can't say how proactive and public mongo's owner has been in addressing criticisms.
That would be good advise, except for the fact that a. I couldn't give a crap if MongoDB started here on HN or not, and b. MongoDB is outperformed by ToroDB, and on the upside you can use regular SQL to do analytics if you use ToroDB. Also, MongoDB has a raft of issues that still haven't been addressed.
Edit: incidentally, don't you think it's ironic that the "new and shiny" thing that was supposed to knock relational databases (now over 36 years old) off it's perch has been found to be lacking in a variety of areas, not least of which is that a "schemaless" document store almost always gains a defacto schema?
Seems to me that the ability to join and divide two relations is a fantastic application of relational algebra and not something you can do particularly well in MongoDB at all.
There are different types of indexes that mongo supports within a document that are more complex than what PostgreSQL can do. Or at least that is what I remember last time I checked.
I mean that this persons code is not production-ready. As in there is no chance it emulates all of the features of mongo or has been performance tested etc.
So, I haven't used Mongo, but here's a list of things I found to be bad about jsonb (use case was a project where we need to be able to quickly aggregate over large numbers of items with small-cardinality metadata):
1. Can't sort using a GIN index.
2. Stats are shit with GIN indices - Postgres assumes that every filter has 100 matches, every array has 99 elements or something. Usually this works well, sometimes (specifically in my case) it's terrible. Specifically, it means that if you combine an aggregation over a GIN filter with an inner join, the performance will be awful because postgres picked a nested loop join for expected 100 results instead of a hash join for the actual 50,000.
3. This also means that additional expression indices you add basically aren't getting used, because it'll always appear better to the query planner to use the GIN index first. This includes things like sorting.
4. Because of how jsonb is implemented (basically arrays containing fields ordered by key alphabetical), we discovered that we were taking out more and more fields out of our jsonb field and placing them in other columns, which kinda missed the point of it (but was very good that we could do so, yay relational data model).
5. Sorting can become an epic chore if you don't have stuff like enum types etc, especially when you try to combine it with tsvectors.
So, very happy with Postgres, but don't slam people who don't use Postgres because of insufficient json support - because Postgres' json support although excellent has quirks that will bite you with certain use cases. Very good, but not a panacea.
1. Yeah, the reason for that is that by default a GIN index doesn't support greater than or less than operators. However, you can introduce btree like functionality by using btree_gin and I believe it should start working.
2. That's (probably) occurring because the default statistics target is 100. Just increase them with:
ALTER TABLE gin_index ALTER COLUMN indexed_column SET STATISTICS 1000;
That should hopefully help with all the other issues you are seeing.
P.S. while looking at MongoDB a little further, I discovered that it doesn't support sorting by collation. This was logged as a JIRA bug in 2014, and as of yet I don't believe there is a solution.
Except that ToroDB, as an example, is a drop-in replacement for MongoDB and communicates using the MongoDB wire protocol. So basically, you can use ToroDB to use the MonogoDB API as you would normally.
As an example? It is like the only thing that does it and it is so new that nobody has used it anywhere. It also looks like it just tries to map a document database back into a relational database implementation.
Then there are all kinds of other issues related indexes and the differences between mongo and PostgreSQL and so on.