SQL e NoSQL
Os modelos de dados disponíveis e os critérios para escolher o banco de um sistema.
A escolha do banco depende de três perguntas: qual é o formato dos dados, quais consultas o sistema faz e quais garantias ele exige quando algo dá errado. Velocidade e escala entram depois, e com menos peso do que costumam receber.
Comparação entre as famílias
| Família | Melhor em | Pior em |
|---|---|---|
| Relacional | Dados com relacionamentos, consultas variadas, integridade garantida pelo banco | Escrita em volume muito alto distribuída por várias máquinas |
| Documentos | Entidades lidas sempre inteiras, formatos que variam entre registros | Relatórios que cruzam coleções, dados muito relacionados |
| Chave-valor | Leitura e escrita por chave com latência mínima | Qualquer consulta que não seja pela chave |
| Colunar de linha larga | Volume enorme de escrita, séries de eventos, alta disponibilidade em várias regiões | Consultas que não foram previstas no desenho |
| Grafos | Percorrer relacionamentos em várias profundidades | Agregações e varreduras simples em grande volume |
O relacional como ponto de partida
Para a maioria dos sistemas, um banco relacional como PostgreSQL ou MySQL é a escolha inicial mais segura:
- Os requisitos mudam, e o SQL responde perguntas que ninguém previu no início.
- O banco protege a integridade: chaves estrangeiras, restrições e transações evitam uma classe inteira de erros.
- Um único servidor bem configurado atende milhares de transações por segundo, muito além do que a maior parte dos sistemas vai precisar.
- O PostgreSQL cobre vários casos de outras famílias:
JSONBpara documentos, busca textual, extensões geográficas e vetoriais.
A ideia de que bancos relacionais "não escalam" vem de uma época de servidores menores. Réplicas de leitura, particionamento e cache levam um banco relacional muito longe antes que outra arquitetura seja necessária.
Quando um banco de documentos faz sentido
| Sinal | Exemplo |
|---|---|
| A entidade é lida e gravada sempre inteira | Um catálogo em que cada produto tem atributos diferentes |
| O formato varia muito entre registros | Formulários configuráveis pelos clientes |
| Os relacionamentos são poucos e rasos | Perfis de usuário com preferências aninhadas |
| A equipe conhece bem as consultas que vai fazer | Um aplicativo com telas estáveis |
O desenho de documentos começa pelas consultas, e não pelas entidades. A regra prática é embutir o que é lido junto e referenciar o que cresce sem limite ou é compartilhado. Os itens de um pedido ficam embutidos no pedido. Os pedidos de um cliente não ficam embutidos no cliente, porque crescem para sempre.
Quando as outras famílias fazem sentido
| Família | Situação típica | Observação |
|---|---|---|
| Chave-valor | Cache, sessões, contadores, limites de requisição | Quase sempre ao lado de um banco principal, e não no lugar dele |
| Colunar | Milhões de eventos por segundo, telemetria, mensagens, alta disponibilidade em várias regiões | Exige desenhar uma tabela por consulta |
| Grafos | Recomendações, detecção de fraude, redes de relacionamento | Muitas vezes como banco auxiliar, alimentado pelo principal |
Mais de um banco no mesmo sistema
Sistemas maiores costumam usar vários bancos, cada um para o que faz melhor. É a persistência poliglota:
| Necessidade | Banco |
|---|---|
| Pedidos, clientes, pagamentos | Relacional |
| Sessões e cache | Chave-valor |
| Busca no catálogo | Motor de busca textual |
| Eventos de navegação para análise | Colunar ou armazém analítico |
Cada banco a mais custa operação, monitoramento, backup e conhecimento da equipe, além do trabalho de manter os dados sincronizados entre eles. Acrescente um banco quando houver um problema concreto que o atual não resolve bem.
Mitos comuns
| Afirmação | O que de fato acontece |
|---|---|
| "NoSQL é mais rápido" | Cada banco é rápido nas consultas para as quais foi desenhado. Fora delas, qualquer um é lento |
| "SQL não escala" | Escala longe com réplicas, particionamento e cache. O limite real raramente é atingido |
| "NoSQL não tem transações" | MongoDB, DynamoDB e outros têm transações, com regras e custos próprios |
| "Sem esquema é mais ágil" | É mais ágil no começo. Depois, a falta de esquema vira custo em cada consulta |
Como escolher
| Situação | Escolha |
|---|---|
| Sistema de negócio típico: cadastros, pedidos, financeiro | Relacional |
| Não está claro como os dados serão consultados | Relacional |
| Catálogo com atributos muito variados | Relacional com colunas JSONB ou banco de documentos |
| Cache, sessões, filas simples | Chave-valor, ao lado do principal |
| Escrita massiva de eventos em várias regiões | Colunar de linha larga |
| Relacionamentos profundos são o centro do produto | Grafo, em geral como auxiliar |
Resumo da decisão
- Comece pelo relacional, salvo um motivo concreto para outro modelo.
- Escolha pelas consultas, e não pela moda ou por uma promessa de escala.
- Documentos quando a entidade é lida inteira e o formato varia; mantenha um esquema validado.
- Bancos especializados entram ao lado do principal, para um problema específico.
- Cada banco a mais precisa justificar o custo de operá-lo.
O próximo nível mostra a mesma operação num banco relacional, nas cinco linguagens, e no MongoDB.
Prompts para aprofundar
Ao abrir no ChatGPT ou no Claude, o prompt é enviado ao serviço escolhido pela URL e também fica copiado na sua área de transferência.
Escolher o banco do meu sistema
Preciso escolher o banco de dados de um sistema e quero chegar à decisão entendendo os critérios. Faça estas perguntas, uma por vez, e espere as respostas: - O que o sistema faz e quais são as entidades principais? - Quais são as cinco consultas mais frequentes e os relatórios esperados? - O sistema precisa de transações que envolvem várias entidades? - Qual é o volume esperado de leitura e escrita no primeiro ano e em cinco anos? - A equipe já opera algum banco? Qual? Com as respostas, avalie para o meu caso um banco relacional, um banco de documentos e, se fizer sentido, alguma família especializada. Seja concreto sobre o que fica fácil e o que fica difícil em cada opção. Termine com uma recomendação, os riscos dela e os sinais que indicariam, no futuro, a necessidade de acrescentar outro banco.
Quando o relacional deixa de bastar
Quero entender até onde um banco relacional como o PostgreSQL vai antes de precisar de outra solução. Explique, com números aproximados e deixando claro que dependem do hardware e da carga: 1. O que um único servidor bem configurado aguenta em leitura e escrita. 2. Como réplicas de leitura, cache, particionamento de tabelas e sharding estendem esse limite, e o custo de cada um. 3. Quais recursos do PostgreSQL cobrem casos de outras famílias: JSONB, busca textual, extensões geográficas e vetoriais. 4. Quais sinais indicam que um problema específico pede outro banco. Depois me descreva quatro sistemas com cargas diferentes e pergunte se eu manteria só o relacional ou acrescentaria outro banco, corrigindo as minhas respostas.
Desenhar documentos a partir das consultas
Quero aprender a modelar dados num banco de documentos do jeito certo, começando pelas consultas. Pergunte qual sistema eu quero modelar, ou proponha um sistema de blog com autores, publicações, comentários e etiquetas. Depois: 1. Peça que eu liste as consultas que o sistema faz e ajude a completar a lista. 2. Explique a regra de embutir o que é lido junto e referenciar o que cresce sem limite ou é compartilhado. 3. Peça que eu proponha o desenho dos documentos, e comente cada decisão. 4. Mostre o desenho recomendado, os índices necessários e uma regra de validação de esquema. 5. Mostre duas consultas que esse desenho deixa difíceis, e como resolvê-las. No final, compare com o mesmo sistema num banco relacional, em uma tabela.