Exato, no caso sua ideia seria adicionar colunas pra cada funcionalidade? Por ex · ownerczx

Exato, no caso sua ideia seria adicionar colunas pra cada funcionalidade?

Por exemplo tabela de planos contendo:
nome, usuarios, email_personalizado, dominio_proprio, notas_fiscais_mes, armazenamento

Enquanto a segunda opção seria:
nome, funcionalidades - Onde funcionalidades será um json com cada coluna utilizada anteriormente, pra ficar mais flexível.

E na terceira opção:
Tabela planos contendo apenas o nome, tabela funcionalidades contendo nome, descricao, valor e outra tabela pra relacionar plano e funcionalidades.

Independente das opções acima, na tabela de tenants vai haver uma coluna plano_id pra fazer a relação.

Pra pegar a data de expiração pensei em uma tabela a parte com o nome de assinaturas onde irá conter as colunas tenant_id, plano_id, assinatura_efetuada_em, expira_em pra manter os logs de assinaturas.

Tudo depende das suas regras de negócio.
A sugestão de colocar as funcionalidades como colunas implica em você não estar mudando o tempo todo.
Porém, se você pensar bem, sempre que uma funcionalidade é lançada, você fez diversas alterações no código, no sistema, no banco, nas interfaces etc.. não tem problema nenhum incluir uma coluna a mais. A vantagem é que fica mais simples de manter e fazer as buscas.
Sobre a questão dos logs das assinaturas, esse log pode ficar separado, somente como informação extra. Não necessariamente você precisaria usá-lo como registro. Para você, é mais simples ter essa informação na tabela tenant e deixar o log ser somente log.
Eu só usaria outra opção diferente dessa se você viesse a ter múltiplos planos pra um mesmo cliente. Por exemplo: o cara comprou o plano intermediário e comprou uma integração fiscal e um pacote de mil notas a mais, por exemplo. Aí você se obriga a ter um relacionamento n:n. Não dá pra fazer isso usando as colunas pois elas podem variar muito entre clientes. Mas no seu caso, usar colunas para funcionalidades atende perfeitamente.
Inclusive, se você quiser facilitar ainda mais, nem precisa das colunas. Você pode deixar fixo no seu código o que cada plano tem. Por exemplo, você tem uma interface IPlan e as suas classes implementam ela. Assim você deixa seu banco sem modificações por causa de inclusão de funcionalidades.
Mas fica a seu critério. Tudo depende do que você planeja.
As sugestões são baseadas nos dados que você passou