Banco de dados relacional ou NoSQL: qual escolher?

O fornecedor apresenta a proposta do sistema novo e, no meio dos slides, aparece uma escolha que ninguém na diretoria sabe avaliar: o banco de dados. Um lado defende o relacional "de sempre"; outro diz que NoSQL é mais moderno, escala melhor e deixa o desenvolvimento mais rápido. A decisão parece técnica demais para entrar na pauta, e acaba tomada pela preferência de quem vai programar.

O problema aparece meses depois. O financeiro fecha o mês e o saldo do relatório não bate com o extrato. O estoque mostra uma quantidade na tela de vendas e outra no inventário. Ou o contrário: um banco rígido demais trava cada cadastro novo de produto com atributo diferente, e qualquer ajuste vira projeto.

O banco de dados é a parte do sistema mais difícil de trocar depois. Código se reescreve por módulos; dados acumulados em anos de operação, com regras embutidas na forma como foram gravados, não. Este texto explica como escolher pelo tipo de dado e de operação do negócio, e por que o relacional segue sendo o padrão seguro para a maioria dos sistemas de gestão.

A resposta curta

Para quem precisa da resposta antes do detalhe:

• Sistemas que movimentam dinheiro, estoque, pedidos, notas e contratos devem ter um banco relacional como base. PostgreSQL, MySQL, SQL Server e Oracle são exemplos. Eles garantem que uma operação com várias etapas acontece por inteiro ou não acontece, e que dois usuários não vendem a mesma última unidade.
• NoSQL faz sentido para partes específicas: catálogos com atributos muito variados, sessões e cache, registros de eventos em grande volume, leituras de sensores, buscas por texto. Quase sempre como complemento, não como base do sistema de gestão.
• A pergunta certa não é "qual é melhor", é "qual dado mora onde". Um sistema bem desenhado pode usar os dois, cada um no papel em que é forte.

O resto do texto explica o porquê, com exemplos que aparecem no dia a dia de uma empresa brasileira.

Por que a escolha do banco importa para o negócio

Para o gestor, o banco de dados define quatro coisas que ele sente na operação:

• Se o número é confiável. Saldo de caixa, posição de estoque, títulos a receber. Um banco que aceita gravar metade de uma operação produz números que ninguém consegue explicar.
• Quanto custa mudar. Incluir um campo, criar uma regra nova, abrir uma filial. Alguns modelos facilitam mudanças; outros exigem cuidado em cada alteração.
• Como sai o relatório. Cruzar vendas por vendedor, por região e por mês é natural em um modelo e trabalhoso em outro.
• Quem consegue manter. Profissionais que dominam bancos relacionais existem em todo o mercado brasileiro. Tecnologias de nicho dependem de poucas pessoas.

Essa escolha conversa com outras decisões de arquitetura, como dividir ou não o sistema em serviços separados. Se esse debate também está na mesa, vale ler monólito ou microsserviços antes de decidir o banco, porque uma escolha influencia a outra.

Banco relacional: consistência para dinheiro e estoque

Um banco relacional organiza os dados em tabelas ligadas entre si: clientes, pedidos, itens do pedido, produtos, títulos. Cada tabela tem colunas definidas, e o banco garante as relações. Não existe item de pedido sem pedido, nem título apontando para um cliente que foi apagado.

Transação: tudo ou nada

O ponto central é a transação. Pense na baixa de um pedido faturado: o sistema precisa reduzir o estoque, gerar o título a receber, registrar a nota e atualizar o status do pedido. São quatro gravações. Se essas gravações estiverem na mesma transação e a energia cair entre a segunda e a terceira, o banco relacional desfaz as duas primeiras. O estoque não fica baixado sem título correspondente.

Esse comportamento tem nome técnico (propriedades ACID: atomicidade, consistência, isolamento e durabilidade), mas o efeito prático é simples: ou a operação inteira aconteceu, ou nada aconteceu. É isso que permite fechar o mês sem caçar diferença.

Concorrência: a última unidade

Dois vendedores, em lojas diferentes, tentam vender a última unidade de um produto no mesmo segundo. Um banco relacional bem usado garante que só uma venda passa, e a outra recebe o aviso de saldo insuficiente. O mesmo vale para baixa de títulos, uso de limite de crédito e reserva de agenda.

Regras que o próprio banco protege

O relacional permite declarar regras que valem independentemente de quem grava: CNPJ único por cadastro, quantidade que não pode ser negativa, pedido que só existe ligado a um cliente. Se um integrador ou um script de importação tentar gravar algo inválido, o banco recusa. Isso protege o dado mesmo quando o código tem falhas.

O que o relacional cobra

Ele tem limites, e é bom conhecê-los:

• Mudança de estrutura precisa de cuidado. Incluir colunas e tabelas é rotina, mas exige uma migração planejada, testada e versionada junto com o código.
• Atributos muito variados ficam desajeitados. Um catálogo em que cada categoria de produto tem campos diferentes pede uma modelagem mais elaborada. Bancos relacionais modernos, como o PostgreSQL, aceitam colunas em formato JSON para esses casos, o que resolve boa parte do problema sem sair do relacional.
• Volume muito alto de escrita contínua (milhões de eventos chegando o tempo todo) pode pressionar o banco principal, e aí vale separar esse fluxo.

