I find that a poor argument. One can use an ORM that automatically creates a schema based on classes. E.g. I like Ebean with DDL generation. You just write classes and add @Entity annotations. Ebean automatically creates the schema. Combine this with an embedded database, such as h2, and there is virtually nothing to set up.
Once you are out of the rapid iteration phase, you can take the latest Ebean generated schema and use to proper migrations for later changes.
So you don't have to create bullshit m2m tables with tedious joins for a fucking tagging system
I read somewhere that nesting in hstore is coming in the next version (Q3 2014?) and non-string types are on deck.
Compared to the nightmarish development workflows and processes I've had to deal with resulting from using CouchDB as a main datastore, having to get the entire JSON value in order to update one key seems like not that big of a deal. What NoSQL databases even let you do incremental operations in that sense?
Shitty index? It seems like you should be able to make an index on a value inside the JSON just as easily as any other index.
Then maybe some advanced features of Postgres can really shine: http://www.postgresql.org/docs/8.3/static/indexes-bitmap-sca... https://wiki.postgresql.org/wiki/Index-only_scans
I'm also exploring a solution for abstracting that as a normal, non-JSON table for semi-structured data using views.
Basically, it seems like for semi-structured data where you know what the schema is, but maybe it just changes over time or isn't 100% certain, so it's not possible to store it using a typical schema, JSON + indexes + views offers the best of both worlds.
[1] http://clarkdave.net/2013/06/what-can-you-do-with-postgresql...
But one can argue that not careful with schema design can break api and make codebase messy.
I guess I will stick with the hard work now... I guess not careful with schema will definitely bite me.