Tipos de Banco de Dados: qual usar, quando e por quê — O Guia Completo

💾 1. Bancos de Dados Relacionais (SQL/RDBMS)

Exemplos: PostgreSQL, MySQL/MariaDB, Oracle Database, SQL Server, SQLite

Como funcionam:

Organizam dados em tabelas (também chamadas de relações) com linhas (registros/tuplas) e colunas (atributos), conectadas por chaves primárias e chaves estrangeiras.

Consultas são feitas via SQL, garantindo transações ACID:

• Atomicity (Atomicidade): tudo ou nada
• Consistency (Consistência): regras sempre válidas
• Isolation (Isolamento): transações não interferem entre si
• Durability (Durabilidade): dados persistidos são permanentes

Quando usar:

✅ Aplicações corporativas (ERP, CRM, sistemas bancários, e-commerce)
✅ Dados com estrutura fixa e relações bem definidas (ex: usuários → pedidos → produtos)
✅ Quando consistência é mais importante que performance
✅ Compliance e auditoria (logs inalteráveis, LGPD/GDPR)
✅ Transações financeiras (impossível perder um centavo)

Por que usar:

São maduros, testados em batalha e comprovados há décadas. O PostgreSQL, por exemplo, é praticamente o “tanque de guerra open source” dos bancos — suporta JSON, full-text search, extensões (como pgvector para IA), e ainda assim mantém todas as garantias ACID.

MySQL/MariaDB domina a web (WordPress, Drupal, 90% dos sites PHP). Oracle e SQL Server reinam no enterprise.

Trade-offs:

❌ Escalabilidade vertical limitada (caro adicionar RAM/CPU infinitamente)
❌ Schema rígido (ALTER TABLE pode travar banco em produção)
❌ Sharding complexo (dividir dados entre servidores dá trabalho)

Casos reais:

• Nubank: PostgreSQL para transações financeiras (milhões de clientes, zero inconsistência tolerada)
• Stripe: também PostgreSQL, processando bilhões de dólares
• Stack Overflow: SQL Server gerenciando milhões de perguntas e respostas

🔑 3. Bancos Key-Value (Chave-Valor)

Exemplos: Redis, DynamoDB, Riak, Memcached, etcd

Como funcionam:

A estrutura mais simples possível: guardam pares chave → valor, como um HashMap/Dictionary gigante distribuído.

Redis, por exemplo, roda em memória (RAM) e suporta estruturas de dados complexas: strings, hashes, listas, sets, sorted sets, bitmaps, HyperLogLogs e streams.

Quando usar:

✅ Cache de aplicação (páginas renderizadas, queries SQL, APIs externas)
✅ Sessões de usuário (tokens JWT, dados de login)
✅ Rate limiting e throttling
✅ Ranking em tempo real (leaderboards de jogos)
✅ Filas de mensagens (job queues, pub/sub)
✅ Contadores e métricas (views, likes, analytics)

Por que usar:

Performance absurda — operações de leitura/escrita em sub-milissegundos. Redis consegue facilmente 100.000+ operações por segundo em hardware modesto.

Simplicidade brutal: SET user:1000 "John Doe" e GET user:1000. Pronto.

Trade-offs:

❌ Sem queries complexas (esqueça WHERE, JOIN, GROUP BY)
❌ Limitado pela RAM (caro escalar para terabytes)
❌ Você precisa saber a chave exata — ou não encontra nada

Casos reais:

• Twitter: Redis para timeline caching (milhões de tweets por segundo)
• GitHub: Redis para jobs em background e rate limiting
• Pinterest: Memcached para cache de imagens e metadata

⏱️ 5. Bancos de Dados de Séries Temporais (Time-Series DB)

Exemplos: InfluxDB, TimescaleDB, Prometheus, Graphite, OpenTSDB

Como funcionam:

Armazenam dados associados a timestamps, registrando variações ao longo do tempo. São otimizados para append-only writes (escrever no final, nunca atualizar) e queries baseadas em tempo.

Estrutura típica: métrica + timestamp + valor + tags

cpu_usage,host=server01,region=us-east 85.3 1697219420
cpu_usage,host=server01,region=us-east 87.1 1697219480

Quando usar:

✅ Monitoramento de infraestrutura (CPU, memória, disco, rede)
✅ Observabilidade e APM (Application Performance Monitoring)
✅ IoT e telemetria (sensores, dispositivos embarcados)
✅ Finanças e trading (cotações de ações, criptomoedas)
✅ Analytics de eventos (clickstream, user behavior)

Por que usar:

Otimizados para responder perguntas temporais rapidamente:

• “Qual a média de CPU nos últimos 5 minutos?”
• “Pico de requisições na última hora por região”
• “Anomalias nos últimos 30 dias”

Compressão agressiva (dados temporais são altamente compressíveis) e rollups automáticos (agregação de dados antigos).

Trade-offs:

❌ Não serve para dados transacionais
❌ Atualizações/deleções são caras
❌ Não é ACID compliant

Casos reais:

• Booking.com: InfluxDB para monitoramento de performance
• Tesla: time-series para telemetria de veículos
• DigitalOcean: Prometheus para observabilidade da infraestrutura

⚡ 7. Bancos em Memória (In-Memory DB)

Exemplos: Redis, Memcached, SAP HANA, Apache Ignite, Hazelcast

Como funcionam:

Guardam 100% dos dados na RAM (memória volátil), eliminando completamente o gargalo de disco.

