System Design/02 - Componentes/Databases2 min
SQL vs NoSQL
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off?
- Como isso falha em produção?
Conceito
| SQL (relacional) | NoSQL | |
|---|---|---|
| Schema | Rígido, validado na escrita | Flexível, validado na leitura |
| Junções | Nativas e otimizadas | Manuais ou inexistentes |
| Transações | ACID multi-tabela | Limitadas (frequentemente por item) |
| Consistência | Forte por padrão | Frequentemente eventual |
| Escala de escrita | Vertical → sharding manual | Horizontal por design |
| Consulta ad-hoc | Excelente | Ruim fora do padrão previsto |
| Modelagem | Pelos dados (normalizar) | Pelas consultas |
A inversão de modelagem
É o ponto que mais confunde quem migra. Em SQL você modela as entidades e normaliza; as consultas vêm depois, e o otimizador resolve.
Em NoSQL você modela as consultas. A pergunta inicial não é "quais são minhas entidades", é "quais acessos meu sistema faz" — e o esquema é desenhado para servi-los, aceitando duplicação de dados como parte do desenho.
ACID vs BASE
| ACID | BASE |
|---|---|
| Atomicidade | Basically Available |
| Consistência | Soft state |
| Isolamento | Eventual consistency |
| Durabilidade |
Trade-offs
A escolha real raramente é sobre volume — é sobre quão previsível é o acesso e quanto a consistência forte vale.
SQL brilha quando as consultas mudam, quando há relacionamentos ricos, e quando invariantes precisam ser garantidas pelo banco (integridade referencial, unicidade, transação multi-registro). Bancos relacionais modernos escalam muito mais do que a reputação sugere: uma instância bem ajustada atende dezenas de milhares de transações por segundo.
NoSQL brilha quando o padrão de acesso é conhecido e estável, quando o volume exige escrita distribuída, e quando o modelo de dados não é tabular.
O erro mais caro é adotar NoSQL por moda e descobrir seis meses depois que o negócio precisa de uma consulta que o modelo não suporta — em NoSQL, mudar o padrão de acesso frequentemente significa remodelar e migrar tudo.
O erro simétrico é forçar relacional onde o modelo não é relacional: guardar grafo com auto-junções recursivas, ou séries temporais com bilhões de linhas.
E vale lembrar: Postgres com jsonb cobre boa parte dos casos de documento, com transação ACID por cima. "Preciso de schema flexível" nem sempre implica trocar de banco.
Exemplo prático
Um sistema financeiro precisa garantir que débito e crédito aconteçam juntos, com saldo nunca negativo, e que relatórios arbitrários possam ser escritos amanhã. É SQL — a transação e a consulta ad-hoc são o requisito, não um detalhe.
Um sistema de sessões guarda sessao:{token} → dados, com acesso sempre por chave, milhões de escritas por segundo e TTL. É chave-valor — junção não existe, consulta ad-hoc não existe, e escala horizontal é o requisito.
Não é o volume que decidiu nenhum dos dois casos.
Relacionado
Parte de Databases · roadmap.sh/system-design