True, Postgres 9.1 does not have json / jsonb data types. But there is the additional module hstore providing the data type of the same name.

hstore has been in the core release since Postgres 8.3 (it's very mature). For just text data and no nesting it's just as good as json, if not better. (jsonb introduced some new candy.)

If you only have a few dozen of sparsely populated columns I would also consider wide rows with many columns just being NULL. NULL storage is very cheap in Postgres.

• Many columns vs few tables - performance wise

You could also go with an EAV (Entity-attribute-value) design. Related answer discussing pitfalls:

• Is there a name for this database schema of key values?

But consider upgrading to a current version of Postgres first. Postgres 9.1 reaches EOL in Sept 2016.

True, Postgres 9.1 does not have json / jsonb data types. But there is the additional module hstore providing the data type of the same name.

hstore has been in the core release since Postgres 8.3 (it's very mature). For just text data and no nesting it's just as good as json, if not better. (jsonb introduced some new candy.)

If you only have a few dozen of sparsely populated columns I would also consider wide rows with many columns just being NULL. NULL storage is very cheap in Postgres.

• Many columns vs few tables - performance wise

You could also go with an EAV (Entity-attribute-value) design. Related answer discussing pitfalls:

• Is there a name for this database schema of key values?

But consider upgrading to a current version of Postgres first. Postgres 9.1 reaches EOL in Sept 2016.

True, Postgres 9.1 does not have json / jsonb data types. But there is the additional module hstore providing the data type of the same name.

hstore has been in the core release since Postgres 8.3 (it's very mature). For just text data and no nesting it's just as good as json, if not better. (jsonb introduced some new candy.)

If you only have a few dozen of sparsely populated columns I would also consider wide rows with many columns just being NULL. NULL storage is very cheap in Postgres.

• Many columns vs few tables - performance wise

You could also go with an EAV (Entity-attribute-value) design. Related answer discussing pitfalls of related :

• Is there a name for this database schema of key values?

But consider upgrading to a current version of Postgres first. Postgres 9.1 reaches EOL in Sept 2016.

True, Postgres 9.1 does not have json / jsonb data types. But there is the additional module hstore providing the data type of the same name.

hstore has been in the core release since Postgres 8.3 (it's very mature). For just text data and no nesting it's just as good as json, if not better. (jsonb introduced some new candy.)

If you only have a few dozen of sparsely populated columns I would also consider wide rows with many columns just being NULL. NULL storage is very cheap in Postgres.

• Many columns vs few tables - performance wise

You could also go with an EAV (Entity-attribute-value) design. Related answer discussing pitfalls:

• Is there a name for this database schema of key values?

But consider upgrading to a current version of Postgres first. Postgres 9.1 reaches EOL in Sept 2016.