Where we use MongoDB, it's not because of speed. PostgreSQL is certainly capable of fast performance. MongoDB is useful for its ability to log freeform data as well as for its replication model. (We use sharded MongoDB in a few places, but mostly use straight replica sets.)
We use MySQL, MongoDB, PostgreSQL, and Impala. They're all useful in different places.
These are the same guys who built hstore, full text search, GIN and GIST indexes and I think are working on a generic regular expression index type right now.
Thanks for the clarification, but this makes it even more obvious your engineering team is introducing needless complexity into your organization.
Postgres can store unstructured data just fine, so you have a 'solution' that uses 3 OLTP stores instead of one.
Making developers productive is an important aspect for choosing a database.
More important questions are how is the data stored, how is it accessible, how can you scale the system, what operational constraints are there, how fast is it, what types of data modeling can be done, what consistency/transaction guarantees does it provide, etc. These are the things that will make developers productive because they will not be putting out fires all the time.
How are you liking Impala? We just dropped 0.5 release yesterday which includes the JDBC driver :D!
Edit: Awesome job on the Ruby client, it's great!
I've been meaning to write a MoSQL equivalent for our Impala data, but at the moment we're doing a more traditional ETL.
I've passed your comment on to Colin, who wrote the Ruby client -- I'm sure he'll appreciate it!
Thanks for the kind words!