[killedbydeath]

Not sure what you mean by lack of developer friendliness and what specific tools you find it lacking. Postgres is a great choice for new startups that need an RDBMS and like having schema for their data. There is built-in JSON support in upcoming 9.2 release and most JSON-to-schema mapping should be done in application anyway. Sharding is easy to do at application level; you would lose ability to do certain queries across shards but most solutions offering automatic sharding are designed specifically not to allow most types inter-shard querying and instead offer map-reduce.

[taligent]

Sorry but PostgreSQL's JSON support is a joke. It is nothing more than a VARCHAR that validates. You can't search or index across fields and the way you actually query the JSON is cumbersome at best.

Also all of your arguments are "push to the application layer". Well my point is that with most of the newer databases you don't have to reimplement the wheel.

[killedbydeath]

If you need to store arbitrary JSON fields in the database and index them, then you indeed are better of with some NoSQL database. But I strongly disagree with the statement that all new startups deal with that kind of data organization. Many problems have good structure and can benefit from imposing structure (schema) upfront. In which case any JSON you get will parse in the application, map it to your data organization and store in a clean strict relational format, with all indexable fields extracted to separate columns. I do not store my logs in Postgres, but I do store my billing transactions in Postgres. There are many different types of data with different tradeoffs involved. For most, Postgres is a great choice.