Startups costumam culpar a aplicação por tudo porque é a parte que os desenvolvedores veem. Mas chega uma fase em que metade da experiência do usuário é determinada por decisões antigas de banco: uma query inocente, um índice que nunca existiu, uma tabela que cresceu mais do que o otimismo do roadmap.
O gargalo costuma chegar devagar
A tela leva 300 milissegundos, depois 700, depois dois segundos. Ninguém abre incidente porque ainda funciona. Só que cada novo cliente amplia uma consulta que já era ruim. Aí alguém joga mais CPU no banco e compra alguns meses de silêncio. Antes de escalar máquina, olhe as consultas mais caras e frequentes. Verifique planos de execução, índices, cardinalidade, N+1, paginação e operações que varrem dados sem necessidade. Performance de banco raramente melhora com fé.
Modelagem também é produto
Toda vez que o produto cria uma regra nova, a estrutura de dados ganha cicatriz. Isso é normal. O problema é não revisar os compromissos. Campos genéricos, JSON para tudo e relações improvisadas compram velocidade no começo; em algum momento podem cobrar complexidade em relatório, busca, consistência e migração.
Não otimize o que não dói
Também não transforme o banco em religião. Se a query roda dez vezes por dia e leva 400 milissegundos, talvez exista coisa melhor para fazer. Priorize pelo impacto: latência percebida, custo, risco, bloqueio de feature e trabalho operacional. O banco não precisa ser perfeito. Precisa continuar sendo uma fundação que aguenta o prédio que você realmente está construindo, não o arranha-céu imaginário do pitch.