

JSON vs hstore - ishbits
http://thebuild.com/blog/2013/07/03/json-vs-hstore-which-will-get-you-into-a-cool-bar-in-the-mission/

======
wh-uws
So I'm using both types in a current personal project and I have to agree with
the comment on the blog post

"[...] 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..."

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.

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.

It will be awesome when 9.3 comes out and you can query that though. That will
be something.

------
NatW
I also think of this in terms of viable development migration paths:

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.

------
moomin
Now all we need is EDN support in Postgres.

------
craigkerstiens
Here's the original post which fired off some further clarifications from
Christophe:

[http://www.craigkerstiens.com/2013/07/03/hstore-vs-
json/](http://www.craigkerstiens.com/2013/07/03/hstore-vs-json/)

------
zapov
I'm really failing to understand obsession with unstructured types in
Postgres? Why can't you just use native types for hierarchical structures?

Is it really that hard for people to maintain database changes?

~~~
ketralnis
I'm really failing to understand obsession with deriding people for solving
problems that you personally don't have.

But yes, for some people it can be difficult to do this. It slows development,
it makes programmers have to do sysadmin work (which in a two-person company
without a specialised sysadmin can be difficult).

As another use-case, there was a point at which Twitter would take days or
weeks to implement even minor schema changes across their entire MySQL cluster
without impacting production.

And some people are solving problems that just do have unstructured or semi-
structured data, rather than your assumption here that it's just a proxy for
avoiding schema changes

~~~
jakejake
Avoiding DB work strikes me as not the greatest reason to store JSON in your
DB. But I find there are good reasons to do it. The main one for me is when
the data fields are configurable by the user.

If I didn't want to be constrained by a schemas I'd just go with a NoSQL
solution. Nothing wrong with that either.

~~~
tensor
Postgres can make a pretty nice "nosql" solution too. Either via hstore, json,
or bytea. That said, nothing frees you from a schema. Not having it explicit
in the database just means you have it encoded into your application code.

------
reczy
a bit more hands-on, but it's possible to create a functional index to improve
json query performance in postgres:

[https://postgres.heroku.com/blog/past/2013/6/5/javascript_in...](https://postgres.heroku.com/blog/past/2013/6/5/javascript_in_your_postgres/)

