Banco de Dados para Desenvolvedores

"Banco de dados são escolhidos somente pelo tipo de dados da aplicação?"

O erro mais comum

O que realmente influencia a escolha de um banco

Bancos relacionais

Modelo tabular com SQL, joins, constraints e transações ACID

PostgreSQL — referência relacional moderna

NoSQL não é "melhor que SQL"

É outra categoria de trade-offs, não um upgrade natural.

Bancos de documentos

Key-value stores

Wide-column databases

Graph databases

Nós e relacionamentos — ótimo para conexões complexas.

• Redes sociais e recomendação
• Detecção de fraude
• Permissões e dependências

Search engines

Time-series databases

Dados orientados ao tempo — cada registro carrega um timestamp como dimensão central.

Vector databases

Guardam embeddings — representações numéricas do significado de um texto ou imagem. A busca encontra conteúdo parecido, não apenas idêntico.

Event stores e persistência orientada a eventos

Event Sourcing = guardar cada mudança que aconteceu, não só o resultado final. Como um extrato bancário, não apenas o saldo atual.

Ideia central: Event Sourcing

O banco muda quando o sistema deixa de ser simples

Deixa de ser "uma tabela em um servidor" e passa a fazer parte de uma arquitetura distribuída.

Consistência eventual

Os servidores não ficam iguais na hora, mas depois de um tempo todos convergem. Aceitável quando ver dado levemente desatualizado não é um problema grave.

Quando consistência forte importa

Todo mundo precisa ver o mesmo valor ao mesmo tempo. Quando errar por segundos causa prejuízo real — dinheiro, estoque ou vaga perdida.

Teorema de CAP

Quando a rede falha, você não consegue garantir dado 100% correto e sistema sempre respondendo ao mesmo tempo. Precisa escolher um lado.

C

Consistency

Todos veem o mesmo dado

A

Availability

Sistema sempre responde

P

Partition Tolerance

Tolera falha de rede

CP vs AP

CP prefere parar ou bloquear a entregar dado errado. AP prefere continuar respondendo, mesmo que o dado ainda não esteja atualizado.

Teorema PACELC

CAP olha o que acontece quando a rede falha. PACELC lembra que, mesmo sem falha, você troca velocidade por dado mais fresco.

Mesmo sem falha, sistemas distribuídos vivem trade-offs entre latência e consistência.

PACELC na prática

Ler do servidor mais próximo é rápido, mas o dado pode estar desatualizado. Ler do servidor central é mais lento, porém mais confiável.

Índices

Atalho que o banco usa para achar linhas sem varrer a tabela inteira — como o índice de um livro. Acelera leitura, mas deixa escrita e armazenamento mais pesados.

Transações e ACID

Garantias de que uma operação composta completa tudo corretamente ou não faz nada. Essencial em transferências, pagamentos e qualquer regra de negócio crítica.

ACID vs BASE

ACID prioriza correção rigorosa. BASE prioriza ficar online e aceitar que os dados convergem depois — comum em sistemas de grande escala.

Normalização vs desnormalização

Normalizar = organizar tabelas para não repetir dados. Desnormalizar = repetir dados de propósito para evitar joins e ler mais rápido.

Nenhuma é "sempre correta" — depende do workload.

OLTP vs OLAP

OLTP = banco do dia a dia do app — muitas operações pequenas e rápidas. OLAP = banco de análise — consultas pesadas, relatórios e dashboards.

Polyglot Persistence

Usar mais de um banco no mesmo sistema — cada um resolve um problema diferente. Não é fraqueza; é escolher a ferramenta certa para cada job.

Como escolher na prática

Exemplos reais de decisão

Conclusão

• Banco de dados não é só armazenamento
• Banco é decisão de arquitetura
• Escolher banco é escolher trade-offs
• Escala, consistência, latência e operação importam tanto quanto o modelo do dado