Latência típica:

• Disco HDD: 10-20ms
• SSD: 0.1-1ms
• RAM: 0.0001ms (100 nanossegundos)

Isso significa 10.000x a 100.000x mais rápido que disco.

Quando usar:

✅ Sistemas que exigem latência < 1ms
✅ Cache L1 de aplicação (antes de bater no banco principal)
✅ Real-time analytics (dashboards ao vivo)
✅ Jogos online (state de partidas, ranking ao vivo)
✅ Trading algorítmico (milissegundos = milhões de dólares)
✅ Session stores (milhões de usuários simultâneos)

Por que usar:

Velocidade insana. Redis consegue facilmente 100.000-500.000 operações por segundo em hardware modesto, e 1M+ ops/s em clusters otimizados.

Trade-offs:

❌ RAM é cara (vs disco)
❌ Volatilidade (precisa configurar persistência para não perder dados no reboot)
❌ Limitação de tamanho (difícil ter terabytes em RAM)

Casos reais:

• Amazon: Redis para sessões de milhões de usuários
• Tinder: Redis para matching em tempo real
• Stack Overflow: Redis para caching agressivo

🧬 9. Bancos Vetoriais (Vector Databases) — A Revolução da IA

Exemplos: Pinecone, Milvus, Weaviate, Qdrant, Chroma, FAISS, pgvector (extensão PostgreSQL)

Como funcionam:

Armazenam embeddings — representações matemáticas de dados (textos, imagens, áudios, vídeos, código) na forma de vetores de alta dimensão (256, 512, 1536, 3072 dimensões são comuns).

Embeddings são arrays de números float:

"carro elétrico" → [0.23, -0.45, 0.89, ..., 0.12]  # 1536 dimensões
"Tesla Model 3"  → [0.25, -0.43, 0.91, ..., 0.10]  # 1536 dimensões

Esses vetores capturam significado semântico — conceitos similares ficam próximos no espaço vetorial (medido por distância cosseno, distância euclidiana ou produto interno).

O que é Similarity Search?

Em vez de buscar texto exato (WHERE title LIKE '%tesla%'), você busca por similaridade semântica:

query = "veículos elétricos modernos"
query_embedding = model.encode(query)  # [0.24, -0.44, 0.90, ...]

# Busca os K vetores mais próximos (KNN - K-Nearest Neighbors)
results = vector_db.search(query_embedding, k=10)
# Retorna: Tesla Model 3, Nissan Leaf, Chevrolet Bolt, ...

Quando usar:

✅ Busca semântica (Google, Bing, Claude, ChatGPT)
✅ RAG (Retrieval-Augmented Generation) em IA generativa
✅ Chatbots inteligentes (buscar contexto relevante antes de responder)
✅ Sistemas de recomendação avançados (conteúdo similar)
✅ Busca por similaridade multimodal (texto → imagem, áudio → texto)
✅ Detecção de plágio e duplicatas semânticas
✅ Code search (GitHub Copilot, busca de código por descrição)

Por que usar:

Permitem à IA entender contexto e significado, não apenas palavras exatas ou regex.

São otimizados para bilhões de vetores e buscas em milissegundos usando algoritmos como HNSW (Hierarchical Navigable Small World), IVF (Inverted File Index) e PQ (Product Quantization).

Arquitetura típica de RAG (Retrieval-Augmented Generation):

1. Ingestão: documento = "A fotossíntese é o processo..." embedding = openai.embeddings.create(input=documento, model="text-embedding-3-large") vector_db.insert(id=doc_id, vector=embedding.data[0].embedding, metadata={...})
2. Query: pergunta = "Como as plantas produzem energia?" query_embedding = openai.embeddings.create(input=pergunta, ...) contextos_relevantes = vector_db.search(query_embedding.data[0].embedding, k=5)
3. Geração: prompt = f"Baseado nestes contextos:\n{contextos_relevantes}\n\nResponda: {pergunta}" resposta = openai.chat.completions.create(messages=[{"role": "user", "content": prompt}])

Dimensionalidade e Trade-offs:

• Mais dimensões = maior precisão semântica, mas + memória e + latência
• Menos dimensões = menos preciso, mas muito mais rápido

OpenAI text-embedding-3-small: 1536 dimensões (~$0.02 / 1M tokens)
OpenAI text-embedding-3-large: 3072 dimensões (~$0.13 / 1M tokens)

Casos reais:

• Notion AI: Pinecone para busca semântica em workspaces
• Shopify: embeddings para recomendação de produtos
• Spotify: vetoriais para recomendação de músicas e podcasts
• GitHub Copilot: busca de código via embeddings

O Futuro Híbrido: pgvector

O PostgreSQL já possui a extensão pgvector, que transforma o banco relacional clássico em um híbrido SQL + vetorial:

-- Criar tabela com coluna vetorial
CREATE TABLE documentos (
  id SERIAL PRIMARY KEY,
  titulo TEXT,
  conteudo TEXT,
  embedding vector(1536)  -- Vetor de 1536 dimensões
);

-- Busca por similaridade (cosine distance)
SELECT titulo, 1 - (embedding <=> '[0.1, 0.2, ...]') AS similarity
FROM documentos
ORDER BY embedding <=> '[0.1, 0.2, ...]'
LIMIT 10;

Isso permite:

• Transações ACID + busca vetorial
• Um único banco para dados estruturados + embeddings
• Joins entre tabelas SQL e similaridade semântica