Compare os principais tipos de bancos de dados — relacional, colunar, documento, grafo, vetorial, chave-valor e outros — com casos de uso, trade-offs e dicas para escolher bem.
Um “tipo de banco de dados” não é apenas um rótulo — é um atalho para como um sistema armazena dados, como você consulta e para o que ele é otimizado. Essa escolha afeta diretamente a velocidade (o que é rápido vs. lento), o custo (hardware ou gasto em nuvem) e as capacidades (transações, analytics, busca, replicação, e mais).
Diferentes tipos de banco fazem diferentes trade-offs:
Essas escolhas de design influenciam:
Este artigo percorre os principais tipos de bancos de dados e explica, para cada um:
Muitos produtos modernos borram as linhas. Alguns bancos relacionais adicionam suporte a JSON que se sobrepõe a um banco de documentos. Plataformas de busca e analytics podem oferecer indexação vetorial como um banco vetorial. Outros combinam streaming e armazenamento com recursos de séries temporais.
Então “tipo” não é uma caixa rígida — ainda assim é útil para entender forças padrão e os tipos de workloads que um banco atende melhor.
Comece pelo seu workload principal:
Use depois a seção “Como Escolher o Tipo Certo de Banco de Dados” para afinar com base em escala, necessidades de consistência e nas consultas que você mais executará.
Bancos relacionais são o que muita gente imagina ao ouvir “banco de dados”. Dados são organizados em tabelas formadas por linhas (registros) e colunas (campos). Um esquema define como cada tabela é — quais colunas existem, seus tipos e como as tabelas se relacionam.
Sistemas relacionais são tipicamente consultados com SQL (Structured Query Language). SQL é popular porque é legível e expressivo:
WHERE, ORDER BY).JOIN).GROUP BY).A maioria das ferramentas de reporting, plataformas de analytics e apps empresariais falam SQL, o que o torna uma escolha segura quando você quer ampla compatibilidade.
Bancos relacionais são conhecidos por transações ACID, que ajudam a manter os dados corretos:
Isso importa quando erros são custosos — como cobrar um cliente em duplicidade ou perder uma atualização de estoque.
Um banco relacional costuma ser a escolha certa para dados bem definidos e estruturados e fluxos como:
A mesma estrutura que torna relacionais confiáveis pode adicionar atrito:
Quando seu modelo muda constantemente — ou você precisa de escala horizontal extrema com padrões de acesso simples — outros tipos podem ser uma escolha melhor.
Bancos colunar armazenam dados “por coluna” em vez de “por linha”. Essa mudança tem grande impacto em velocidade e custo para workloads analíticos.
Num row-store tradicional (comum em um banco relacional), todos os valores de um registro ficam juntos. Isso é ótimo quando você busca ou atualiza um cliente/pedido de cada vez.
Num column-store, todos os valores do mesmo campo ficam juntos — todos os price, todos os country, todos os timestamp. Isso torna eficiente ler apenas as colunas necessárias para um relatório, sem puxar linhas inteiras do disco.
Consultas de analytics frequentemente:
SUM, AVG, COUNT e agrupam por dimensõesO armazenamento por coluna acelera esses padrões porque lê menos dados e comprime muito bem (valores similares agrupados comprimem melhor). Muitos motores colunares também usam execução vetorizada e indexação/particionamento inteligente para acelerar grandes varreduras.
Sistemas colunares brilham para dashboards e relatórios: “receita por semana”, “top 20 produtos por região”, “taxa de conversão por canal” ou “erros por serviço nos últimos 30 dias”. Essas consultas tocam muitas linhas, mas poucas colunas.
Se seu workload é “buscar um registro por ID” ou “atualizar uma única linha dezenas de vezes por segundo”, columnar pode parecer mais lento ou mais caro. Escritas são frequentemente otimizadas para lotes (ingest append-heavy) em vez de atualizações frequentes e pequenas.
Bancos colunar são uma boa escolha para:
Se sua prioridade são agregações rápidas em muitos dados, columnar geralmente é o primeiro tipo a avaliar.
Bancos de documentos armazenam dados como “documentos” — registros autocontidos que se parecem com JSON. Em vez de dividir informação por muitas tabelas, você normalmente mantém campos relacionados juntos em um objeto (incluindo arrays e subobjetos). Isso os torna um encaixe natural para dados de aplicação.
Um documento pode representar um usuário, um produto ou um artigo — completo com atributos que podem diferir entre documentos. Um produto pode ter size e color, outro dimensions e materials, sem forçar um esquema rígido para todos.
Essa flexibilidade é útil quando os requisitos mudam com frequência ou quando itens diferentes têm conjuntos distintos de campos.
Para evitar varrer todos os documentos, bancos documentais usam índices — estruturas que ajudam a localizar rapidamente documentos que casam com uma consulta. Você pode indexar campos comuns (como email, sku ou status), e muitos sistemas também indexam campos aninhados (por exemplo, address.city). Índices aceleram leituras mas adicionam overhead às escritas, porque precisam ser atualizados quando documentos mudam.
Bancos de documentos brilham com esquemas que evoluem, dados aninhados e payloads orientados a APIs. Os trade-offs surgem quando você precisa de:
São uma escolha forte para CMS, catálogos de produtos, perfis de usuário e APIs de backend — onde seus dados mapeiam bem para “um objeto por página/tela/requisição”.
Key-value stores são o modelo de banco mais simples: você armazena um valor (uma string, um JSON, etc.) e recupera usando uma chave única. A operação central é basicamente “me dê o valor para esta chave”, por isso esses sistemas podem ser extremamente rápidos.
Como leituras e escritas giram em torno de uma chave primária, os key-value stores podem ser otimizados para latência baixa e alto throughput. Muitos são projetados para manter dados quentes na memória, minimizar planejamento de consulta e escalar horizontalmente.
Essa simplicidade também molda como modelar dados: em vez de pedir ao BD para “encontre todos os usuários em Berlin que se inscreveram na semana passada”, você costuma desenhar chaves que já apontam para o registro exato que quer (por exemplo, user:1234:profile).
Key-value stores são amplamente usados como cache em frente a um banco primário mais lento (como um relacional). Se seu app precisa repetidamente dos mesmos dados — detalhes de produto, permissões de usuário, regras de preço — cachear o resultado por chave evita recomputar ou reconsultar.
Também são naturais para armazenar sessões (session:<id> -> session data) porque sessões são lidas e atualizadas frequentemente e costumam expirar automaticamente.
A maioria suporta TTL (time to live) para dados expirarem sem limpeza manual — ideal para sessões, tokens one-time e contadores de rate limit.
Quando a memória é limitada, sistemas usam políticas de evicção (como LRU) para remover entradas antigas. Alguns produtos são memory-first; outros persistem em disco para durabilidade. A escolha entre memória e disco depende se você prioriza velocidade (memória) ou retenção/recuperação (persistência).
Key-value stores brilham quando você já conhece a chave. Eles são menos indicados para perguntas abertas.
Muitos têm padrões de consulta limitados comparados a bancos SQL. Suporte a índices secundários (consultar campos dentro do valor) varia: alguns oferecem, outros não, e alguns encorajam que você mantenha chaves de lookup adicionais.
São ótimos para:
Se seu padrão de acesso é “buscar/atualizar por ID” e latência importa, um key-value store costuma ser a forma mais simples de obter velocidade confiável.
Wide-column databases (ou wide-column stores) organizam dados em familias de colunas. Em vez de pensar numa tabela fixa com as mesmas colunas para cada linha, você agrupa colunas relacionadas e pode armazenar conjuntos diferentes de colunas por linha dentro de uma família.
Apesar do nome parecido, wide-column não é o mesmo que um banco colunar usado para analytics.
Um banco colunar armazena cada coluna separadamente para varrer grandes datasets eficientemente (ótimo para relatórios). Um wide-column é construído para workloads operacionais em grande escala, onde você precisa gravar e ler muitos registros rapidamente em muitas máquinas.
Sistemas wide-column são projetados para:
O padrão mais comum é:
Isso os torna fortes para dados ordenados por tempo e workloads append-heavy.
Com wide-column, modelagem é dirigida por consultas: você normalmente desenha tabelas ao redor das consultas exatas necessárias. Isso pode significar duplicar dados em formas diferentes para suportar padrões de acesso distintos.
Eles também tendem a oferecer joins limitados e menos opções de consultas ad-hoc que um relacional. Se sua aplicação depende de relações complexas e consultas flexíveis, você pode se sentir limitado.
São usados para IoT events, mensageria e activity streams e outros dados operacionais em grande escala onde escritas rápidas e leituras previsíveis por chave importam mais que consultas relacionais ricas.
Bancos de grafos armazenam dados como muitos sistemas realmente se comportam: coisas conectadas a outras coisas. Em vez de forçar relações em tabelas e tabelas de junção, as conexões são parte do modelo.
Um grafo normalmente tem:
Isso torna natural representar redes, hierarquias e relações muitos-para-muitos sem contorcer o esquema.
Consultas pesadas em relações frequentemente exigem muitos joins em um relacional. Cada join adicional pode aumentar custo e complexidade conforme os dados crescem.
Bancos de grafos são feitos para travessias — caminhar de um nó para nós conectados, e então para suas conexões. Quando suas perguntas são “encontre coisas conectadas em 2–6 passos”, travessias podem permanecer rápidas e legíveis mesmo com expansão da rede.
Grafos se destacam em:
Grafos podem ser uma mudança para times: modelagem é diferente e linguagens de consulta (Cypher, Gremlin, SPARQL) podem ser novas. Você também vai querer convenções claras para tipos e direção de relação para manter o modelo gerenciável.
Se suas relações são simples, suas consultas são principalmente filtros/agregações e alguns joins cobrem as partes “conectadas”, um banco relacional pode continuar sendo a escolha mais direta — especialmente quando transações e relatórios já funcionam bem.
Bancos vetoriais são projetados para um tipo específico de pergunta: “Quais itens são mais similares a este?” Em vez de casar valores exatos (ID ou palavra-chave), eles comparam embeddings — representações numéricas de conteúdo (texto, imagens, áudio, produtos) geradas por modelos de IA. Itens com significados semelhantes tendem a ficar próximos num espaço multi-dimensional.
Uma busca normal pode perder resultados se a redação for diferente (“laptop sleeve” vs. “notebook case”). Com embeddings, a similaridade é por significado, então o sistema pode trazer resultados relevantes mesmo sem as mesmas palavras.
A operação principal é nearest neighbor search: dado um vetor de consulta, recupere os vetores mais próximos.
Em apps reais, você costuma combinar similaridade com filtros, como:
Esse padrão “filtro + similaridade” é como busca vetorial vira prática para datasets reais.
Usos comuns incluem:
Busca vetorial depende de índices especializados. Construir e atualizar esses índices pode levar tempo e consumir muita memória. Você também costuma escolher entre maior recall (encontrar mais correspondências verdadeiras) e menor latência (respostas mais rápidas).
Bancos vetoriais raramente substituem seu banco principal. Um arranjo comum é: guardar a “fonte da verdade” (pedidos, usuários, documentos) num relacional ou documental, armazenar embeddings + índices vetoriais no banco vetorial — e então unir os resultados com o armazenamento primário para registros completos e verificações de permissão.
Bancos de séries temporais (TSDBs) são feitos para dados que chegam continuamente e sempre têm um timestamp. Pense em uso de CPU a cada 10s, latência de API por requisição, leituras de sensores por minuto ou preços de ações que mudam várias vezes por segundo.
A maioria dos registros de séries temporais combina:
Isso facilita perguntas como “mostre taxa de erro por serviço” ou “compare latência entre regiões.”
Como o volume de dados cresce rápido, TSDBs normalmente focam em:
Esses recursos mantêm custos de armazenamento e consulta previsíveis sem limpeza manual constante.
TSDBs são fortes quando você precisa de cálculos baseados em tempo, como:
Casos típicos: monitoramento, observabilidade, IoT/sensores e ticks financeiros.
O trade-off: TSDBs não são a melhor escolha para relações complexas e ad-hoc entre muitas entidades (ex.: joins profundamente aninhados como “usuários → times → permissões → projetos”). Para isso, um relacional ou grafo é geralmente mais adequado.
Um data warehouse é menos um único “tipo de banco” e mais uma carga de trabalho + arquitetura: muitas equipes consultando dados históricos grandes para responder perguntas de negócio (tendências de receita, churn, risco de inventário). Você pode comprá-lo como produto gerenciado, mas o que o torna um warehouse é o uso — centralizado, analítico e compartilhado.
A maioria dos warehouses aceita dados por duas formas comuns:
Warehouses são otimizados para analytics com alguns truques práticos:
Quando vários departamentos dependem dos mesmos números, você precisa de controle de acesso (quem vê o quê), trilhas de auditoria (quem consultou/alterou dados) e lineage (de onde veio uma métrica e como foi transformada). Isso costuma ser tão importante quanto velocidade de consulta.
Um lakehouse mistura o estilo warehouse com a flexibilidade de um data lake — útil quando você quer um lugar para tabelas curadas e arquivos brutos (logs, imagens, eventos semi-estruturados) sem duplicar tudo. Faz sentido quando o volume é alto, os formatos variam e você ainda precisa de consultas SQL amigáveis.
Escolher entre tipos de banco é menos sobre “o melhor” e mais sobre ajuste: o que você precisa consultar, com que rapidez e o que acontece quando partes do sistema falham.
Uma regra rápida:
Relacionais costumam brilhar em OLTP; sistemas colunares, warehouses e lakehouses são comuns para OLAP.
Quando um problema de rede divide seu sistema, normalmente você não consegue ter os três ao mesmo tempo:
Muitos bancos distribuídos escolhem ficar disponíveis durante problemas e reconciliar depois (consistência eventual). Outros priorizam correção estrita, mesmo que isso signifique recusar requisições até o sistema se recuperar.
Se muitos usuários atualizam os mesmos dados, você precisa de regras claras. Transações agrupam passos em “tudo-ou-nada”. Locking e níveis de isolamento previnem conflitos, mas podem reduzir throughput; isolamento mais frouxo melhora velocidade mas pode permitir anomalias.
Planeje backups, replicação e disaster recovery cedo. Considere quão fácil é testar restores, monitorar lag e executar upgrades — detalhes do dia 2 muitas vezes importam tanto quanto a velocidade de consulta.
Escolher entre os principais tipos de bancos de dados é menos sobre o que está na moda e mais sobre o que você precisa fazer com seus dados. Uma forma prática de começar é trabalhar de trás para frente a partir das suas consultas e workloads.
Anote as 5–10 coisas principais que seu app ou time precisa fazer:
Isso reduz as opções mais rápido que qualquer checklist de features.
Use este checklist rápido de “forma”:
Metas de performance definem arquitetura. Defina números aproximados (p95, leituras/escritas por segundo, retenção de dados). O custo geralmente vem de:
| Caso de uso primário | Melhor ajuste (frequentemente) | Por quê |
|---|---|---|
| Transações, faturas, contas de usuário | Relacional (SQL) | Restrições fortes, joins, consistência |
| Dados de app com campos em evolução | Documento | Esquema flexível, natural em JSON |
| Cache/estado de sessão em tempo real | Chave-valor | Leituras rápidas por chave |
| Clickstreams/métricas ao longo do tempo | Séries temporais | Alta ingestão + consultas temporais |
| Dashboards e grandes agregações | Colunar | Varreduras rápidas + compressão |
| Dados sociais/relacionais complexos | Grafo | Travessias eficientes entre relacionamentos |
| Busca semântica, RAG | Vetorial | Busca por similaridade em embeddings |
| Dados operacionais massivos | Wide-column | Escala horizontal, consultas previsíveis |
Muitas equipes usam dois bancos: um para operações (ex.: relacional) e outro para analytics (ex.: colunar/warehouse). A escolha “certa” é a que torna suas consultas mais importantes as mais simples, rápidas e baratas de executar de forma confiável.
Se estiver prototipando ou lançando recursos rapidamente, a decisão do banco costuma se ligar ao fluxo de desenvolvimento. Plataformas como Koder.ai (uma plataforma de vibe-coding que gera apps web, backend e mobile a partir de chat) tornam isso mais concreto: por exemplo, o stack default do backend do Koder.ai usa Go + PostgreSQL, que é um bom ponto de partida quando você precisa de correção transacional e amplo ecossistema SQL.
À medida que o produto cresce, você pode adicionar bancos especializados (como um banco vetorial para busca semântica ou um warehouse colunar para analytics) mantendo PostgreSQL como sistema de registro. A chave é começar pelos workloads que você precisa hoje — e manter a porta aberta para “adicionar uma segunda loja” quando os padrões de consulta exigirem.
Um “tipo de banco de dados” é uma forma curta de dizer três coisas:
Escolher o tipo é, na prática, escolher padrões padrão para desempenho, custo e complexidade operacional.
Comece pelos top 5–10 queries e padrões de escrita do seu produto, depois mapeie-os para as forças certas:
Bancos relacionais são uma boa escolha padrão quando você precisa de:
Eles ficam difíceis quando há mudanças constantes no esquema ou quando é necessário escalar horizontalmente ao extremo com muitas consultas que fazem joins entre shards.
ACID é uma garantia de confiabilidade para mudanças multi-etapa:
É crítico para fluxos onde erros são caros (pagamentos, reservas, atualizações de inventário).
Bancos colunar são ideais quando as consultas:
SUM, COUNT, AVG, )Um banco de documentos é adequado quando:
Fique atento a trade-offs: joins complexos, duplicação de dados para otimizar leituras e custo de transações multi-documento.
Use um armazenamento chave-valor quando seu padrão de acesso for basicamente:
Planeje as limitações: consultas ad-hoc são geralmente fracas e o suporte a índices secundários varia—muitas vezes você precisa projetar chaves e índices adicionais manualmente.
Apesar do nome parecido, eles atendem cargas diferentes:
Wide-column normalmente exige modelagem orientada a consultas (desenhar tabelas de acordo com padrões de acesso) e não busca oferecer a flexibilidade de joins como SQL.
Escolha um banco de grafos quando as suas perguntas centrais forem sobre relações, como:
Grafos são excelentes para travessias (andar pelas relações), onde um modelo relacional exigiria muitos joins. A troca é adotar novas convenções de modelagem e linguagens de consulta (Cypher/Gremlin/SPARQL).
Um banco vetorial resolve busca por similaridade sobre embeddings (representações numéricas de significado). É usado para:
Na prática, costuma ser pareado com um armazenamento relacional/documental: mantenha a fonte da verdade lá, armazene embeddings e índices vetoriais no DB vetorial e una resultados para obter registros completos e checar permissões.
Se você precisa de OLTP e analytics, planeje dois sistemas desde cedo (BD operacional + BD analítico).
GROUP BYEles costumam ser menos indicados para workloads OLTP, como atualizações frequentes e pequenas ou "buscar um registro por ID", que são melhor atendidos por row-stores.