Para uma empresa pequena ou média, esses limites raramente são o gargalo real. Quando o sistema fica lento, a causa mais comum é consulta mal escrita, índice faltando ou tela que carrega dados demais, não o tipo de banco. Antes de culpar a tecnologia, faça um diagnóstico de performance.

NoSQL: quando faz sentido

NoSQL não é uma tecnologia, é um nome guarda-chuva para bancos que não seguem o modelo de tabelas relacionadas. Eles nasceram para resolver problemas específicos: volume enorme, estrutura muito variável, necessidade de distribuir dados entre muitos servidores.

Em troca dessa flexibilidade, muitos deles abrem mão de parte das garantias do relacional, ou as oferecem de forma mais limitada. Alguns bancos de documentos, como o MongoDB, passaram a aceitar transações com várias gravações, mas o modelo de dados continua pensado para registros independentes, e regras como "todo título aponta para um cliente existente" ficam a cargo do código, não do banco. Alguns trabalham com consistência eventual: depois de uma gravação, leituras feitas logo em seguida podem ainda mostrar o valor antigo por um intervalo curto. Para um contador de visualizações, isso não importa. Para o saldo de um cliente, importa muito.

NoSQL faz sentido quando a parte do sistema em questão tem estas características:

• o dado tem formato muito variável e é lido quase sempre inteiro, de uma vez;
• o volume de escrita é alto e contínuo, e perder ordem exata ou ter atraso curto é aceitável;
• a operação é simples (gravar e buscar por uma chave), sem cruzamentos complexos;
• o dado pode ser reconstruído a partir de outra fonte, como um cache.

Se a parte do sistema movimenta dinheiro, estoque ou obrigação fiscal, nenhuma dessas características costuma valer. Por isso o relacional segue como base dos sistemas de gestão.

Documentos, chave-valor, séries temporais e busca

Os principais tipos de NoSQL, com o lugar onde cada um costuma ajudar numa empresa:

Alguns exemplos concretos:

• Indústria com máquinas conectadas. As leituras de temperatura e vibração chegam a cada poucos segundos. Um banco de séries temporais guarda esse fluxo; o relacional guarda a ordem de produção, o apontamento e o estoque.
• Distribuidora com catálogo grande. O cadastro oficial do produto (código, NCM, preço, estoque) mora no relacional. Uma cópia indexada num motor de busca atende a pesquisa rápida no portal do cliente.
• Aplicativo com muitos acessos simultâneos. Sessões de login e dados de consulta frequente ficam em cache chave-valor, aliviando o banco principal.

Usar os dois no mesmo sistema

Na prática, a melhor arquitetura para muitas empresas é um banco relacional como fonte oficial, com componentes NoSQL ao redor para funções específicas. Isso tem nome técnico (persistência poliglota), mas a ideia é a do mapa de responsabilidades: cada tipo de dado mora onde é tratado melhor.

Três cuidados tornam essa combinação segura:

1. Uma fonte da verdade por dado. O estoque oficial está no relacional. O índice de busca é cópia; se divergir, o relacional ganha e a cópia é reconstruída.
2. Sincronização desenhada, não improvisada. Como a cópia é atualizada, com que atraso aceitável e o que acontece se a atualização falhar precisam estar definidos antes do código.
3. Começar simples. Cada banco adicional é mais uma peça para monitorar, atualizar, fazer backup e conhecer. Só acrescente quando houver um problema concreto que o relacional, bem usado, não resolve.

O erro oposto também acontece: escolher um banco de documentos como base de tudo porque ele acelera o início do projeto. A agilidade dos primeiros meses vira custo quando surgem as necessidades de consistência entre pedidos, estoque e financeiro, e o código passa a reimplementar à mão garantias que o relacional entregaria prontas. Em apps, é o dilema de Firebase ou back-end próprio.

Relatórios e BI conforme a escolha

Relatório gerencial é cruzamento: vendas por vendedor, por região, por mês, comparadas com a meta e com o mesmo período do ano anterior. O relacional, com SQL, foi feito para isso. Ferramentas de BI conectam nele diretamente, e qualquer analista de dados sabe consultá-lo.

Bancos de documentos e chave-valor são otimizados para buscar um registro inteiro rapidamente, não para cruzar milhões deles. Relatórios em cima deles costumam exigir exportação, transformação e uma estrutura intermediária, o que aumenta o trabalho e o atraso das informações.

Mesmo no relacional, há um limite saudável: consultas pesadas de BI rodando no mesmo banco que atende o caixa e a expedição disputam recursos com a operação. Quando a empresa cresce e passa a cruzar dados de vários sistemas (ERP, CRM, e-commerce, planilhas), o caminho é levar esses dados para uma base analítica separada. Explicamos quando isso compensa em data warehouse para empresas médias.

