- Por que essa decisão importa mais do que parece
- Quando o banco relacional é a escolha certa
- Sinais de alerta: você pode ter escolhido errado
- Cenários reais onde NoSQL resolve melhor
- Guia prático por categoria de NoSQL
- O erro mais comum ao migrar para NoSQL
- Usando SQL e NoSQL juntos: polyglot persistence
- FAQ
- Checklist de decisão
Por que essa decisão importa mais do que parece
Todo projeto começa igual: PostgreSQL, migrations, schemas bem definidos, foreign keys no lugar certo. Funciona. Por meses, funciona muito bem.
Depois vem o crescimento. Novas features, novas colunas, tabela user_metadata com 40 campos onde metade é NULL. A query que respondia em 40ms começa a dar timeout. Você adiciona índice. Mais um índice. Particionamento. View materializada. E em algum momento alguém pergunta em voz alta o que todo mundo está pensando em silêncio: será que o banco certo é esse?
Essa pergunta, feita tarde demais, custa caro. Migração de banco em produção é cirurgia com o paciente acordado — possível, mas dolorosa e arriscada.
A decisão entre SQL e NoSQL não é sobre tecnologia favorita. É sobre qual modelo de dados reflete como o seu sistema realmente lê e escreve informação. Errar aqui no início não quebra o projeto — mas cobra o preço com juros quando você já tem usuários reais dependendo do sistema.
Quando o banco relacional é a escolha certa
Antes de falar em NoSQL, é importante entender onde o modelo relacional é genuinamente superior — não por hábito, mas por design.
Consistência transacional (ACID)
Se duas operações precisam acontecer juntas ou não acontecer de forma alguma, o banco relacional é insubstituível. Débito e crédito em conta bancária. Reserva de estoque e criação de pedido. Qualquer fluxo onde uma operação parcialmente concluída gera inconsistência de negócio.
O ACID (Atomicidade, Consistência, Isolamento, Durabilidade) do PostgreSQL não é burocracia — é uma garantia real que salva sistemas financeiros de bugs impossíveis de reproduzir.
NoSQL moderno implementa transações (MongoDB desde 4.0, por exemplo), mas com trade-offs de performance e complexidade que raramente compensam quando o banco relacional já resolve o problema.
Dados com relações fortes e bem definidas
Clientes têm pedidos. Pedidos têm itens. Itens têm produtos. Produtos têm fornecedores. Quando as entidades do domínio têm relacionamentos estáveis, bem mapeados e consultados de formas variadas, o modelo relacional brilha. JOINs existem exatamente para isso — e fazem isso bem.
Queries analíticas imprevisíveis
Relatórios gerenciais, dashboards de BI, cruzamentos ad hoc entre entidades — SQL ainda vence em legibilidade e flexibilidade para consultas que você não consegue prever em tempo de design. Um analista de negócio escrevendo SQL diretamente é muito mais produtivo do que um desenvolvedor traduzindo cada necessidade para queries de document store.
Se o seu sistema se encaixa nesse perfil, PostgreSQL é a escolha certa. Não existe prêmio por usar tecnologia mais nova.
Sinais de alerta: você pode ter escolhido errado
Esses sinais raramente aparecem em desenvolvimento local. Surgem em produção, com volume real, quando já tem custo de migração envolvido.
Schema que cresce sem controle. A tabela tem 40 colunas. Toda nova feature adiciona mais uma coluna opcional. Metade dos campos é NULL para a maioria dos registros. Isso não é produto evoluindo — é dado semi-estruturado sendo forçado em um modelo que não foi feito para ele.
JOINs em cascata para montar um único objeto. Se retornar o perfil completo de um usuário exige 6 JOINs entre tabelas que sempre são lidas juntas, esse "objeto" provavelmente deveria ser armazenado como documento. O JOIN está compensando uma decisão de modelagem, não expressando uma relação real.
Escrita massiva de dados que não se relacionam. Logs de acesso, eventos de analytics, métricas de telemetria, registros de auditoria — dados que chegam em volume alto, são escritos uma vez e raramente atualizados. Armazenar isso em tabela relacional é usar a ferramenta errada para o problema.
Necessidade real de escala horizontal. PostgreSQL escala verticalmente muito bem. Sharding horizontal é possível com Citus ou particionamento nativo, mas adiciona complexidade operacional significativa. Se a natureza do produto exige distribuição entre múltiplos nós desde o início, alguns modelos de NoSQL oferecem isso como primeiro cidadão, não como extensão.
⚠️ Ponto de atenção: Um schema descontrolado não é sinal de produto evoluindo organicamente. É sinal de modelo de dados errado desde o início. Quanto mais tarde essa percepção chega, mais cara fica a correção.
Cenários reais onde NoSQL resolve melhor
"NoSQL é melhor" não é uma afirmação completa. A versão completa é: NoSQL é melhor para problemas específicos. Aqui estão os casos onde a escolha faz diferença real.
Catálogos com atributos variáveis por tipo de produto
Um e-commerce que vende eletrônicos, roupas e alimentos tem um problema estrutural no modelo relacional: cada categoria tem atributos completamente diferentes e incompatíveis.
No modelo relacional, as saídas são duas — e as duas são ruins:
- Tabela única com colunas opcionais: resulta em dezenas de campos NULL, schema impossível de manter, queries confusas.
- EAV (Entity-Attribute-Value): armazena atributos como linhas em vez de colunas. Funciona em teoria, vira pesadelo em queries, performance e manutenção.
Com MongoDB, cada produto é um documento autocontido com a estrutura que faz sentido para aquele tipo:
{
"_id": "prod_001",
"nome": "Notebook Pro 15",
"categoria": "eletronico",
"preco": 4599.90,
"specs": {
"processador": "Intel i7-13th",
"ram": "16GB DDR5",
"armazenamento": "512GB NVMe",
"tela": "15.6\" FHD IPS 144Hz"
}
}
{
"_id": "prod_002",
"nome": "Camiseta Dry-Fit",
"categoria": "vestuario",
"preco": 89.90,
"variantes": [
{ "cor": "preto", "tamanhos": ["P", "M", "G", "GG"], "estoque": [12, 8, 5, 2] },
{ "cor": "branco", "tamanhos": ["P", "M", "G"], "estoque": [6, 0, 3] }
],
"composicao": "88% poliéster, 12% elastano"
}
Sem ALTER TABLE. Sem migrations para cada nova categoria. O schema evolui junto com o produto.
Dados de série temporal e eventos de alta frequência
Logs de acesso, eventos de analytics, métricas de infraestrutura, registros de auditoria — esse tipo de dado tem características específicas: chega em volume alto, é imutável após a escrita e é consultado principalmente por intervalo de tempo ou por usuário/entidade.
Tentar armazenar esse volume em PostgreSQL funciona até certo ponto. Depois vem o sofrimento: particionamento manual por data, jobs de arquivamento, índices parciais, vacuum agressivo. É possível — mas é manutenção constante que não agrega valor ao produto.
O Cassandra foi construído exatamente para esse padrão. O schema é definido pela query que você vai fazer, não pelo dado em si:
-- Cassandra: schema orientado ao padrão de acesso
CREATE TABLE eventos_usuario (
usuario_id UUID,
ocorrido_em TIMESTAMP,
tipo_evento TEXT,
payload TEXT,
PRIMARY KEY (usuario_id, ocorrido_em)
) WITH CLUSTERING ORDER BY (ocorrido_em DESC)
AND default_time_to_live = 7776000; -- TTL de 90 dias automático
Escrita distribuída, compressão eficiente, expiração automática por TTL — sem um job de limpeza manual rodando toda madrugada.
Grafos de relacionamento entre entidades
Redes sociais, sistemas de recomendação baseados em comportamento, detecção de fraude por padrão de conexão — quando o que importa não é o dado em si, mas a relação entre os dados, bancos de grafo como Neo4j tornam a pergunta natural.
"Quais produtos compraram juntos usuários que também compraram o produto X?" é uma query de recomendação que em SQL exige JOINs recursivos complexos. Em Cypher (linguagem do Neo4j), é uma frase quase em linguagem natural.
Guia prático por categoria de NoSQL
NoSQL não é uma categoria única — é um guarda-chuva para modelos de dados que não são relacionais. Cada categoria resolve um problema diferente.
| Categoria | Exemplos | Use quando |
|---|---|---|
| Documento | MongoDB, CouchDB, Firestore | Dados semi-estruturados, schemas variáveis por tipo, catálogos, perfis de usuário |
| Chave-Valor | Redis, DynamoDB, Memcached | Cache, sessões, filas simples, dados com acesso direto por chave |
| Coluna Larga | Cassandra, HBase, ScyllaDB | Série temporal, logs, eventos de alta frequência, escrita massiva distribuída |
| Grafo | Neo4j, Amazon Neptune | Redes sociais, recomendações, detecção de fraude, hierarquias |
| Busca | Elasticsearch, OpenSearch | Full-text search, facets, autocomplete, analytics de log |
Sobre Redis: é um equívoco comum usar Redis como banco principal porque "é muito rápido". Redis é uma estrutura de dados em memória — excelente para cache, sessões, pub/sub e filas. Usar como fonte de verdade significa aceitar que os dados vivem na RAM (com persistência opcional e limitada), o que raramente é aceitável para dados de negócio críticos.
Sobre DynamoDB: brilha para acesso por chave primária com escala imprevisível e sem necessidade de operação. Para queries flexíveis com filtros variados, o modelo de acesso do DynamoDB cobra caro — tanto em complexidade de design quanto em custo financeiro de leitura de tabelas inteiras via scan.
O erro mais comum ao migrar para NoSQL
Esse padrão se repete: um time que trabalhou anos com PostgreSQL decide migrar para MongoDB. O resultado é um MongoDB com schema idêntico ao Postgres anterior — tabelas viram coleções, rows viram documentos, e os JOINs viram $lookup.
Funciona. Mas é mais lento, mais complexo e não aproveita nada do modelo de documentos.
O problema é transferir o instinto de normalização para um contexto onde ele trabalha contra você.
No PostgreSQL, você normaliza para evitar redundância. Faz sentido porque o banco garante integridade referencial e JOINs são eficientes para dados relacionados.
No MongoDB, você desnormaliza intencionalmente porque o documento deve ser autocontido para a leitura mais frequente. Dois roundtrips ao banco para montar um objeto simples é um problema de modelagem, não de performance de infra.
// Modelagem "normalizada" no MongoDB — o anti-padrão
// Coleção: pedidos
{ "_id": "ord_001", "usuario_id": "usr_abc", "total": 450.00 }
// Coleção: usuarios
{ "_id": "usr_abc", "nome": "Carlos Mendes", "email": "carlos@empresa.com" }
// Para exibir o pedido com nome do usuário: $lookup (JOIN disfarçado)
// Dois roundtrips ou pipeline de agregação desnecessário
// Modelagem orientada ao padrão de acesso — o caminho certo
{
"_id": "ord_001",
"total": 450.00,
"status": "aprovado",
"criado_em": "2026-05-06T14:30:00Z",
"usuario": {
"id": "usr_abc",
"nome": "Carlos Mendes",
"email": "carlos@empresa.com"
},
"itens": [
{
"produto_id": "prod_007",
"nome": "Teclado Mecânico TKL",
"quantidade": 1,
"preco_unitario": 450.00
}
]
}
O tradeoff é real: se o e-mail do usuário mudar, você atualiza N documentos de pedido. Mas se a leitura de pedido acontece mil vezes mais do que a atualização de e-mail do usuário, o tradeoff é matematicamente justificado.
💡 Regra prática para NoSQL orientado a documento: modele pelo padrão de acesso, não pela normalização. A pergunta não é "como organizo os dados?", mas "qual query vou fazer com mais frequência?" — e o schema deve responder essa pergunta de forma direta.
Usando SQL e NoSQL juntos: polyglot persistence
A pergunta não precisa ter resposta única. Em sistemas com domínios bem separados, usar bancos diferentes para problemas diferentes é uma arquitetura legítima e madura — chamada de polyglot persistence.
Um exemplo real de e-commerce de médio porte:
- PostgreSQL para pedidos, transações financeiras e inventário — onde ACID é inegociável
- MongoDB para catálogo de produtos — schemas variáveis por categoria sem migrations
- Redis para carrinho de compras, sessões de usuário e cache de preços calculados
- Elasticsearch para busca de produtos com autocomplete, filtros e ranking por relevância
- Cassandra para eventos de comportamento do usuário (visualizações, cliques, tempo na página)
Cada banco fazendo o que foi projetado para fazer. A complexidade operacional aumenta — mais infraestrutura para monitorar, mais backups para configurar, mais conexões para gerenciar. Em escala, esse custo operacional compensa. Em projetos pequenos, pode ser over-engineering.
A decisão de adicionar um banco novo ao stack precisa ser justificada pelo problema que resolve, não pela tecnologia que parece interessante.
FAQ
Posso usar SQL e NoSQL no mesmo projeto?
Sim, e é uma prática comum em sistemas que cresceram além do escopo inicial. O padrão tem nome — polyglot persistence — e faz sentido quando os domínios do sistema têm necessidades genuinamente diferentes. A decisão de adicionar um banco novo deve ser guiada por um problema concreto que o banco atual resolve mal, não por preferência tecnológica.
DynamoDB é sempre a escolha certa na AWS?
Não. DynamoDB é excelente para acesso por chave primária com escala imprevisível e sem overhead operacional. Se o sistema precisa de queries flexíveis, filtros variados ou padrões de acesso que mudam com frequência, RDS PostgreSQL na AWS costuma ser mais produtivo e previsível em custo. Muito time escolhe DynamoDB pelo "escala automático" e descobre tarde que o modelo de acesso rígido cobra caro em complexidade de design e custo de operações de scan.
NoSQL tem transações?
Depende do banco. MongoDB suporta transações multi-documento com ACID desde a versão 4.0. Cassandra tem lightweight transactions com trade-offs de latência. Redis tem MULTI/EXEC para operações atômicas. Nenhum deles chega na robustez transacional do PostgreSQL para fluxos complexos — e isso é uma escolha de design deliberada, não uma limitação técnica a ser contornada.
Como migrar de SQL para NoSQL em produção sem downtime?
A estratégia mais usada é dual-write: escrever nos dois bancos simultaneamente por um período de transição, validar consistência dos dados e depois migrar o tráfego de leitura gradualmente — começando com uma porcentagem pequena e aumentando conforme a confiança nos dados do novo banco cresce. Não existe caminho sem risco. Migração de banco é sempre uma operação delicada que exige monitoramento intensivo e rollback planejado.
Schema-less significa que posso guardar qualquer coisa sem pensar?
Não — e esse é um dos mal-entendidos mais perigosos sobre bancos de documento. Schema-less significa que o banco não impõe estrutura, mas você deve impor via código. Em times maiores, um MongoDB sem validação de schema vira uma coleção de formatos inconsistentes em semanas. Use JSON Schema validation no nível do banco ou validação na camada de aplicação (Mongoose, Joi, Zod). Liberdade sem disciplina é entropia.
Checklist de decisão antes de escolher o banco
Responda essas perguntas antes de abrir o pgAdmin ou o MongoDB Compass:
Vá de PostgreSQL se:
- Os dados têm relações fortes e bem definidas entre entidades
- Consistência transacional é requisito de negócio (financeiro, estoque, reservas)
- As queries analíticas são imprevisíveis ou variadas
- O time tem mais familiaridade com SQL e o prazo é curto
Considere NoSQL de documento (MongoDB) se:
- O schema varia significativamente por tipo de registro
- Os dados são consultados principalmente como objetos completos, raramente em partes
- Você precisa de iteração rápida no modelo de dados sem migrations custosas
Considere NoSQL de coluna larga (Cassandra, ScyllaDB) se:
- O volume de escrita é alto e constante
- Os dados têm padrão claro de acesso por chave + intervalo de tempo
- Escala horizontal é requisito desde o início
Considere Redis se:
- O caso de uso é cache, sessão ou fila — não banco principal
- Os dados têm vida curta ou podem ser regenerados
Considere Elasticsearch se:
- O caso de uso principal é busca textual com filtros e ranking
- Você precisa de facets, autocomplete ou análise de logs
Se ainda não tem certeza, começa com PostgreSQL. Não como decisão definitiva — como decisão reversível com menor custo de mudança no início. Mas monitore os sinais de alerta desde o primeiro dia: schema crescendo sem controle, JOINs em cascata para montar objetos simples, queries de leitura que ignoram relações. Esses sinais aparecem cedo se você prestar atenção.
A decisão certa não é a que usa a tecnologia mais sofisticada. É a que você vai conseguir manter, escalar e entender quando a produção travar às 2h da manhã.
