Começa Com A Letra B

Por que a maioria dos projetos travam no banco de dados

A maior parte dos desenvolvedores escolhe o banco de dados que conhece da faculdade. Não que isso seja errado. O problema é que os benchmarks que você vê na internet rodam com datasets irreais. Um INSERTbatch de 10 mil linhas num Postgres roda instantaneamente porque a tabela ainda não existe. Na vida real, você começa a ter lentidão quando o número de linhas escala e o plano de execução muda sem você perceber. O que eu chamo de começa com a letra b quando quero dizer um sistema de gerenciamento de banco de dados relacional é simplesmente uma ferramenta que guarda dados estruturados e responde a consultas. A definição técnica é mais longa, mas na prática você vai usar uma dessas coisas todos os dias. Redis para cache. PostgreSQL para dados transacionais. MongoDB se o esquema muda muito rápido. A escolha errada gera dor de cabeça silenciosa que só aparece meses depois. O que ninguém te conta é que o plano de execução do seu SELECT mais simples pode mudar entre versões do banco sem aviso. Eu passei uma semana caçando performance num projeto porque um UPDATE com subconsulta que levava 0,3 segundos passou a levar 8 segundos após um upgrade do PostgreSQL de 14 para 16. O explain analyze não mostrava nada de errado. Só depois de verificar o pull plan que encontrei a diferença: o custo estatístico mudou e o otimizador resolveu fazer nested loop em vez de hash join. Uma versão nova do banco, mesma query, comportamento completamente diferente.

Como começar (e não perder três dias)

Se você está começando do zero, o caminho mais direto é baixar e instalar o PostgreSQL. Ele é gratuito, roda em qualquer lugar, e tem ferramentas como o pg_dump que salvam seu pescoço quando algo dá errado. O Docker já tem imagem pronta. Você roda em dois minutos. Criação de banco:

CREATE DATABASE app_em_prod;
CREATE USER app_user WITH PASSWORD 'não_use_senha_faca';
GRANT ALL PRIVILEGES ON DATABASE app_em_prod TO app_user;

Esse comando acima é o básico. O erro mais comum é dar permissão total ao usuário da aplicação em todas as tabelas e schemas. Você não precisa disso. Permissões granulares evitam problemas depois. Eu perdi um dia inteiro corrigindo acesso porque um desenvolvedor junior havia dado GRANT ALL em tudo sem ler a documentação. O maior problema que eu encontrei na prática foi com NULL em índices compostos. O PostgreSQL indexa NULLs por padrão, mas o MySQL (InnoDB) não. Se você migra uma query de um para o outro, o plano de execução pode mudar radicalmente. E isso não aparece num teste unitário. Aparece quando o banco já está em produção com milhões de linhas. Uma dica prática que salva tempo: use EXPLAIN ANALYZE antes de confiar que seu índice está funcionando. O EXPLAIN mostra o plano estimado. O ANALYZE mostra o plano real executado. A diferença entre eles é onde a mágica (ou o problema) acontece.

Outro erro comum é criar índices em colunas que todo mundo pensa que devem ser indexadas. Timestamps? Raramente. Campos booleanos? Quase nunca, a menos que a coluna tenha distribuição altamente desigual. Um índice em coluna booleana com 99% TRUE e 1% FALSE funciona, mas com distribuição 50/50 é pior que não ter índice algum. O custo de manter o índice durante INSERTs supera o ganho na leitura.

Query lenta: passo a passo

Quando uma query trava, não comece ajustando o código. Comece pelo banco. O comando ANALYZE é simples mas faz diferença real. Bancos modernos mantêm estatísticas automáticas, mas em tabelas com UPDATE massivo ou INSERT batch as estatísticas ficam desatualizadas. O otimizador decide com base em dados velhos e escolhe plano ruim. Rodar ANALYZE manualmente resolve 70% dos casos de query lenta sem mudança de schema ou índice. Partições de tabela são useful quando você tem dados que podem ser separados por período. Registros de 2020, 2021, 2022 em partições diferentes. Consultas que filtram por ano rodam em uma fração do tempo porque o planner ignora partições irrelevantes. Mas cuidado: partição excessiva aumenta o overhead de manutenção. 50 partições não é vantagem. 5 a 10 partições por ano costuma ser o sweet spot.

Connection pooling é obrigatório em produção. Cada conexão consome memória e CPU no servidor de banco. O PgBouncer é a ferramenta padrão. Ele reutiliza conexões e evita que seu aplicativo abra 200 conexões simultâneas num pico de tráfego. Sem pooler, seu banco vai morrer de conexões antes de morrer de queries lentas. Migrações de schema merecem atenção especial. ALTER TABLE ADD COLUMN com DEFAULT num banco grande pode travar a tabela por minutos ou horas, dependendo do motor. O PostgreSQL resolve isso com ADD COLUMN sem DEFAULT primeiro, depois um UPDATE batched, e só então o DEFAULT. Esse truque evita lock table completo. Eu vi um ALTER simples travar um banco de e-commerce por 45 minutos. O gerente de produção quase pediu demissão.

Alternativas ao modelo relacional clássico

nem todo problema precisa de banco relacional. Se seu dado é altamente relacional e não muda de estrutura, o SQL é a melhor escolha. Se você precisa de flexibilidade extrema em esquema, considere um NoSQL como MongoDB. Se velocidade de leitura é crítica e tolera perda de dados em failover, Redis pode ser suficiente. A resposta correta depende do caso de uso. Não existe ferramenta universal. O que eu aprendi na prática é que a escolha do banco define o architecture do projeto inteiro. Trocar de banco depois é caro. Escolha com base nos requisitos reais, não no hype do momento. E sempre tenha um plano B: um export bem feito do pg_dump ou mongodump pode ser a diferença entre um incident tranquilo e um 3 AM page de pânico.