“Qual banco aguenta mais escala: SQL ou NoSQL?” parece uma boa pergunta, mas começa pelo lugar errado. Antes da tecnologia, precisamos entender quais dados serão armazenados, como serão consultados, quais regras não podem ser violadas e como o sistema deve falhar.
Um checkout precisa confirmar pedido, pagamento e estoque com regras rigorosas. Um catálogo de produtos precisa servir páginas com atributos muito diferentes. Uma linha do tempo recebe muitas escritas e leituras por usuário. Embora todos armazenem dados, seus padrões de acesso e suas garantias não são iguais.
O que são bancos SQL?
Neste contexto, SQL representa principalmente os bancos relacionais. Eles organizam dados em tabelas compostas por linhas e colunas, conectadas por relacionamentos explícitos.
Um e-commerce pode separar clientes, pedidos, itens e produtos:
customers 1 ─── N orders 1 ─── N order_items N ─── 1 products
O esquema define tipos, chaves e restrições. Uma FOREIGN KEY, por exemplo, pode impedir que um item faça referência a um pedido inexistente. Consultas SQL combinam tabelas, filtram, agregam e ordenam dados sem exigir que cada pergunta tenha sido prevista no momento da escrita.
SELECT c.id, c.name, SUM(oi.quantity * oi.unit_price) AS total
FROM customers AS c
JOIN orders AS o ON o.customer_id = c.id
JOIN order_items AS oi ON oi.order_id = o.id
WHERE o.created_at >= DATE '2026-09-01'
GROUP BY c.id, c.name
ORDER BY total DESC;
Bancos relacionais costumam ser uma escolha forte quando o domínio possui muitos relacionamentos, regras de integridade, transações envolvendo vários registros e consultas que mudam conforme o produto evolui.
O que são bancos NoSQL?
NoSQL não descreve um único modelo nem significa “sem qualquer linguagem de consulta”. É um grupo de bancos não relacionais, com estruturas e garantias diferentes. As categorias mais comuns são:
| Modelo | Organização | Bom encaixe |
|---|---|---|
| Chave-valor | Uma chave aponta para um valor | Sessões, cache, preferências e contadores |
| Documentos | Objetos com campos aninhados | Catálogos, perfis e conteúdo com estrutura variável |
| Colunas largas | Linhas distribuídas por uma chave de partição | Eventos, telemetria e grandes volumes orientados à chave |
| Grafos | Vértices e relações | Fraude, recomendação e caminhos entre entidades |
Cada família otimiza operações diferentes. Dizer apenas “vamos usar NoSQL” é tão incompleto quanto dizer “vamos usar uma estrutura de dados”: ainda falta escolher qual estrutura resolve o problema.
Em um banco de documentos, um produto pode guardar seus atributos no próprio documento:
{
"id": "camiseta-42",
"name": "Camiseta DevPath",
"category": "vestuario",
"attributes": {
"color": "coral",
"sizes": ["P", "M", "G"]
}
}
Outro produto pode ter voltagem e potência em vez de cor e tamanhos. Essa flexibilidade ajuda catálogos heterogêneos, mas não elimina a necessidade de validar versões, campos obrigatórios e compatibilidade na aplicação.
SQL e NoSQL: comparação direta
| Critério | SQL relacional | NoSQL |
|---|---|---|
| Modelo | Tabelas e relações | Documentos, chave-valor, colunas largas ou grafos |
| Esquema | Explícito e aplicado pelo banco | Frequentemente flexível, mas ainda precisa de contrato |
| Relacionamentos | Joins e integridade referencial são recursos centrais | Dados relacionados costumam ser agregados ou resolvidos pela aplicação |
| Consultas | Boa flexibilidade para combinar e agregar dados | Geralmente favorece acessos previstos pelo modelo |
| Transações | Suporte maduro a transações entre registros e tabelas | Varia por produto; costuma ser mais simples dentro de um agregado |
| Escala | Pode escalar verticalmente, com réplicas e também particionamento | Muitos produtos priorizam distribuição e particionamento horizontal |
| Duplicação | Normalização reduz redundância | Desnormalização pode acelerar leituras, com custo de sincronização |
Essas são tendências, não leis. Bancos relacionais modernos suportam JSON, replicação e particionamento. Alguns bancos NoSQL oferecem transações, índices secundários e diferentes níveis de consistência. A decisão deve considerar o comportamento do produto específico, não apenas o rótulo da categoria.
Como escolher?
Uma escolha defensável começa pelo workload. Liste as operações importantes e responda às perguntas a seguir.
1. Quais são os padrões de acesso?
Não modele apenas as entidades; modele as perguntas que o sistema precisa responder.
Operação Frequência Requisito
Buscar pedido pelo ID muito alta < 100 ms
Listar pedidos recentes do cliente alta paginação por data
Fechar pedido e baixar estoque média consistência forte
Relatório mensal por categoria baixa pode ser assíncrono
Se as consultas são variadas e combinam entidades de maneiras novas, o modelo relacional oferece flexibilidade. Se o sistema acessa quase sempre um agregado completo por uma chave conhecida, um banco de documentos ou chave-valor pode simplificar o caminho crítico.
2. Quais invariantes precisam ser preservadas?
Uma invariante é uma regra que deve continuar verdadeira mesmo com concorrência e falhas. Exemplos:
- Um pagamento não pode ser contabilizado duas vezes;
- Um nome de usuário precisa ser único;
- Um item de pedido deve pertencer a um pedido existente;
- Uma transferência não pode criar dinheiro;
- O estoque não pode ficar negativo.
Constraints, transações e isolamento tornam bancos relacionais uma escolha natural quando várias entidades compartilham invariantes. Em NoSQL, confirme quais operações são atômicas, qual é o escopo das transações e quanto trabalho ficará na aplicação.
3. Como os dados crescem e são distribuídos?
“Muitos dados” não é uma unidade útil. Estime:
- Volume total e crescimento por mês;
- Leituras e escritas por segundo;
- Tamanho médio de cada registro;
- Distribuição das chaves;
- Regiões atendidas;
- Retenção e expiração;
- Picos e sazonalidade.
Um banco distribuído precisa decidir em qual partição cada dado ficará. Uma chave ruim, como uma data crescente ou um único cliente muito movimentado, pode criar uma hot partition: uma parte do cluster fica saturada enquanto as demais permanecem ociosas.
4. Qual consistência cada operação exige?
Não classifique o produto inteiro como “fortemente consistente” ou “eventualmente consistente”. Analise por operação.
Confirmar pagamento → leitura atual e escrita protegida
Exibir curtidas → pequeno atraso pode ser aceitável
Reservar estoque → concorrência precisa ser coordenada
Atualizar busca → índice pode convergir depois
O banco deve oferecer as garantias que o negócio exige. Se a leitura pode retornar um valor antigo, a interface e o workflow precisam continuar corretos nesse cenário.
5. A equipe consegue operar a solução?
Considere backup e restauração, monitoramento, upgrades, índices, capacidade, custo, suporte e conhecimento da equipe. Uma tecnologia adequada no papel pode ser uma má escolha se ninguém consegue diagnosticar uma consulta lenta ou recuperar os dados com segurança.
Serviços gerenciados reduzem parte do trabalho, mas não removem decisões sobre modelagem, índices, limites, consistência e custo.
Exemplo prático: e-commerce
Considere um e-commerce com clientes, catálogo, carrinho, pedidos, pagamentos e recomendações. Não existe obrigação de armazenar tudo no mesmo modelo.
Começo simples: um banco relacional
No início, um banco SQL pode atender todo o domínio:
Aplicação
│
└── Banco relacional
├── clientes
├── produtos
├── pedidos e itens
├── pagamentos
└── estoque
Essa solução mantém poucos componentes operacionais, permite transações no checkout e suporta consultas que ainda estão mudando. Um campo JSON pode acomodar atributos variáveis do catálogo sem introduzir imediatamente outro banco.
Evolução orientada por um problema real
Com o crescimento, a equipe mede que a navegação do catálogo concentra grande volume de leitura e possui documentos naturalmente agregados. Ela cria uma projeção de leitura em um banco de documentos, atualizada por eventos:
┌── Banco relacional
Checkout e cadastro ──►│ pedidos, pagamentos, estoque
└──────────┬───────────
│ eventos
▼
┌── Banco de documentos
Navegação no catálogo ◄┤ projeção de produtos
└──────────────────────
O banco relacional continua como fonte de verdade das operações transacionais. O banco de documentos serve uma visão otimizada para leitura. Essa combinação é chamada de persistência poliglota.
Ela melhora um gargalo específico, mas cria novos custos:
- Eventos podem atrasar, falhar ou chegar repetidos;
- A projeção pode ficar temporariamente desatualizada;
- É preciso reconciliar e reconstruir dados;
- Backups e observabilidade passam a cobrir dois bancos;
- A equipe precisa entender qual sistema é a fonte de verdade.
Vantagens
Quando SQL tende a ajudar
- Relacionamentos e consultas ad hoc fazem parte do domínio;
- Constraints devem proteger regras críticas;
- Vários registros precisam mudar na mesma transação;
- O produto ainda muda e os acessos não estão totalmente conhecidos;
- A equipe busca um modelo geral antes de otimizar casos específicos.
Quando NoSQL tende a ajudar
- O modelo especializado representa melhor o problema, como caminhos em um grafo;
- A maior parte dos acessos busca um agregado por uma chave conhecida;
- A estrutura dos registros varia e evolui com frequência;
- O workload exige distribuição horizontal alinhada a uma boa chave de partição;
- Desnormalizar dados oferece um ganho importante e a aplicação aceita o custo de mantê-los consistentes.
Limitações e trade-offs
| Decisão | Benefício | Custo ou risco |
|---|---|---|
| Normalizar dados | Menos duplicação e atualizações centralizadas | Mais joins e possível custo de consulta |
| Desnormalizar dados | Leituras diretas e alinhadas ao acesso | Duplicação, sincronização e risco de versões divergentes |
| Particionar horizontalmente | Distribui volume e throughput | Escolha de chave, hot partitions e consultas entre partições |
| Usar vários bancos | Cada workload recebe um modelo adequado | Mais operação, integração e consistência entre sistemas |
| Adotar esquema flexível | Evolução gradual dos documentos | Versões incompatíveis e validação movida para a aplicação |
Erros comuns
Acreditar que SQL não escala
Bancos relacionais podem usar índices, réplicas de leitura, particionamento e sharding. A pergunta útil é se uma implementação e uma arquitetura específicas cumprem o volume, a latência e as garantias necessárias dentro do orçamento.
Escolher NoSQL apenas por ter esquema flexível
Dados sem contrato explícito ainda possuem formatos esperados pelo código. Sem validação e estratégia de migração, a flexibilidade vira documentos incompatíveis e condicionais espalhadas pela aplicação.
Modelar entidades sem listar consultas
Em modelos NoSQL, principalmente, a chave de partição e a estrutura dos agregados dependem dos acessos. Descobrir depois que uma consulta crítica atravessa todas as partições pode exigir duplicação ou uma remodelagem cara.
Ignorar consistência na desnormalização
Copiar o nome e o preço de um produto em vários documentos acelera leituras, mas exige decidir se dados antigos são aceitáveis, como propagar mudanças e como reparar divergências.
Introduzir um banco para cada problema cedo demais
Persistência poliglota pode ser adequada, mas cada banco adiciona provisionamento, credenciais, métricas, alertas, backup, restauração e conhecimento especializado. Complexidade operacional também é um requisito arquitetural.
Comparar categorias em vez de produtos e configurações
“SQL é consistente” e “NoSQL é eventualmente consistente” são generalizações insuficientes. Verifique transações, níveis de isolamento, replicação, comportamento em falhas e opções de leitura e escrita do banco avaliado.
Checklist de decisão
Antes de escolher, registre:
- As cinco operações mais importantes e sua frequência;
- Os limites de latência e disponibilidade de cada operação;
- As invariantes e o escopo atômico necessário;
- O volume atual, o crescimento e os picos esperados;
- As chaves de acesso e a distribuição provável dos dados;
- As consultas que precisam de joins, filtros ou agregações;
- O atraso de replicação ou de projeção que o negócio aceita;
- O plano de índices, backup, restauração e observabilidade;
- O custo financeiro e operacional da solução;
- A evidência que justificaria adicionar outra tecnologia.
Relações + consultas variadas + invariantes entre registros
↓
Comece avaliando SQL
Acesso por chave + agregado natural + distribuição previsível
↓
Avalie o modelo NoSQL correspondente
Requisitos diferentes dentro do mesmo produto
↓
Comece simples; evolua com persistência poliglota se necessário
Perguntas de entrevista
- Por que “SQL não escala” é uma afirmação incompleta?
- Como os padrões de acesso influenciam a escolha do modelo de dados?
- Qual é o custo de desnormalizar o catálogo de um e-commerce?
- Como uma chave de partição ruim cria uma hot partition?
- Quando um esquema flexível ajuda e quando ele transfere riscos para a aplicação?
- Quais operações de um e-commerce exigem consistência forte e quais podem aceitar atraso?
- Em que situação você usaria SQL e NoSQL no mesmo produto?
- Que métricas ou limites fariam você trocar ou complementar o banco atual?
Próximos conteúdos
Continue com transações e propriedades ACID para entender as garantias de uma unidade de trabalho. Depois, estude índices, replicação, particionamento e sharding e o teorema CAP. Esses conceitos ajudam a transformar a escolha inicial em uma arquitetura que continua correta e operável conforme o sistema cresce.