SQL ou NoSQL: qual banco escolher

"SQL ou NoSQL" parece uma escolha entre dois produtos, mas não é. SQL é uma linguagem de consulta e, por extensão, o modelo relacional por trás dela. NoSQL é um guarda-chuva para tudo que não segue esse modelo: bancos de documentos, chave-valor, colunares, de grafos. Comparar os dois é comparar formas de organizar dados.

A decisão importa porque trocar de banco depois custa caro: você reescreve consultas, migra dados e refaz testes. Por isso vale escolher pelo formato dos seus dados e pela forma como você os acessa, não pela moda.

O que é um banco SQL?#

Um banco SQL (relacional) guarda dados em tabelas de linhas e colunas. Você define o esquema antes: nomes das colunas, tipos e restrições. As tabelas se ligam por chaves estrangeiras, e a consulta cruza tudo com JOIN.

Exemplos comuns são PostgreSQL, MySQL e SQLite. A promessa central é a integridade: o banco recusa um pedido que aponte para um usuário inexistente, e uma transação garante que um conjunto de gravações acontece por inteiro ou não acontece.

O que é um banco NoSQL?#

"NoSQL" não descreve um modelo, descreve uma ausência. Os tipos mais usados por quem hospeda bots, APIs e sites são:

• Documentos (MongoDB): objetos parecidos com JSON, agrupados em collections. Cada documento pode ter listas e objetos aninhados.
• Chave-valor e estruturas em memória (Redis): acesso por chave, com tipos como strings, hashes, listas, sets e sorted sets, segundo a documentação do Redis.
• Colunares e de grafos: para análise em larga escala e redes de relações. Ficam fora do escopo da maioria dos projetos pequenos.

O que une esses bancos é a escolha de abrir mão de parte do modelo relacional em troca de outra vantagem: formato flexível, acesso direto por chave ou facilidade de distribuir dados entre servidores.

Qual a diferença entre SQL e NoSQL, lado a lado?#

A tabela é uma tendência, não uma lei. O PostgreSQL guarda JSON com o tipo jsonb, e o MongoDB tem transações e validação de esquema. As fronteiras se misturam, por isso o critério certo é o seu padrão de acesso, não o rótulo.

Como o mesmo dado fica em cada modelo?#

Pegue um pedido com itens. No modelo relacional, ele se divide em tabelas:

CREATE TABLE pedidos (
  id         serial PRIMARY KEY,
  usuario_id integer NOT NULL,
  criado_em  timestamptz NOT NULL DEFAULT now()
);

CREATE TABLE itens_pedido (
  pedido_id  integer NOT NULL REFERENCES pedidos (id),
  produto    text NOT NULL,
  quantidade integer NOT NULL CHECK (quantidade > 0),
  PRIMARY KEY (pedido_id, produto)
);

SELECT p.id, i.produto, i.quantidade
FROM pedidos p
JOIN itens_pedido i ON i.pedido_id = p.id
WHERE p.usuario_id = 42;

No modelo de documentos, o mesmo pedido vira um objeto só, com os itens dentro (exemplo no mongosh):

db.pedidos.insertOne({
  usuarioId: 42,
  criadoEm: new Date(),
  itens: [
    { produto: "Camiseta", quantidade: 2 },
    { produto: "Caneca", quantidade: 1 },
  ],
});

db.pedidos.find({ usuarioId: 42 });

Ler o pedido completo é uma operação só, sem junção. O preço aparece quando o mesmo dado é consultado por outro ângulo, por exemplo "quais pedidos contêm Caneca": no modelo relacional isso é um índice e um JOIN, e no modelo de documentos você depende de um índice sobre o campo aninhado e de manter os dados consistentes na aplicação.

Quando as transações decidem a escolha?#

Transferir saldo entre duas contas só pode acontecer por inteiro. Em SQL isso é natural:

BEGIN;
UPDATE contas SET saldo = saldo - 100 WHERE id = 1;
UPDATE contas SET saldo = saldo + 100 WHERE id = 2;
COMMIT;

No PostgreSQL, o nível de isolamento padrão é o Read Committed, e é possível subir para Repeatable Read ou Serializable quando a lógica exigir, segundo a documentação.

O MongoDB suporta transações entre vários documentos, mas a documentação avisa que elas costumam custar mais que gravações em um documento só e recomenda embutir os dados como primeira opção de modelagem.

A regra prática: se o seu domínio vive de transações entre muitas entidades (saldos, estoque, pagamentos), o modelo relacional é o ajuste natural. Se cada operação mexe num objeto só, o modelo de documentos serve bem.

E o esquema flexível, é vantagem ou risco?#

Num banco de documentos, a collection aceita documentos com campos diferentes. Isso acelera o início do projeto e ajuda com dados heterogêneos, como catálogos em que cada produto tem atributos próprios. A documentação do MongoDB descreve esse modelo flexível e a validação de esquema para quando você quiser travar o formato.

O risco é o esquema implícito: sem regras, cada versão do código grava de um jeito e a leitura precisa tratar todas as variações. Num banco relacional, a migração é mais trabalhosa, mas o banco garante que todo registro obedece à estrutura. O meio-termo existe: o PostgreSQL combina colunas fixas com um campo jsonb indexável, o que cobre muitos casos "meio flexíveis" sem trocar de banco.

Como escolher entre SQL e NoSQL?#

Faça quatro perguntas:

1. Os dados têm relações fortes entre si? Usuários, pedidos, assinaturas e inventário apontam uns para os outros. SQL.
2. Você lê e grava o objeto inteiro de uma vez? Configuração por servidor de Discord, perfil com campos opcionais. Documentos funcionam bem, e o PostgreSQL com jsonb também.
3. O acesso é por chave, e perder o dado é tolerável? Cache, sessão, cooldown, rate limit. Redis. Ele pode gravar em disco (veja a documentação de persistência), mas foi pensado para dados que cabem na memória.
4. O formato muda toda semana? Num protótipo, a flexibilidade ajuda. Em produção, avalie quanto vale impor estrutura.

Sem uma razão clara para o contrário, um banco relacional é o ponto de partida mais seguro. Para decidir dentro de cada família, veja qual banco de dados escolher, PostgreSQL ou MySQL e o que é MongoDB. Para o papel do Redis ao lado de outro banco, leia Redis como cache ou como banco.

Como fazer isso na Square Cloud#

A Square Cloud oferece hospedagem de MongoDB, PostgreSQL, MySQL e Redis, a partir do plano Standard. O plano Hobby não inclui hospedagem de bancos. Assim, você tem os dois lados da comparação: SQL com PostgreSQL ou MySQL, NoSQL com MongoDB ou Redis.

Você cria o banco no painel, e ele fica pronto em segundos no mesmo datacenter das suas aplicações, com latência média de cerca de 1 ms e TLS obrigatório. Combinar dois motores no mesmo projeto, como PostgreSQL para os dados permanentes e Redis para cache, é só criar os dois e guardar as URLs de conexão em variáveis de ambiente. O número de bancos só é limitado pela RAM do plano: cada um usa no mínimo 512 MB (Redis) ou 1024 MB (os outros).

Você tira snapshots manuais quando quiser, e todo plano com bancos inclui também um snapshot automático diário. Dá para restaurar um snapshot no mesmo banco, em outro do mesmo motor ou num banco novo. O Redis tem persistência, e o PostgreSQL é o nativo, sem extensões. Veja as opções em Bancos de dados.