Que tipos de banco de dados existem

A caminho do índice, QUERY desacelera diante de uma seção escura do cofre. Atrás do vidro está o registro dos arquivos da velha Terra que não sobreviveram à Grande Ruptura: os nós de cache apagaram primeiro, os bancos documentais chegaram em fragmentos, os clusters analíticos ficaram em silêncio por setores inteiros. Já o instantâneo relacional do «Kotomarket» sobreviveu completo — com todas as conexões intactas.

Nem só relacionais

Para o «Kotomarket», os bancos relacionais servem especialmente bem: compradores, pedidos e produtos se encaixam naturalmente em tabelas conectadas entre si. É a eles que este curso se dedica. Mas, na indústria, existem também outras abordagens:

• chave-valor (Redis) — um formato «chave → valor» muito rápido, para quando você precisa buscar um registro simples na hora;
• orientados a documentos (MongoDB) — guardam documentos JSON flexíveis, cuja estrutura pode variar de registro para registro;
• colunares (ClickHouse) — fortes em análise, quando é preciso calcular métricas rapidamente sobre volumes enormes de dados.

A maioria dos SGBDs populares no desenvolvimento de produtos continua sendo relacional: PostgreSQL, MySQL, Oracle, MS SQL. Domine SQL aqui e você conseguirá ler dados com segurança em empresas bem diferentes.

QUERY: Cada arquivo tem uma função: um prioriza velocidade, outro flexibilidade, um terceiro análise. Tivemos sorte: herdamos justamente aquele em que tudo está conectado a tudo.

Not only relational

For Kotomarket, relational databases suit us especially well: buyers, orders, and products fall naturally into tables with links between them. That’s what this course is about. But across the industry — in 2024 just as today — you’ll meet other approaches too:

• key-value (Redis) — a blazingly fast "key → value" format for when you need to grab a simple record instantly;
• document-oriented (MongoDB) — stores flexible JSON documents whose structure can differ from record to record;
• columnar (ClickHouse) — strong at analytics, when you need to crunch metrics over enormous volumes of data fast.

Most of the popular DBMSs for product development stay relational: PostgreSQL, MySQL, Oracle, MS SQL. Master SQL here and you’ll be able to read data confidently at very different companies.

QUERY: Each archive has its own job: one prizes speed, another flexibility, a third analytics. You and I got lucky: we inherited the one where everything is connected to everything.

O registro das famílias: cada coisa em seu lugar

O registro atrás do vidro é um bom pretexto para destrinchar de verdade as famílias de bancos de dados: «que tipos de BD existem e quando escolher cada um» é uma das perguntas mais comuns em entrevistas. Vamos percorrer cinco famílias, sempre pelo mesmo roteiro: forma de armazenamento, pontos fortes e fracos, produtos e quando escolher.

Bancos relacionais: esquema rígido e conexões

Forma de armazenamento: linhas em tabelas com um esquema declarado de antemão — cada coluna tem um tipo, as conexões entre tabelas funcionam por chaves, e o próprio SGBD protege a integridade: não dá para registrar um pedido de um comprador que não existe. As alterações são executadas como transações com garantias ACID — «pedido + baixa no estoque» são gravados juntos, ou nada é gravado.

• Pontos fortes: SQL expressivo (filtros, junções de tabelas, agregações), integridade garantida no nível do banco, transações.
• Pontos fracos: o esquema precisa ser planejado antes e migrado quando algo muda; escalar horizontalmente em muitos servidores é mais difícil do que nas famílias NoSQL.
• Produtos: PostgreSQL, MySQL/MariaDB, Microsoft SQL Server, Oracle, SQLite.
• Quando escolher: usuários, pedidos, dinheiro, estoque — qualquer cenário em que os dados são conectados e uma gravação errada é inaceitável. Para um produto novo, esta é a escolha padrão.

Bancos chave-valor: um dicionário em velocidade máxima

Forma de armazenamento: um único dicionário gigante «chave → valor», quase sempre mantido na memória RAM. Sem tabelas, sem conexões: você grava pela chave e busca de volta pela chave em frações de milissegundo.

-- Isto não é SQL, são comandos do Redis
SET session:8f3a '{"user_id": 42}'
GET session:8f3a

