Banco relacional vs NoSQL: como escolher

A reunião de arquitetura durou duas horas. No final, alguém disse "vamos usar MongoDB porque é mais flexível" e todo mundo concordou sem discutir o que "flexível" significa nesse contexto. Seis meses depois, o time estava tentando fazer joins manuais na aplicação para um relatório que levaria dois segundos em SQL. Já vi esse filme algumas vezes.

A escolha entre banco relacional e NoSQL não é sobre qual tecnologia é mais moderna — é sobre entender o que o seu dado é e como você vai acessá-lo.

Quando usar banco relacional (SQL)

Banco relacional é a escolha certa na maioria dos sistemas de negócio. Se você tem dados com estrutura conhecida, relacionamentos entre entidades, e precisa de consistência transacional, um banco relacional resolve isso melhor do que qualquer alternativa.

Os casos clássicos onde SQL brilha:

• Dados financeiros: transferências, faturas, balanços. Você precisa de ACID — atomicidade, consistência, isolamento e durabilidade. Uma transferência bancária que debita numa conta e não credita na outra é um desastre. Isso é o problema que transações relacionais resolvem desde 1970.
• Sistemas com muitos relacionamentos: usuários têm pedidos, pedidos têm itens, itens têm produtos, produtos têm categorias. SQL foi desenhado para isso. JOINs são eficientes quando os índices estão corretos.
• Relatórios e analytics: GROUP BY, window functions, CTEs — o SQL para análise de dados é uma linguagem madura com décadas de otimização. Tentar replicar isso numa aplicação é reinventar a roda mal.
• Dados cujo schema vai evoluir de forma controlada: migrations com ALTER TABLE são previsíveis e auditáveis. Saber que o campo status só pode ter quatro valores possíveis porque existe uma constraint no banco é uma garantia que um documento JSON sem schema nunca vai te dar.

O PostgreSQL em particular faz parte de uma categoria própria. Tem suporte a JSONB com indexação GIN (você guarda documento JSON e ainda faz query eficiente nele), tipos customizados, full-text search, PostGIS para dados geoespaciais, e arrays de primeira classe. É difícil argumentar que você precisa de um banco NoSQL para "flexibilidade" quando o Postgres já tem isso embutido.

