If you know you are only storing two languages, they can go directly on the parent table, named english_text and spanish_text. If you are talking about the easy

If you know you are only storing two languages, they can go directly on the parent table, named english_text and spanish_text. If you are talking about the easyness of storing a hashmap in NoSQL, ie: { english :'text', spanish : 'text', french: 'text' } You can achieve this in the same table with the JSON storage type: http://www.postgresql.org/docs/devel/static/datatype-json.html http://www.postgresql.org/docs/devel/static/datatype-json.ht... Really though, a decent ORM will take care of all the foreign key implementation, and a hashmap is well served by a 2nd table called 'texts' with 3 columns. I can see why you would be opposed to this, because of the extra join but given the right indexes it won't be slow at all.