Critérios de decisão: perguntas para o time técnico

Leve estas perguntas para a próxima reunião com o fornecedor ou com a equipe interna. As respostas mostram se a escolha foi pensada para o negócio ou para a preferência de quem desenvolve.

1. Quais operações do sistema mexem com dinheiro, estoque ou obrigação fiscal? Onde elas ficam gravadas, e como o banco garante que não ficam pela metade?
2. O que acontece se dois usuários alterarem o mesmo registro ao mesmo tempo? A resposta precisa ser concreta, com um exemplo do seu negócio.
3. Por que esse banco e não um relacional? Se a proposta é NoSQL como base, qual problema real ele resolve que o relacional não resolveria?
4. Como serão feitos os relatórios gerenciais? Direto no banco, numa cópia ou numa base analítica?
5. Como mudanças de estrutura serão feitas e versionadas? Existe processo de migração testado antes de ir para produção?
6. Qual é a rotina de backup e quanto tempo leva uma restauração? Já foi testada?
7. Onde o banco vai rodar? Serviço gerenciado na nuvem, servidor próprio, região de hospedagem. Isso afeta disponibilidade, manutenção e o tratamento de dados pessoais exigido pela LGPD.
8. Quantos profissionais no mercado dominam essa tecnologia? Se o fornecedor sair, a empresa encontra quem mantenha?
9. O dado é da empresa? Existe forma documentada de exportar tudo, em formato aberto, se for preciso trocar de sistema?

Sinais de alerta nas respostas:

• "NoSQL escala mais" sem dizer qual volume a empresa tem hoje e qual espera ter.
• "Não precisa de estrutura definida, o banco aceita qualquer coisa", dito sobre pedidos ou lançamentos financeiros.
• Ausência de resposta clara sobre backup e restauração.
• Vários bancos diferentes no desenho inicial de um sistema que ainda nem entrou em produção.
• Proposta de trocar de banco para resolver lentidão, sem diagnóstico que mostre a causa.

Perguntas frequentes

Qual a diferença entre SQL e NoSQL?

A diferença principal está na forma de guardar os dados. Bancos SQL, ou relacionais, organizam tudo em tabelas ligadas entre si e garantem transações completas. Bancos NoSQL usam outros formatos, como documentos, chave-valor ou séries temporais, e costumam trocar parte dessas garantias por flexibilidade de estrutura ou por volume muito alto de escrita.

NoSQL é mais rápido que banco relacional?

Depende da operação. Para gravar e buscar um registro por chave em volume muito alto, um banco NoSQL pode ser mais eficiente. Para cruzar vendas, estoque e financeiro em relatórios, o banco relacional tende a ser mais adequado. Em empresas pequenas e médias, lentidão costuma vir de consulta mal escrita ou índice faltando, não do tipo de banco.

MongoDB serve para sistema de gestão (ERP)?

Como base de um sistema de gestão, geralmente não é a melhor escolha. O MongoDB aceita transações com várias gravações, mas o modelo pensa em registros independentes, e regras como "todo título aponta para um cliente existente" ficam por conta do código. Ele funciona bem como complemento, por exemplo para catálogo com atributos muito variados.

Banco relacional consegue guardar dados em JSON?

Sim. Bancos relacionais modernos, como o PostgreSQL, aceitam colunas em formato JSON. Isso resolve boa parte dos casos de atributos variados, como um catálogo em que cada categoria de produto tem campos diferentes, sem abrir mão das transações e das regras de integridade que protegem pedidos, estoque e financeiro no mesmo banco.

Trocar de banco de dados depois é muito difícil?

Sim, o banco de dados é a parte do sistema mais difícil de trocar. O código pode ser reescrito por módulos, mas os dados acumulados em anos de operação carregam regras embutidas na forma como foram gravados. Por isso a escolha merece análise no início do projeto, com base no tipo de dado e de operação do negócio.

Como a Pervian Tech trabalha bancos de dados

Na Pervian Tech, a escolha do banco faz parte do trabalho de arquitetura de software e começa pelo negócio, não pela ferramenta. Primeiro mapeamos quais dados o sistema vai guardar, quais operações movimentam dinheiro e estoque, que volume existe hoje e quais relatórios a gestão precisa. A partir disso definimos o banco principal, quase sempre relacional, e só acrescentamos outros componentes quando há um problema concreto para eles resolverem.

Em sistemas que já existem, o ponto de partida é o diagnóstico: como o dado está modelado, onde estão as inconsistências, o que está deixando as consultas lentas e se a estrutura atual aguenta o crescimento planejado. Muitas vezes o caminho é ajustar a modelagem e os índices, não trocar de tecnologia. Mais textos sobre decisões desse tipo estão na categoria engenharia.

Cada projeto é sob medida, e o investimento é definido sob consulta, depois de um diagnóstico inicial gratuito. Se a escolha do banco está em discussão no seu próximo sistema, ou se os números do sistema atual não batem, conte o que está acontecendo.