A escolha do banco de dados é uma das decisões mais duradouras de um sistema. Linguagem você troca com esforço, framework você troca com dor, banco de dados você troca com projeto, prazo e risco. E, no entanto, é frequentemente a decisão tomada com menos critério — por familiaridade, por moda ou porque alguém leu um comparativo de benchmark que não se parece nada com a carga real.
O critério que funciona é outro: o formato do dado e o padrão de acesso mandam na escolha. Não o contrário.
As perguntas que decidem antes de qualquer nome
Antes de comparar produtos, responda cinco coisas sobre o seu dado:
- Ele tem estrutura estável? Os campos são conhecidos e mudam devagar, ou cada registro pode ter forma diferente?
- As relações importam? Você precisa cruzar entidades com frequência, ou cada registro é consultado sozinho?
- Como ele é lido? Por chave exata, por filtro complexo, por faixa de tempo, por texto livre?
- Qual o volume e a taxa de escrita? Milhares de registros por dia ou milhões por hora?
- Consistência imediata é requisito? Ler o valor desatualizado por dois segundos é problema de negócio ou não é?
Quem responde essas cinco perguntas com honestidade já eliminou metade das opções. Quem não responde vai escolher pelo que estava em alta no ano passado.
Relacional: o padrão, e por bons motivos
Bancos relacionais — PostgreSQL, MySQL/MariaDB — guardam dados em tabelas com esquema definido e sabem cruzar essas tabelas com eficiência. Garantem transações com as propriedades que evitam dado inconsistente: ou tudo acontece, ou nada acontece.
Ganham quando: há relações entre entidades, integridade importa, consultas variam bastante e o esquema é razoavelmente estável. Sistemas financeiros, ERPs, e-commerce, qualquer coisa que envolva dinheiro ou obrigação legal.
Doem quando: o esquema muda a cada semana com campos imprevisíveis, ou quando a escrita passa de um volume que um servidor só não segura e o particionamento horizontal vira necessidade.
O ponto que quase ninguém diz em voz alta: o PostgreSQL moderno cobre boa parte dos casos que motivaram gente a sair do relacional. Ele guarda documento JSON com índice, faz busca textual razoável, tem extensão para série temporal e para dado geoespacial. Antes de adicionar um segundo banco ao ambiente, verifique se o que você já tem não resolve — um banco a mais é mais backup, mais monitoramento, mais gente que precisa saber operar.
Comece aqui, salvo motivo claro para não começar.
Documento: flexibilidade de esquema com custo escondido
Bancos de documento — MongoDB à frente — guardam registros semiestruturados, cada um podendo ter sua forma. A leitura de um documento inteiro por chave é muito rápida, porque tudo que pertence àquela entidade está fisicamente junto.
Ganham quando: o dado é naturalmente aninhado e lido inteiro (catálogo de produto com atributos variáveis, perfil de usuário, conteúdo editorial), o esquema evolui rápido, e o sistema precisa distribuir a escrita por vários nós desde cedo.
Doem quando: você precisa cruzar coleções com frequência. Fazer o equivalente a uma junção do lado da aplicação é lento, propenso a erro e cresce mal. Se as suas consultas cruzam entidades o tempo todo, o dado é relacional e o banco vai avisar isso da pior forma possível: em produção, com carga.
A armadilha real do documento não é técnica, é disciplina. "Esquema flexível" vira "nenhum esquema" com muita facilidade, e três anos depois a coleção tem quatro formatos diferentes de registro que ninguém documentou.
Chave-valor: velocidade com escopo estreito
Redis e afins guardam valores endereçados por chave, quase sempre em memória. A latência é de microssegundos e o modelo é simples de propósito.
Ganham quando: o acesso é sempre por chave conhecida e a velocidade é o requisito. Cache, sessão, contador, fila de trabalho, limitador de requisições, ranking.
Doem quando: alguém trata o cache como fonte da verdade. Dado que só existe em memória some quando o processo reinicia — e mesmo com persistência configurada, a garantia é diferente da de um banco transacional. Se perder aquele dado tem consequência de negócio, ele precisa existir em outro lugar também.
É um complemento, quase nunca o banco principal. E merece um artigo inteiro sobre os modos de falha que ele apresenta sob pressão.
Série temporal: quando o eixo é o tempo
Prometheus, InfluxDB, TimescaleDB. Dado que chega em ordem cronológica, quase nunca é atualizado e é consultado por faixa de tempo com agregação: métrica de infraestrutura, telemetria de dispositivo, cotação, leitura de sensor.
Ganham quando: o volume de escrita é alto e contínuo, e as consultas são do tipo "média por minuto nas últimas 6 horas". A compressão desses bancos para esse formato de dado é dramática comparada a um relacional, e a agregação por janela de tempo é nativa.
Doem quando: você precisa atualizar registros antigos ou cruzar com entidades de negócio — não é para isso que servem.
Detalhe que evita banco novo: se o volume é moderado, uma extensão de série temporal sobre o PostgreSQL que você já opera resolve sem adicionar mais uma peça ao ambiente.
Busca: quando o usuário digita texto livre
Elasticsearch e OpenSearch indexam texto para responder consulta com relevância, tolerância a erro de digitação, sinônimo e faceta.
Ganham quando: a busca é parte central do produto — catálogo grande, base de conhecimento, análise de log.
Doem quando: são usados como banco principal. São índices de busca; o dado canônico precisa morar no banco transacional, e o índice ser alimentado a partir dele. Operar cluster de busca também tem suas próprias armadilhas de memória e distribuição de shards.
Antes de subir um cluster inteiro: a busca textual do PostgreSQL atende muito caso de catálogo pequeno e médio.
O comparativo direto
| Família | Formato do dado | Acesso típico | Ponto forte | Ponto fraco |
|---|---|---|---|---|
| Relacional | Tabelas com esquema | Consulta variada, com cruzamento | Integridade e transação | Escala de escrita horizontal |
| Documento | Documento aninhado | Por chave, documento inteiro | Esquema flexível, distribuição | Cruzamento entre coleções |
| Chave-valor | Valor simples por chave | Por chave exata | Latência mínima | Não é fonte da verdade |
| Série temporal | Medida com marca de tempo | Faixa de tempo com agregação | Compressão e ingestão | Atualização e cruzamento |
| Busca | Documento indexado | Texto livre com relevância | Relevância e faceta | Não é fonte da verdade |
Poliglota: legítimo, e mais caro do que parece
Sistemas maduros costumam usar mais de um banco: relacional como fonte da verdade, cache em memória na frente, índice de busca ao lado, série temporal para métrica. É um desenho correto.
O que precisa entrar na conta é o custo operacional de cada peça adicional: backup próprio e testado, monitoramento próprio, atualização própria, alguém que saiba diagnosticar quando ela falha às três da manhã, e o mecanismo de sincronização entre a fonte da verdade e os derivados — que é justamente onde aparecem os bugs mais difíceis de reproduzir.
A regra prática: cada banco novo precisa justificar o próprio custo de operação, não só o ganho técnico na feature que motivou a adoção.
Erros comuns
- Escolher por modismo, sem descrever o padrão de acesso.
- Sair do relacional por escala que o ambiente não tem nem vai ter tão cedo.
- Usar banco de documento para dado fortemente relacional e reimplementar junções na aplicação.
- Tratar cache como fonte da verdade.
- Usar índice de busca como banco principal.
- Adicionar um banco novo sem plano de backup, monitoramento e atualização.
- Ignorar que o PostgreSQL já cobre documento, busca e série temporal em volume moderado.
- Decidir com benchmark sintético em vez de uma amostra da carga real.
- Escolher um banco que ninguém da equipe sabe operar em incidente.
A escolha é reversível, mas cara
Trocar de banco depois é possível e é um projeto. Por isso vale gastar duas semanas testando com dado real antes, em vez de dois trimestres migrando depois. Pegue uma amostra representativa, escreva as cinco consultas mais críticas e meça — tempo de resposta, comportamento com volume crescente e, principalmente, quanto trabalho dá operar aquilo.
Onde a Solvefy/Cloud entra
Nossa consultoria de bancos de dados começa exatamente nessa conversa: qual dado você tem, como ele é acessado e o que o negócio exige de consistência e disponibilidade. A partir daí, implantamos, ajustamos e sustentamos — PostgreSQL, MariaDB, MongoDB, Redis e Elasticsearch —, com alta disponibilidade, backup testado, monitoramento e transferência de conhecimento para o seu time. Cobrada por hora, com escopo definido.
Está na dúvida sobre qual banco usar, ou desconfia que o atual não é o certo? Diagnóstico gratuito, sem compromisso, em solvefy.cloud.
Solvefy/Cloud — Infraestrutura que cresce com você.