O que é banco de dados e qual tipo escolher para cada projeto

Você termina o curso, abre o editor para começar o primeiro projeto de verdade (um controle de estoque para a loja de um parente, digamos) e trava antes da primeira linha: PostgreSQL, MySQL, MongoDB, SQLite, Firebase? Cada tutorial jura que o seu é o certo.

A boa notícia é que, para a imensa maioria dos projetos, a escolha é menos dramática do que parece. Um banco de dados é só um programa especializado em guardar informações de forma organizada e devolver exatamente o pedaço que você pedir, rápido e sem perder nada quando a luz cai. O que muda entre os tipos é como os dados são organizados e quais garantias o banco oferece.

Direto ao ponto: se você não tem um motivo concreto para outra coisa, comece com um banco relacional (PostgreSQL para aplicações web, SQLite para apps locais e protótipos). NoSQL resolve problemas específicos e entra quando esses problemas aparecem.

Banco de dados por dentro: tabela, documento, chave

Antes de comparar, vale entender as três formas de organização que você mais vai encontrar.

Relacional: linhas, colunas e relações

Os dados ficam em tabelas com colunas definidas. No estoque, uma tabela produtos tem id, nome e preço; outra, movimentacoes, registra cada entrada e saída apontando para o id do produto. Você consulta tudo com SQL e o banco garante que uma movimentação não aponte para um produto que não existe.

Documentos: um registro com tudo dentro

Em bancos como o MongoDB, cada registro é um documento parecido com JSON. Um pedido pode carregar o cliente, os itens e o endereço juntos, sem tabelas separadas. A documentação do MongoDB sobre documentos mostra esse formato (BSON) em detalhe. É flexível: dois documentos da mesma coleção podem ter campos diferentes.

Chave-valor: guarda e busca pelo nome

Redis é o exemplo clássico. Você grava “sessao:8f2a” com um valor e lê de volta em microssegundos, normalmente com os dados mantidos em memória. Serve para cache, sessão de login, contadores e filas leves. Raramente é o banco principal de um sistema.

Relacional ou NoSQL lado a lado

Banco de dados certo começa pelo formato dos seus dados

Este é o critério que mais decide, e quase ninguém olha para ele primeiro. Pegue papel e escreva as “coisas” do seu sistema e como elas se ligam.

No controle de estoque: produto, fornecedor, movimentação, usuário. Um fornecedor tem muitos produtos, um produto tem muitas movimentações, cada movimentação foi feita por um usuário. Isso é uma teia de relações, e relações são o ponto forte do modelo relacional.

Agora pense num app que recebe leituras de sensores diferentes, cada um com campos próprios, e que quase nunca cruza um sensor com outro. Aí um banco de documentos encaixa melhor, porque cada leitura é autossuficiente.

Quando um erro custa dinheiro, escolha transações fortes

Se o sistema lida com saldo, pagamento, estoque ou qualquer número que não pode ficar errado, você quer transações: um bloco de operações que acontece por inteiro ou não acontece. O exemplo clássico é a transferência entre contas: debitar de uma e creditar na outra precisam dar certo juntos.

O tutorial oficial de transações do PostgreSQL usa justamente esse exemplo e mostra o BEGIN e o COMMIT em ação. Bancos relacionais fazem isso há décadas com muita maturidade, o que pesa a favor deles em sistemas de negócio.

SQLite merece mais respeito do que recebe

Muita gente trata o SQLite como “banco de brinquedo”. Ele é um arquivo único, sem servidor para instalar, e está dentro de praticamente todo celular e navegador. A página quando usar o SQLite, escrita pelos próprios autores, recomenda o banco para sites de tráfego baixo e médio, apps locais e análise de dados, e é honesta sobre onde ele não serve: muitos processos escrevendo ao mesmo tempo pela rede.

Para o primeiro projeto, aprender SQL com SQLite e depois migrar para PostgreSQL é um caminho tranquilo, porque a linguagem é quase a mesma.

Escala e custo pesam menos do que parece no começo

“Mas MongoDB escala melhor” é o argumento que mais aparece em fórum. Na prática, um PostgreSQL bem indexado num servidor modesto aguenta muito mais do que um projeto iniciante vai ver em anos. Escolher banco pensando em milhões de usuários antes de ter dez costuma gerar complexidade sem benefício.

O custo real costuma vir de outro lugar:

• backup automático e testado (restaurar de verdade pelo menos uma vez);
• plano gerenciado na nuvem versus instalar e manter você mesmo;
• tempo do time aprendendo uma tecnologia nova;
• migração futura se a escolha inicial foi errada.

Para quem trabalha com dados específicos, como vetores de busca semântica, existem opções dentro do próprio banco relacional. O guia sobre armazenar embeddings em projetos pequenos mostra um caso em que não foi preciso trocar de banco.

Sinais de que o banco escolhido está brigando com o projeto

Às vezes a escolha já foi feita e a dúvida é se foi a certa. Alguns sintomas ajudam a diagnosticar:

• Você copia o nome do cliente em dez documentos diferentes e, quando ele muda, metade fica desatualizada. É sinal de dados relacionais forçados num banco de documentos.
• Toda semana aparece uma migração para adicionar coluna opcional que só 5% dos registros usam. Talvez parte desses dados caiba numa coluna JSON (PostgreSQL tem o tipo jsonb) em vez de dezenas de colunas vazias.
• Consultas simples demoram segundos com poucos milhares de linhas. Quase sempre o problema é falta de índice, não o tipo de banco.
• O cache virou fonte de verdade e um reinício do Redis apagou informação que ninguém conseguia recriar.

Repare que só o primeiro e o último sintoma pedem troca de abordagem. Os outros se resolvem dentro do banco que você já tem, o que costuma ser bem mais barato do que migrar.

Banco de dados para cada projeto: escolhas rápidas

• Sistema de gestão, loja, agendamento, financeiro: PostgreSQL ou MySQL.
• App mobile offline, protótipo, ferramenta de linha de comando: SQLite.
• Catálogo com produtos de atributos muito variados, logs de eventos: MongoDB pode simplificar.
• Cache, sessão, ranking em tempo real: Redis ao lado do banco principal.
• Projeto de estudo sem servidor: SQLite primeiro, PostgreSQL quando for publicar.

Uma última recomendação direta: escolha um banco relacional, aprenda a modelar tabelas e escrever consultas com calma e só adote outro tipo quando sentir uma dor concreta que ele resolve. Essa ordem evita a maior parte das migrações dolorosas. Os termos técnicos deste texto, como esquema, índice e transação, estão explicados no glossário de programação do Buildbase, e o exemplo de modelagem de escalas em banco de dados de RH mostra como sair do papel para as tabelas.