O erro não é discordar do cliente, é assumir o risco por ele

Você não deve simplesmente obedecer, porque:

daqui a 6 meses o sistema continuará lento

daqui a 1 ano o cliente vai reclamar de manutenção

daqui a 2 anos você será culpado por algo que avisou antes

Faça o seguinte:

1º Documente por escrito:

• os problemas do modelo atual

• os riscos de escalabilidade

• as limitações futuras

2º Documente sua proposta com benefícios claros:

• manutenção

• performance

• segurança

• evolução

3º Apresente duas opções formais:

• implementação conforme especificação atual, sem garantia de performance futura

• implementação com refatoração estrutural, garantindo base sólida.

E peça uma decisão registrada.

Se o cliente escolher a solução ruim, você executa, mas:

com escopo claro

com responsabilidade técnica delimitada

sem assumir culpa futura

Show mano, clientes realmente dão muita dor de cabeça já sem ter conhecimento técnico e tendo um conhecimento técnico defasado, acredito que seja pior kkkkkk. Tenho experiência nisso, já que fazem mais de 5 anos que trabalho como freelancer e já vi de tudo!

Nesse caso, eu recomendo o contra intuitivo, seguir o que o cliente quer, mas com um contrato de levantamento de requisitos, mostrando o que ele quer segundo as palavras dele e explicando que caso ele queira alterações posteriores ela deverá ser discutida num novo levantamento de requisitos para a atualização e cobrada à parte.

Isso é bom primeiramente evitando ele dizer que o sistema não ficou bom, afinal de contas se ele soubesse do que está querendo/fazendo ele mesmo faria e não contrataria alguém, como ele não sabe ele vai pagar pelo sistema "ruim" e depois pelo bom e esse documento te ajuda a se resguardar. Em segundo lugar, vai te resguardar do re-trabalho programadores não são pagos por hora ou linhas de código, são pagos por solucionar problemas, se o cliente não quer tua solução, tu cobra a solução dele e a tua e aí ele aprende a dar valor a sua solução fazendo com que esse problema não se repita.

Tem um vídeo muito show que fala sobre isso, sempre que vejo alguém com dúvida em preço/processo eu passo ele. O vídeo é esse, caso interesse:

https://www.youtube.com/watch?v=EkAOLjjImUc&t=1158s

A playlist toda é muito boa! Super recomendo!

O banco atual é SQL Server e estou construindo agora com PostgreSQL.

Mudar de banco não vai ter diferença nenhuma. Você tem que aplicar práticas inteligentes de otimização de querys e indices.

milhões de registros por empresa

Milhões de registros não é nenhum problema para bancos bem configurados.

O limite teórico do PostgreSQL por tabela é 1 bilhão de registros. É a partir desse numero que otimizar é mais custoso que dividir.

A única coisa que na minha opinião vai resolver o problema é um bom DBA.

PostgreSQL vs SQLServer

Os dois vão ter um desempenho péssimo para querys mal estruturadas e mal indexadas

Os dois vão ter um desempenho semelhante para querys bem estruturadas e indexadas.

A diferença aqui só vai começar aparecer no bilhão.

Eu faria uma outra abordagem:
Uma tabela users_roles poderia ter papéis vinculados ou não a empresas.
Ex.:

o usuário pode ser gerente na empresa 1
o dono pode ter permissão admin nas empresas 1, 2 e 3.
o suporte teria permissão de suporte em todas as empresas. poderia ser null no lugar da empresa.

Users
id: uuid
name: string

Roles
id: uuid
name: string
requires_business_id: boolean

Business
id: uuid
name: string

users_roles
id: uuid
user_id: uuid
role_id: uuid
business_id: uuid <-- não obrigatório
is_active: boolean

Dessa forma, você permitiria que o mesmo usuário tivesse n papéis em cada empresa. Inclusive, se um dia quiserem colocar um suporte que seja específico somente de 2 empresas, ou um gerente que possa visualizar 3 empresas, é possível com essa modelagem. Poderia deixar o business_id não obrigatório para que seja considerado como "todos". Quando o roles tiver o requires_business_id, então aquele perfil exige que seja informado uma empresa.

Essa modelagem é usada nos meus sistemas seguindo a mesma ideia, onde o mesmo usuário pode ser gerente de uma loja e atendente da outra, por exemplo. E os papéis de dev, admin e suporte são de toodos, então não precisaria informar uma loja.