...for reads. Once you get any real traffic it hangs on its DB write lock. Yes, I have experienced this, and the solution "just shard!" is especially obnoxious because setting up sharding is a lot harder than they make it seem. Not only is it complicated, you go from one server to three config servers, two repsets with 3 servers each (so 9 fucking servers) just so you can make more than 40 writes/s that most relational DBs wouldn't bat an eyelash at.

It's a poorly designed system, and this becomes painfully apparent once your app moves out of the basement and into the real world. Luckily for MongoDB, most of their users' apps never leave the basement and they think "wow, this is great!!"

> argualy scalable performance

Not scalable. At all. Global locks do not scale. Complicated config setups are hard to scale.

Check out RethinkDB. It's an open-source document DB that fixes just about all the problems MongoDB has and it has DB-side joins. It's just as easy to get quick and dirty apps running against, and it doesn't actively flush your data down the toilet like Mongo has been known to do.

Depending on your database adapter, this is not the case. With Postgres, you have the Simple Query Protocol and the Extended Query Protocol (http://www.postgresql.org/docs/9.3/static/protocol-flow.html). A Simple Query involves text in and out. However with an Extended Query, properly parsed statements are always executed by the DB, and will always return properly typecasted data. You can also stream data to the client and use Cursors, if you have very large datasets (a life saver when reporting on large tables). Also, you don’t need to worry about SQL injection when using Extended Queries, as they are handled as prepared statements.

JDBC supports the Extended Query Protocol with Postgres, so if you are using Java, Scala, JRuby, or anything running on the JVM, you are good to go. But, I have not had to deal with raw text being returned from my Postgres queries in a long time ;)