why did you guys invent mosql [1] ? you are clearly loving postgres and cannot get rid of it... but potentially with jsonb in 9.5 [2] you can get rid of mongodb.
With the kind of resources you have, you could fix the few things about postgres that you dont like.
Or use ToroDB (http://www.torodb.com) that speaks the MongoDB protocol but stores the data relationally, in PostgreSQL. Directly. No ETL, no mosql required :)
I just checked out the page. This seems like an interesting project, but how would rewriting unstructured documents into relational form be faster to query than just retrieving the whole document as jsonb or whatever?
Pulling a document together back from its parts cannot be faster than jsonb or whatever. But it can be orders of magnitude faster if you are pulling a collection out of a query and you avoid scanning the whole thing. Let me elaborate.
When you search in MongoDB (or PostgreSQL with a single table with a jsonb column) the executor needs to visit every single document, every single key, to try to see whether that documents matches the query criteria. This means that in the absence of indexes (or inability to use them, as it happens in MongoDB, where they are not used under many circumstances) the whole db would be scan to answer every single query.
I contrast, ToroDB effectively is "partitioning" the data "by type" (being the type the shape of the documents). See this explanation for more detail: https://github.com/torodb/torodb/wiki/How-ToroDB-stores-json.... To answer a given query, ToroDB only reads those tables with potential documents involved in the result, which usually is a small % of the while database. And this, of course, leads to significantly less I/O and queries that can run up to orders of magnitude faster.
There are many reasons. The first is that Java is in our opinion the language with the biggest and greatest ecosystem of open source libraries on top of which we can build our software. And this is saving many man-years for us.
I contrast, PostgreSQL extensions need C, which doesn't have these advantages and becomes less productive.
But even more importantly: we don't want to tie it, as much as possible, to PostgreSQL. Maybe, tomorrow, ToroDB would run on other RDBMs :)
If run locally, there's barely performance hit. And it also enables you to run it remotely.
With the kind of resources you have, you could fix the few things about postgres that you dont like.
[1] https://github.com/stripe/mosql/blob/master/README.md
[2] https://wiki.postgresql.org/wiki/What's_new_in_PostgreSQL_9....