>Now I don't know why anyone would not choose PostgreSQL for almost any project.
No offense but people who make statements like this clearly don't know much about the current state of databases. PostgreSQL is pretty bad in many areas compared to the newer databases e.g. ease of clustering and sharding, developer friendliness, JSON support, tool support etc.
It's great as a replacement for a typical RDBMS but if you're working on a new startup project I would see no reason to use it.
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.
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.
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.
Well some are better than others right. Riak/CouchDB are great when it comes to clustering/sharding. MongoDB has the best JSON support and is very friendly for developers. MySQL is proven, has the best tool support and most widely supported.
The fact is that just like one programming language doesn't satisfy all use cases. Neither does one database. So maybe PostgreSQL 'supporters' should stop trying to claim it is perfect for everyone.
No offense but people who make statements like this clearly don't know much about the current state of databases. PostgreSQL is pretty bad in many areas compared to the newer databases e.g. ease of clustering and sharding, developer friendliness, JSON support, tool support etc.
It's great as a replacement for a typical RDBMS but if you're working on a new startup project I would see no reason to use it.