• Pontos fortes: velocidade, simplicidade, escalonamento fácil.
• Pontos fracos: só dá para consultar por uma chave exata — não há como pedir a esse formato «encontre todas as sessões de compradores de Moscou»; o conteúdo do valor é opaco para o banco.
• Produtos: Redis, Memcached, Amazon DynamoDB.
• Quando escolher: cache, sessões, contadores, filas, rankings — dados quentes ao lado do banco principal, e não no lugar dele.

Bancos documentais: JSON flexível

Forma de armazenamento: os registros são documentos JSON agrupados em coleções. O esquema não é declarado de antemão: um smartwatch tem o campo «duração da bateria», um moletom tem uma «tabela de medidas», e os dois documentos convivem tranquilamente na mesma coleção. Estruturas aninhadas ficam dentro do próprio documento, sem tabelas separadas.

• Pontos fortes: estrutura flexível, leitura do documento inteiro em um único acesso, praticidade para catálogos com atributos heterogêneos e protótipos rápidos.
• Pontos fracos: as conexões entre documentos ficam a cargo da aplicação, e quase não existe um JOIN de verdade; sem disciplina, uma coleção vira um conjunto de formatos incompatíveis.
• Produtos: MongoDB, Couchbase, Firestore.
• Quando escolher: conteúdo, catálogos com campos muito variados, perfis e configurações.

A fronteira entre as famílias, aliás, é difusa: o PostgreSQL consegue guardar documentos em uma coluna do tipo jsonb e criar índices sobre eles — muitas vezes isso resolve a necessidade «de documento» sem um segundo banco:

-- Um exemplo fora do nosso instantâneo: attrs é uma coluna do tipo jsonb
SELECT name, attrs->>'color' AS color
FROM catalog
WHERE attrs @> '{"brand": "Kotomarket"}';

Bancos colunares: análise sobre bilhões de linhas

Forma de armazenamento: os valores não ficam linha a linha, e sim por coluna: todos os preços juntos, todas as datas juntas. A consulta «ticket médio por mês» lê do disco apenas duas colunas em vez da tabela inteira, e valores do mesmo tipo comprimem muito bem. É daí que vem a velocidade nas agregações.

-- O gênero predileto de um banco colunar (dialeto do ClickHouse: toYYYYMM é uma função dele)
SELECT toYYYYMM(created_at) AS month, avg(total_amount) AS avg_check
FROM orders
GROUP BY month;

• Pontos fortes: agregações e varreduras sobre bilhões de linhas, compressão forte.
• Pontos fracos: atualizações e exclusões pontuais são caras; ler uma única linha completa é mais lento do que em um banco por linhas; carga transacional não é o objetivo desse modelo.
• Produtos: ClickHouse, BigQuery, Snowflake, Amazon Redshift.
• Quando escolher: análise, relatórios, eventos, logs, métricas — normalmente ao lado do banco relacional «de produção».

Aqui entram dois termos que entrevistadores adoram: OLTP (online transaction processing — muitas operações curtas de gravação e leitura, o mundo do PostgreSQL) e OLAP (online analytical processing — leituras analíticas pesadas sobre todo o histórico, o mundo do ClickHouse). O produto grava no banco OLTP, a análise lê uma cópia OLAP.

E a última família — os bancos de grafo

Quando as conexões importam mais do que os próprios registros — «amigos de amigos», rotas de entrega, cadeias de recomendação —, entram os bancos de grafo (Neo4j, Memgraph). Neles, os dados são nós (os registros) e arestas (as conexões entre os registros); percorrer conexões em qualquer profundidade é uma operação nativa. Em um banco relacional, o mesmo percurso vira uma cadeia de junções de tabelas que fica mais pesada a cada nível.

Miniguia: como escolher um banco para o projeto

1. Comece pelas perguntas, não pelos dados. Que consultas o produto vai fazer: pontuais «por chave», relacionais «quem comprou o quê», analíticas «quanto no mês»?
2. Por padrão — relacional. Dados conectados e alto custo de erro (pedidos, pagamentos, estoque) apontam para PostgreSQL. É o começo mais seguro para quase qualquer produto.
3. Bancos especializados — para uma tarefa específica, não «por precaução». As leituras quentes estão apertando — adicione um cache no Redis. A análise cresceu — replique os eventos para o ClickHouse. Há variabilidade absurda de campos — comece pelo jsonb no PostgreSQL, e só adote um banco documental se isso não bastar.
4. Calcule o custo de um segundo banco. Cada novo SGBD traz sincronização de dados, backups, monitoramento e mais uma tecnologia para a equipe manter.