vyegorov Думаю, что вас склоняют к No-SQL (key-value). Для этого будет лучше использовать JSONB тип.
для плоского key--value удобнее был hstore (в нём конкатенация была "искаропки")

vyegorov Массивы очень удобны для специфических задач. Но в целом для дизайна я предпочитаю реляционную модель. Она и гибка (для построения запросов), и строга (типы данных и ограничения целостности) одновременно.
для индексирования как по телу таблицы так и подчинённым записям реляционная модель будет пригодна , если завести такую штуку, как кросс-табличные индексы.

А пока их нет -- суем все нужные подчиненки в массив -- и имеем возможность индексировать хоть GIST-ом + btree_gist. (с поиском по операторам над массивами). Хоть btree по скалярным ф-ям от массивов (применяю). В букваре по gist-ам у Бартунова встречалось. Можно комбинировать -- строгая реляционка, + триггерно поддерживаемые мат-вью (плата -- двойная и более нагрузка на диск).

минусы массивов (и прочей НоСКЛ) -- стандартные средства разработки морд их не поддерживают в плане наличия готовых контролов. надо кодить.

vyegorov,

минусы массивов

если вы меняете содержимое починенной реляционной записи -- она меняется одна

в случае массива -- поменяется вся запись "головной". каждое изменение "подчиненной" -- перезапись всего. если в массиве элементов много, добавляются удаляются они отдельными операциями -- индексы там опухают -- только в путь. а в toast-ах после чистки бывают много--гигабайтные индексы по пустой таблице тостов. требуется reindex. в общем плата не маленькая.

кросс-индексы были бы гораздо предпочтительнее. IOT какой-нибудь, хотя бы -- для handjob-а.