Na maioria dos casos, eu usaria um esquema normalizado com uma tabela option_tag implementando o relacionamento muitos-para-muitos entre as tabelas option e tag . Implementação de referência aqui:

• Como implementar um relacionamento muitos-para-muitos no PostgreSQL?

Pode não ser a opção mais rápida em todos os aspectos, mas oferece toda a gama de funcionalidades do banco de dados, incluindo integridade referencial, restrições, toda a gama de tipos de dados, todas as opções de índice e atualizações baratas.

Para completar, adicione à sua lista de opções:

• hstore (boa opção)
• xml mais detalhado e mais complexo do que hstore ou jsonb , então eu só o usaria ao operar com XML.
• "cadeia de valores separados por vírgula" (muito simples, principalmente opção ruim)
• EAV (Entidade-Atributo-Valor) ou "pares nome-valor" (principalmente opção ruim)
  Detalhes nesta questão relacionada em dba.SE:
  • Existe um nome para essa estrutura de banco de dados?

Se a lista for apenas para exibição e raramente atualizada, eu consideraria uma matriz simples, que normalmente é menor e tem um desempenho melhor para isso do que o resto.

Leia a entrada de blog de Josh Berkus @a_horse linkado em seu comentário. Mas esteja ciente de que ele se concentra em casos de leitura selecionados. Josh admite:

E é aí que a abordagem normalizada ganha muito, especialmente quando você altera muito as tags únicas sob carga simultânea.

jsonb é apenas uma boa opção se você for operar com JSON de qualquer maneira e puder armazenar e recuperar JSON "como está".