Como decidir entre SQL e NoSQL

O problema

Discussão de SQL vs NoSQL quase sempre desanda cedo.

Um lado vira:

• moderno
• escalável
• flexível

O outro vira:

• antigo
• rígido
• burocrático

Esse tipo de conversa é ruim porque troca critério por rótulo.

Banco não se escolhe por imagem.

Banco se escolhe por encaixe.

E o encaixe depende muito mais de:

• como o sistema lê
• como o sistema escreve
• quanto de consistência ele exige
• que forma o dado realmente tem

do que de slogan sobre tecnologia.

Modelo mental

Pense assim:

SQL e NoSQL não competem no vazio. Eles respondem melhor a formatos diferentes de problema.

Essa frase é o centro do assunto.

SQL tende a ser forte quando você precisa de:

• relações claras entre entidades
• consultas relacionais e agregações frequentes
• integridade forte
• transação confiável

NoSQL tende a ser forte quando você precisa de:

• modelo mais flexível por documento ou chave
• leitura simples e previsível
• distribuição natural em certos cenários
• acesso muito orientado ao padrão específico do dado

Isso não quer dizer que:

• SQL não escala
• NoSQL não faz consistência

Quer dizer só que as forças mais naturais costumam aparecer em contextos diferentes.

Quebrando o problema

A primeira pergunta não é sobre tecnologia

Antes de falar “Postgres”, “Mongo”, “Redis” ou qualquer outra coisa, vale responder:

• qual é a entidade principal?
• o dado se relaciona fortemente com outros?
• a leitura principal é por chave ou por consulta relacional?
• a operação depende de transação forte?
• o formato do registro muda muito ou é bem previsível?

Essas perguntas normalmente esclarecem mais do que comparar bancos por fama.

SQL costuma encaixar bem quando a relação importa de verdade

Se o seu sistema vive de coisas como:

• pedido, cliente, pagamento e reembolso
• usuário, permissão, organização e histórico
• relatório com filtro, junção e agregação

então relação não é detalhe.

Ela é parte do problema.

Nesse tipo de cenário, SQL costuma brilhar porque conversa bem com:

• integridade referencial
• consulta rica
• transação
• consistência forte local

Se você tenta fugir disso cedo demais, pode acabar trocando clareza por improviso.

NoSQL costuma encaixar melhor quando o acesso é muito previsível

Tem cenário em que o valor não está em atravessar relação o tempo todo.

Está em:

• buscar rápido por chave
• gravar documento com estrutura variável
• operar em volume alto com padrão de acesso bem conhecido

Exemplos plausíveis:

• sessão
• carrinho temporário
• cache de leitura
• evento bruto
• documento cujo formato varia bastante

Nesses casos, um modelo não relacional pode simplificar bastante.

Mas o ganho não vem do nome “NoSQL”.

Vem do fato de que ele combina com o jeito como o dado realmente é usado.

”NoSQL” é um balde grande demais

Esse é um erro bem comum.

Muita gente fala “NoSQL” como se fosse uma coisa só.

Não é.

Dentro desse grupo entram, por exemplo:

• documento
• chave-valor
• coluna larga
• grafo

E cada um resolve problema diferente.

Então responder só “eu usaria NoSQL” ainda costuma ser vago demais.

Escala sozinha não decide a resposta

Outro tropeço clássico:

• “em escala eu usaria NoSQL”

Escala importa, claro.

Mas escala sem tipo de acesso ainda é conversa pela metade.

Você pode ter sistema enorme em SQL.

Você pode ter sistema pequeno que se beneficia de um modelo NoSQL específico.

O que decide não é a palavra “escala” sozinha.

É a combinação entre:

• volume
• padrão de leitura
• padrão de escrita
• consistência exigida
• custo operacional

Consistência costuma ser o divisor mais honesto

Esse ponto ajuda bastante em entrevista.

Se a operação depende de coisas como:

• débito e crédito fecharem juntos
• estoque e pedido ficarem coerentes
• histórico e estado atual não se contradizerem

então a conversa puxa forte para garantias transacionais e integridade séria.

Se o fluxo tolera:

• atraso
• reprocessamento
• documento com esquema mais solto
• leitura direta por chave

o espaço para modelos não relacionais cresce.

Misturar bancos cedo demais também é armadilha

Tem caso em que usar mais de um modelo faz sentido.

Mas resposta madura quase nunca começa por:

• “usa os dois”

Ela começa por:

• “o que um banco só não está resolvendo?”

Se você pula direto para arquitetura híbrida sem provar a necessidade, a resposta soa mais como fuga do que como critério.

Exemplo simples

Imagine um sistema de pedidos.

Você tem:

• clientes
• pedidos
• itens do pedido
• pagamento
• reembolso

E precisa:

• garantir coerência entre pedido e pagamento
• consultar histórico por cliente
• gerar relatório com várias relações
• impedir estado parcial em operações críticas

Esse é um caso em que SQL tende a encaixar muito bem.

Agora imagine um pipeline de eventos de clique:

• volume alto
• escrita simples
• esquema evoluindo com frequência
• leitura posterior por processamento assíncrono

Aqui um modelo documental ou outro modelo não relacional pode fazer mais sentido, dependendo do acesso.

O ponto não é declarar vencedor.

O ponto é perceber que o problema mudou.

Erros comuns

• Escolher banco pela moda do momento.
• Usar NoSQL para fugir da disciplina de modelar e nomear regra.
• Usar SQL por reflexo sem olhar o padrão real de acesso.
• Falar “NoSQL escala mais” como se isso resolvesse a discussão.
• Ignorar consistência porque a palavra “flexibilidade” parece mais moderna.
• Propor dois bancos cedo demais sem provar por que um só não basta.

Como um senior pensa

Um senior normalmente puxa a conversa para o uso real.

Ele pensa algo como:

• “qual é a pergunta dominante que o sistema faz ao dado?”
• “o dado se relaciona com força ou é mais isolado?”
• “o custo maior está em consulta rica, distribuição, flexibilidade ou integridade?”

E costuma responder sem torcida.

Algo nesta linha:

“Se esse fluxo depende de relação forte, consulta rica e transação confiável, SQL me atende melhor. Se o dado é mais flexível e o acesso é simples por chave ou documento, aí eu considero um modelo NoSQL específico.”

Repare no ponto:

não tem identidade de ferramenta.

Tem critério sobre o problema.

O que o entrevistador quer ver

Em entrevista, esse tema aparece muito porque revela rápido se você está pensando ou só repetindo clichê.

O avaliador normalmente quer ver se você:

• conecta banco ao padrão de acesso
• leva consistência a sério
• diferencia relação forte de estrutura flexível
• evita resposta tribal

Uma resposta forte costuma ter esta forma:

“Eu não começo escolhendo pelo nome do banco. Primeiro olho se o sistema depende de relação forte, transação e consulta relacional frequente. Se sim, SQL costuma ser o encaixe mais natural. Se o dado é mais flexível e o acesso é previsível por chave ou documento, um modelo NoSQL pode simplificar bastante. O ponto para mim é o formato do problema, não a moda.”

Isso passa maturidade.

SQL e NoSQL não são ideologias. São ferramentas para formatos diferentes de dado e acesso.

Se você escolhe pelo problema, a conversa fica técnica. Se escolhe pelo hype, ela vira torcida.