O que acontece quando você para de insistir em tabelas
A primeira coisa que precisa entender sobre bancos de dados nao relacionais é que eles não são uma resposta para tudo. Eu vi muita equipe migrar do PostgreSQL para o MongoDB achando que ia resolver problemas de performance, e no final gastaram o dobro de tempo reconstruindo queries que antes funcionavam em segundos. O ponto de partida certo é simplesmente observar onde seu modelo relacional está travando. Quando eu comecei a trabalhar com schemas que cresciam de forma imprevisível — campos novos aparecendo todo mês, aninhamento de dados que não cabia em normalização sem criar dezenas de joins, leituras massivas que dilaceravam o JOIN da vida inteira — a tentação era ir direto para um documento. Mas antes disso, precisei mapear exatamente qual padrão de acesso estava destruindo meu banco. Leitura pesada? Escrita distribuída? Ambos?
Tipos práticos de bancos de dados nao relacionais
Documentos: o mais comum, exemplos são MongoDB e Couchbase. Você guarda um JSON grande por registro. Funciona bem quando os dados já vêm naturalmente aninhados, como perfis de usuário com histórico de compras, endereços múltiplos e preferências salvas em um único objeto. Chave-valor: Redis e DynamoDB na configuração mais simples. Estrutura literal de dictionary. Quando você só precisa recuperar algo por ID e tudo que importa cabe em um payload único, isso é praticamente insuperável em velocidade. Requisições em sub-milissegundo são realidade, não promessa.
Colunar: Cassandra e ScyllaDB. Dados organizados por colunas em vez de linhas. Excelente para escritas massivas e análises agregadas em escala. Se seu volume diário ultrapassa milhões de inserts, esse costuma ser o caminho. Grafo: Neo4j e JanusGraph. Nós e arestas com relações explícitas. Perde feio em performance de leitura quando você precisa seguir múltiplas conexões em sistemas tradicionais. Em sistemas de recomendação ou detecção de fraude, onde a relação é o dado principal, é imbatível.
Tudo isso existe porque cada um resolve um problema específico que o SQL não cobre economicamente. A armadilha é achar que qualquer um substitui o outro. Eu já vi gente colocar Redis como camada de persistência principal e chamar de solução. Isso não funciona na prática.
Como escolher o banco certo na prática
A decisão começa com um inventário frio dos seus acessos. Anote quantas leituras e escritas você faz por segundo. Identifique quais queries mais pesadas existem no seu sistema atual. Quantos joins elas carregam? Qual a latência média de resposta? Se você não tem métricas, implemente log de query lenta por duas semanas antes de decidir qualquer coisa. Eu fiz isso numa migração há alguns anos. Minha aplicação tinha uma API que respondia em 800ms porque uma query de relatório fazia cinco joins com tabelas de milhões de linhas. Parei, coletei os dados por quinze dias e identifiquei que trinta por cento das requisições eram leituras idênticas que nunca mudavam. A solução não foi migrar para um documento. Foi colocar Redis na frente daquele endpoint específico, com TTL de dois minutos. Tempo de resposta caiu de 800ms para 12ms. Custo de infraestrutura praticamente não mudou.
Se mesmo assim a soluçãocache não dá conta, aí sim entra a decisão entre os tipos. Para dados com estrutura flexível que evoluem rápido, documentos são seguros. Quando cada entidade já vem com um identificador único e você nunca precisa fazer filtro complexo por atributos internos, chave-valor resolve. Se o trabalho é ingestão de série temporal ou logs em escala industrial, coluna é a escolha. Quando a complexidade real está nas conexões entre entidades, grafo domina.
Implementação básica com MongoDB
Vamos ao que realmente importa: colocar para rodar. Supondo que você tenha Node.js instalado, a instalação do MongoDB num container Docker é direta: baixe a imagem oficial com docker pull mongo, levante um container com docker run --name mongo-dev -p 27017:27017 -d mongo, e conecte usando o driver nativo do projeto. A conexão básica com mongoose ou com o driver oficial pede apenas a URI mongodb://localhost:27017/nome-do-banco.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Criar uma coleção é implícito. Você não define esquema antes. Insert um documento e a coleção nasce. Isso parece liberdade, mas é exatamente o oposto. Sem validação de schema, eu já perdi horas rastreando bugs causados por campos com tipos inconsistentes vindos de serviços diferentes. A solução que adotei foi ativar o validador do MongoDB com um JSON Schema mínimo definindo campos obrigatórios e tipos aceitos. Isso te dá segurança sem abrir mão da flexibilidade que motivou a migração. Indexação é onde a maioria erra. Indexar tudo é armadilha. Cada índice custa escrita e memória. Eu passei por um caso em que uma coleção com dois milhões de documentos ficou impossível de manter porque tínhamos quarenta índices criados por curiosidade. O tempo de insert disparou de 2ms para 45ms. Removi os índices órfãos e fiquei apenas com os índices compostos das queries que realmente apareciam nos logs. Voltou a 3ms.
Problemas reais que documentação não conta
Um deles é a falta de transações multi-documento em versões antigas. Antes do MongoDB 4.2, transações entre vários documentos em shards diferentes simplesmente não existiam. Eu tive um problema concreto onde uma operação precisava atualizar o saldo de uma conta e registrar o movimento em outra coleção. Em versão anterior ao 4.2, a única saída foi implementar um padrão de compensação manual com retry e log de reversão. Demorou três dias para fazer direito e ainda assim tivemos uma janela de inconsistência de vinte e dois minutos num cenário de teste de carga. Outro problema é consistência eventual em replica sets. Se você lê logo após escrever em um cluster com weak consistency, pode não ver o dado que acabou de gravar. Eu configurei o driver com readPreference secondary e writeConcern majoritária sem entender o impacto. Em carga alta, leituras voltavam com dados desatualizados e minha interface exibia saldos errados por cerca de meio segundo. Mudei para readPreference primary e ajuste fino no writeConcern. Problema resolvedefinitivamente.
Escalabilidade horizontal também tem limitação prática. Sharding exige uma key de shard bem escolhida. Se você escolher mal, os dados ficam desbalanceados e um shard acumula tudo enquanto os outros ficam parados. Eu vi um cluster com doze shards onde oito deles tinham menos de cinco por cento dos dados porque a key de shard era um campo com baixa cardinalidade. A solução foi reavaliar a estratégia de sharding, escolher uma key com distribuição uniforme e rodar um resharding controlado. Levou quatro horas e uma janela de manutenção de seis horas. Nada gratificante, mas necessário.
Quando não usar bancos de dados nao relacionais
Se seu sistema depende pesadamente de relacionamentos complexos com integridade referencial estrita, mantenha o relacional. Transações ACID completas, foreign keys, constraints que impedem dados inconsistentes — nada nesses bancos oferece o mesmo nível de garantia sem esforço extra significativo. Se sua equipe não tem expertise em operar infraestrutura distribuída, pense duas vezes. Monitoring, backup, recovery, tuning de índices, gestão de shards — tudo isso exige conhecimento específico que não vem com o banco. Eu já vi equipes pequenas tentarem administrar um cluster Cassandra sem ninguém que soubesse o básico de gossip protocol e token allocation. O resultado foi um cluster instável que/caía em loops de recovery por semanas.
Hiperescala com writes intensos também não é sinônimo de escolha automática. Às vezes um PostgreSQL bem indexado com partições e connection pooling resolve o mesmo problema com metade da complexidade operacional. A escalabilidade vertical do Postgres ainda é real, e com CTEs, índices gin e materialized views você chega longe sem sair do relational.
Custo operacional que ninguém menciona
Bancos não relacionais costumam ser mais caros em operação do que em aquisição. MongoDB Atlas, DynamoDB com provisionamento, Cassandra gerenciada — os preços sobem rápido quando o volume cresce. Eu fiz um cálculo numa ocasião em que o custo mensal de um DynamoDB com capacidade sob demanda para uma workload específica saía por quinhentos dólares. O mesmo cenário em Postgres rodando em máquina dedicada de quatro núcleos e sessenta gigas de RAM custava cento e vinte dólares. A diferença não era insignificante e crescia linearmente com o tráfego. O segredo é combinar bancos quando necessário. Não há vergonha em ter Postgres para transações financeiras e Redis para cache de sessão. O sistema fica mais complexo de manter, mas cada componente faz o que faz melhor. Arquitetura poliglota não é buzzword. É decisão prática.
Se você está começando agora e quer praticar, o MongoDB Atlas oferece tier gratuito permanente com espaço suficiente para desenvolvimento. Redis também tem cache gratuito na nuvem. Cassandra exige mais configuração, então para aprendizado inicial foque em MongoDB ou Redis primeiro. A curva de aprendizado é menor e a documentação é mais acessível. O que mais importa é não tratar esses bancos como solução mágica. Eles resolvem problemas específicos. Conheça o problema antes de escolher a ferramenta. O resto vem depois.
