So I'm using both types in a current personal project and I have to agree with the comment on the blog post<p>"[...] I use JSON for external application data that doesn’t need to be interpreted by say, an SQL function or a trigger. Basically storage-only data..."<p>Basically I use hstore's as meta columns, for say a one off attribute of a model that I dont want to have as another column and have to do a migration. It is leaps and bounds better than using a text column because you can query.<p>JSON I use for basically caching api calls. For instance I save off the json from the itunes api for all of the albums of an artist or all of their songs.<p>It will be awesome when 9.3 comes out and you can query that though. That will be something.
I also think of this in terms of viable development migration paths:<p>For example, 9.3's upcoming: hstore_to_json(hstore) and hstore_to_json_loose(hstore) open up possibilities. If an hstore datatype is chosen now, you can feel fairly confident that it can be fairly straightforwardly migrated to a native json datatype in 9.3 or later versions, when you feel the json featureset and stability may have become mature enough for your particular project's needs.
Here's the original post which fired off some further clarifications from Christophe:<p><a href="http://www.craigkerstiens.com/2013/07/03/hstore-vs-json/" rel="nofollow">http://www.craigkerstiens.com/2013/07/03/hstore-vs-json/</a>
I'm really failing to understand obsession with unstructured types in Postgres? Why can't you just use native types for hierarchical structures?<p>Is it really that hard for people to maintain database changes?
a bit more hands-on, but it's possible to create a functional index to improve json query performance in postgres:<p><a href="https://postgres.heroku.com/blog/past/2013/6/5/javascript_in_your_postgres/" rel="nofollow">https://postgres.heroku.com/blog/past/2013/6/5/javascript_in...</a>