-- PostgreSQL com JSONB: você tem relacional e documento no mesmo lugar
CREATE TABLE eventos (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  tipo VARCHAR(50) NOT NULL,
  payload JSONB,
  criado_em TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

-- Index no campo dentro do JSON
CREATE INDEX ON eventos USING GIN (payload);

-- Query em campo JSON com performance decente
SELECT * FROM eventos WHERE payload->>'user_id' = '123';

Quando usar NoSQL

NoSQL não é uma categoria única — é um guarda-chuva que cobre tecnologias bastante diferentes com casos de uso distintos.

Document stores (MongoDB, Firestore, CouchDB)

Fazem sentido quando o dado é intrinsecamente variável e você vai acessá-lo quase sempre pelo documento inteiro, sem precisar cruzar com outros documentos.

Um catálogo de produtos é o exemplo canônico: um tênis tem campos que um laptop não tem (número, solado, tecnologia de amortecimento), e vice-versa. Schema fixo aqui é inconveniente real, não teórico. Um document store resolve isso bem.

O que não resolve bem: qualquer coisa que precise de joins. Quando você começa a embutir uma lista de pedidos dentro do documento do usuário para evitar joins, está empurrando a complexidade do banco para o código da aplicação. Isso funciona até o tamanho do documento crescer, até você precisar acessar pedidos sem o contexto do usuário, ou até precisar de um relatório de pedidos por período.

Key-value stores (Redis, DynamoDB, Memcached)

Redis é provavelmente o banco que você deveria ter em produção mas ainda não tem. Não como banco principal — como cache, filas, sessões, rate limiting, e pub/sub. O modelo de dados é simples por design: uma chave, um valor. O que faz do Redis absurdamente rápido (operações em sub-milissegundo) é exatamente o que o torna inadequado para queries complexas.

DynamoDB segue o mesmo princípio mas com persistência garantida e escala horizontal gerenciada pela AWS. O preço é um modelo de acesso mais rígido — você precisa saber suas access patterns antes de modelar a tabela, não depois.

Wide-column stores (Cassandra, HBase)

Cassandra existe para casos onde você precisa de escrita em volume absurdo com disponibilidade geográfica distribuída. Pensa em métricas de IoT, eventos de clickstream, logs de uso em escala de bilhões de registros. A Cassandra aceita escrita em múltiplos datacenters simultaneamente e reconcilia depois — o modelo é AP no CAP theorem, não CP.

O custo: sem joins, sem transações multi-linha, e você modela o schema em função das queries que vai fazer, não da estrutura dos dados. Se as queries mudam, o schema muda. É uma forma de pensar bem diferente do relacional.

Graph databases (Neo4j, Amazon Neptune)

Para dados onde o relacionamento entre entidades é a informação mais importante — redes sociais, sistemas de recomendação por conexões, grafos de dependência, detecção de fraude. SQL pode modelar grafos com tabelas de adjacência, mas queries de "amigos de amigos de amigos" em SQL são progressivamente piores. Uma graph database resolve travessia de grafo por design.

Os tradeoffs que ninguém conta na apresentação de vendas

Consistência eventual: a maioria dos bancos NoSQL distribuídos sacrifica consistência forte por disponibilidade e tolerância a partição. Você pode escrever num nó e ler um valor desatualizado em outro por alguns milissegundos ou segundos. Para um like no Instagram, isso é aceitável. Para um saldo bancário, não é.

Sem schema = responsabilidade na aplicação: ausência de schema no banco não significa ausência de schema — significa que o schema mora na aplicação, distribuído entre os lugares que escrevem e leem dados. Quando o formato muda, você tem documentos antigos com formato A e novos com formato B convivendo na mesma collection. A aplicação precisa lidar com os dois. Migrations controladas num banco relacional existem para evitar exatamente isso.

Operações atômicas entre documentos: muitos document stores só garantem atomicidade dentro de um único documento. Mover um item entre duas collections de forma atômica pode ser impossível ou requerer transações multi-documento com performance pior que SQL.

Escala horizontal é um argumento para poucos: a maioria dos sistemas de negócio nunca vai precisar distribuir dados em múltiplos shards. PostgreSQL escala verticalmente até dezenas de terabytes com réplicas de leitura e connection pooling. Se você não está num problema de escala que o Postgres não resolve, adicionar um banco distribuído é complexidade sem ganho real.

A regra que eu uso

Minha heurística pessoal: começa com PostgreSQL. Se aparecer um caso de uso onde um banco especializado faz sentido — Redis para cache, Elasticsearch para full-text search, Cassandra para series temporais em volume industrial — adiciona esse banco para aquele caso específico. Não substitui o relacional: complementa.

A maioria das aplicações de negócio, mesmo as que escalam bem, funciona melhor com um banco relacional bem modelado do que com um banco NoSQL mal modelado. O problema quase nunca é o banco — é a modelagem e os índices.

Para escrever e validar queries SQL durante o processo de modelagem, uso o SQL Formatter para manter consistência na formatação quando as queries começam a ficar longas — especialmente CTEs e subqueries que precisam ser legíveis para o próximo dev.

Perguntas frequentes

MongoDB é mais rápido que PostgreSQL?

Depende do workload. MongoDB pode ser mais rápido para leitura de documentos inteiros sem joins. PostgreSQL é mais rápido para queries analíticas, joins com índices corretos, e escrita transacional. Benchmarks genéricos não dizem nada — o que importa é o seu padrão de acesso específico. O mito de que NoSQL é "mais rápido" vem de comparações que favorecem document retrieval e ignoram casos de uso relacionais.

Posso usar PostgreSQL como banco de documentos?

Sim, e com frequência é uma boa decisão. O tipo JSONB do PostgreSQL armazena documentos com indexação GIN e suporte a queries dentro do JSON. Você ganha schema flexível onde precisa e schema rígido onde precisa, no mesmo banco, com transações. Para a maioria dos casos que as pessoas citam como razão para usar MongoDB, o PostgreSQL com JSONB resolve — sem trocar o banco principal.

DynamoDB ou RDS para um novo projeto na AWS?

Para a maioria dos projetos novos, RDS (PostgreSQL ou Aurora) é a escolha mais segura. DynamoDB faz sentido quando você conhece muito bem seus access patterns de antemão, precisa de escala horizontal gerenciada, e está disposto a aceitar as limitações do modelo de dados. Se ainda está descobrindo como os dados serão acessados — o que é verdade para a maioria dos projetos no começo — DynamoDB vai te prender em decisões de modelagem que são difíceis de reverter.

Quando faz sentido misturar SQL e NoSQL no mesmo sistema?

Quando as necessidades realmente divergem. Um e-commerce pode usar PostgreSQL para pedidos, pagamentos e estoque (ACID obrigatório) e Redis para sessões e carrinho (velocidade, TTL automático, sem necessidade de persistência durável). O problema é quando a mistura acontece por modismo — dois bancos têm custo operacional: dois monitoramentos, dois backups, dois sets de expertise. Só adiciona se o ganho for real e mensurável.

SQL como default, NoSQL quando faz sentido

A decisão de banco é irreversível a curto prazo. Migrar de MongoDB para PostgreSQL com dados em produção é um projeto de meses. Começar com PostgreSQL e perceber que precisa de Redis para cache é um sprint. O conservadorismo aqui é uma vantagem — você adiciona complexidade quando o problema aparecer de verdade, não na reunião de arquitetura onde todo mundo está entusiasmado com a tecnologia nova.

NoSQL resolve problemas reais. Cassandra em escala de IoT, Redis para sessões, Elasticsearch para busca full-text — essas são ferramentas certas para casos específicos. O erro é usar NoSQL como padrão porque parece mais moderno, e descobrir depois que os relacionamentos do seu negócio se encaixavam melhor num modelo relacional o tempo todo.