Qual banco de dados escolher para o seu projeto

Escolher o banco de dados é uma das decisões mais difíceis de desfazer num projeto. Trocar de banco depois significa reescrever consultas, migrar dados e testar tudo de novo. Por isso vale gastar meia hora pensando antes de rodar o primeiro CREATE TABLE.

A boa notícia é que a escolha raramente é dramática. Cinco bancos cobrem quase tudo de que bots, APIs e sites precisam: PostgreSQL, MySQL, MongoDB, Redis e SQLite.

Quais critérios definem a escolha?#

Quatro perguntas resolvem a maioria dos casos:

1. Qual é o formato dos dados? Registros com colunas fixas e relações entre si (usuários, pedidos, produtos) pedem um banco relacional. Documentos com campos que variam de item para item pedem um banco de documentos.
2. Você precisa de consistência entre várias gravações? Transferir saldo entre duas contas só pode acontecer por inteiro ou não acontecer. Isso é uma transação, e os bancos relacionais foram feitos em torno dela.
3. Como você vai ler os dados? Buscas por chave exata e muito rápidas (sessão, contador, cooldown) favorecem Redis. Relatórios que cruzam tabelas favorecem SQL.
4. Quantos processos acessam o banco? Um único processo na mesma máquina pode usar um arquivo (SQLite). Vários servidores ou aplicações pedem um servidor de banco acessado pela rede.

Responda essas quatro e a lista de candidatos cai para um ou dois.

Quando escolher PostgreSQL ou MySQL?#

São dois bancos relacionais muito usados. Guardam dados em tabelas, relacionam tabelas com chaves estrangeiras e consultam tudo com SQL. Ambos têm transações completas: no MySQL, o mecanismo padrão InnoDB segue o modelo ACID e suporta chaves estrangeiras.

Escolha um deles quando os dados têm estrutura clara e relações: cadastro de usuários, loja virtual, sistema de assinaturas, economia de um bot com inventário e moedas. É a aposta segura quando você está em dúvida.

PostgreSQL tem extensões, tipos avançados e o tipo jsonb, que guarda JSON com suporte a índices. Isso permite misturar colunas fixas com um campo flexível na mesma tabela:

CREATE TABLE produtos (
  id      serial PRIMARY KEY,
  nome    text NOT NULL,
  preco   numeric(10, 2) NOT NULL,
  extras  jsonb NOT NULL DEFAULT '{}'
);

CREATE INDEX produtos_extras_idx ON produtos USING GIN (extras);

INSERT INTO produtos (nome, preco, extras)
VALUES ('Camiseta', 59.90, '{"tamanhos": ["P", "M", "G"], "cor": "preto"}');

SELECT nome FROM produtos WHERE extras @> '{"cor": "preto"}';

MySQL é muito popular em hospedagens e no ecossistema PHP, com ferramentas e tutoriais em abundância. Para um projeto novo sem restrições, a diferença prática entre os dois costuma ser pequena. Veja a comparação detalhada em PostgreSQL ou MySQL: qual escolher.

Quando escolher MongoDB?#

O MongoDB guarda documentos (parecidos com JSON) em collections, sem esquema obrigatório. Cada documento pode ter campos diferentes e carregar listas e objetos aninhados dentro de si.

Funciona bem quando você lê e grava o objeto inteiro de uma vez: configurações por servidor do Discord, perfis com campos opcionais, catálogos em que cada item tem atributos próprios. A flexibilidade acelera o início do projeto, porque mudar o formato não exige migração.

Dois cuidados. Primeiro, sem esquema, a validação passa a ser sua responsabilidade (no código ou em regras de validação do banco). Segundo, o MongoDB suporta transações entre vários documentos, mas a própria documentação diz que, na maioria dos casos, elas custam mais que gravações em um só documento. Elas também não substituem uma boa modelagem, porque documentos embutidos já reduzem a necessidade de transações. Se você já está escrevendo muitas relações e transações, provavelmente quer um banco relacional. Veja o que é MongoDB e para que serve.

Quando escolher Redis?#

O Redis guarda tudo em memória, com acesso por chave, e é muito rápido. Seu papel clássico é ser o segundo banco: cache de respostas, sessões, filas, contadores, limites de requisições e cooldowns de comandos de bot.

Ele pode gravar em disco. A documentação oficial descreve duas formas: RDB (fotografias do conjunto de dados em intervalos) e AOF (um registro de cada gravação). Com RDB sozinho, uma queda pode custar os últimos minutos de dados. Com AOF e o padrão de sincronizar a cada segundo, o risco cai para cerca de um segundo de gravações. Mesmo assim, o Redis foi desenhado para dados que cabem na memória, então não o use como banco principal de dados que você não pode perder ou que crescem sem parar.

Regra prática: se perder o dado é um incômodo (o cache esquenta de novo), Redis é ótimo. Se perder o dado é um prejuízo (pedidos, pagamentos), o dado mora num banco relacional ou de documentos. Mais em o que é Redis e para que serve.

E o SQLite?#

O SQLite é um banco inteiro dentro de um arquivo, sem servidor. A documentação do projeto o posiciona como alternativa a abrir arquivos com fopen(), não como concorrente dos bancos cliente-servidor. É excelente para protótipos, ferramentas de linha de comando, apps desktop e bots pequenos de um único processo.

O limite está na concorrência: o SQLite aceita vários leitores, mas só um escritor por vez, e a documentação recomenda evitar o acesso direto ao mesmo arquivo por vários computadores pela rede. Quando seu projeto passar a ter mais de um servidor ou muitas escritas simultâneas, migre para PostgreSQL ou MySQL. Começar no SQLite e migrar depois é um caminho legítimo, desde que você use SQL padrão e evite recursos exclusivos.

Qual banco para cada tipo de projeto?#

Na dúvida, escolha PostgreSQL. Ele cobre o caso relacional e boa parte do caso flexível, e raramente vira motivo de arrependimento.

Como fazer isso na Square Cloud#

Os bancos cliente-servidor da tabela (MongoDB, PostgreSQL, MySQL e Redis) têm hospedagem na Square Cloud a partir do plano Standard; o Hobby não inclui bancos. Você cria o banco no painel (nome, memória e motor), e ele fica pronto em segundos no mesmo datacenter das aplicações, com latência média de cerca de 1 ms e TLS obrigatório. Se você seguir o "na dúvida, PostgreSQL", saiba que é o PostgreSQL nativo, sem extensões.

O padrão da FAQ, dados permanentes num banco relacional e Redis como cache ou fila, cabe num plano só. Motores diferentes convivem, limitados só pela RAM do plano: no mínimo 1024 MB para PostgreSQL, MySQL e MongoDB e 512 MB para o Redis. Um PostgreSQL e um Redis juntos ocupam 1,5 GB dos 4 GB do Standard de entrada. Cada um tem a própria URL de conexão, que o painel entrega e você guarda numa variável de ambiente da aplicação.

O SQLite também tem lugar: o disco de cada aplicação persiste entre restarts e deploys, então um bot de um processo só pode manter o arquivo .db ali. Deixe esse arquivo fora do ZIP de deploy, porque um commit sobrescreve os arquivos que estão no pacote. O critério 4 continua valendo: aplicações num load balancing não compartilham disco, então, a partir de dois processos, o caminho é um banco servidor.

Para os dados que não podem se perder, você tira snapshots manuais quando quiser, e todo plano com bancos faz também um snapshot automático diário. Veja os bancos disponíveis hoje em Bancos de dados.