Xentory
← Comparações // comparações · banco de dados

SQL ou NoSQL: o que muda de verdade

Os dois guardam o mesmo cadastro. O que muda é qual garantia cada um te dá de graça e qual ele cobra depois. Esta página coloca cada afirmação ao lado do documento oficial que a sustenta, com data.

A régua desta página. Nada aqui vem de benchmark nosso. Tudo sai de documentação oficial do próprio produto, de paper acadêmico ou de blog de engenharia da empresa que construiu a coisa, com os links no fim. Onde a fonte oficial não afirma, a página diz que não afirma.

Os dois modelos, no concreto

Três pessoas cadastradas. Uma delas tem telefone, as outras duas não. Repare no que acontece com quem não tem.

SQL, uma tabela

nomecidadetelefone
AnaRecifevazio
BrunoManausvazio
DaviBelém98 9876

A coluna existe para todo mundo. Quem não preenche fica com um buraco declarado.

NoSQL, documentos

nomeAna
cidadeRecife
nomeBruno
cidadeManaus
nomeDavi
cidadeBelém
telefone98 9876

Cada registro desses se chama documento, e o formato em que você escreve costuma ser JSON. O campo existe só em quem tem. Quem não tem nem sabe que ele existe.

A documentação do MongoDB descreve esse comportamento em uma frase: "MongoDB uses a flexible schema model. By default, documents in a collection don't need the same fields or data types". A mesma página recomenda impor validação depois que a aplicação amadurece, o que já entrega o preço junto com a vantagem.

Uma ressalva antes da tabela. NoSQL é guarda-chuva, e documento é só uma família dentro dele. Chave-valor (DynamoDB, Redis), coluna larga (Cassandra) e grafo têm contas próprias, e é por isso que a tabela abaixo cita cada produto pelo nome em vez de falar de "NoSQL" como se fosse uma coisa só.

As cinco diferenças que decidem

quando vocêrelacionaldocumento ou chave-valor
acrescenta um campo Muda o formato para todos os registros, inclusive os que nunca vão preencher. O campo entra só em quem precisa, na hora.
pergunta quem tem um campo Uma coluna responde pela tabela inteira. A resposta está espalhada, registro por registro.
liga dois conjuntos de dados O join está no modelo desde 1970 e o banco resolve. Depende. O MongoDB tem $lookup, o Cassandra não tem join nenhum e manda duplicar o dado.
precisa crescer O caminho curto é máquina maior. Espalhar dá trabalho. Foi desenhado para somar máquinas, com custo em complexidade de operação.
precisa de transação Padrão da casa desde sempre. Existe hoje na maioria, com limites duros e documentados.

A frase que mais resume a decisão veio da própria AWS, que vende o lado NoSQL. A tabela oficial de comparação deles coloca "ad hoc queries, data warehousing, OLAP" como carga ideal do relacional, e "web-scale applications" como carga ideal do DynamoDB. Quem construiu o produto sabe onde ele não é a melhor escolha.

Sete coisas que se lê por aí e a documentação desmente

Comparações de SQL contra NoSQL envelheceram mal. Boa parte do que circula descreve um mundo que acabou em 2018.

1. "O teorema CAP obriga a escolher dois de três"

O autor do teorema desmentiu isso ele mesmo. Eric Brewer escreveu que "a formulação '2 de 3' sempre foi enganosa porque tendia a simplificar demais as tensões entre as propriedades", e que o teorema "proíbe apenas uma fatia minúscula do espaço de projeto: disponibilidade e consistência perfeitas na presença de partições, que são raras".

Eric Brewer, CAP Twelve Years Later. IEEE Computer, 02/2012.

2. "Dá para escolher CA e viver sem partição"

Brewer responde direto: se a escolha for CA e uma partição acontecer, a escolha volta a ser C ou A. Cinco anos depois ele foi mais duro, no whitepaper do Spanner: "você não tem direito a 2 de 3, e muitos sistemas têm zero ou uma das propriedades".

Eric Brewer, Spanner, TrueTime and the CAP Theorem. Google, 14/02/2017.

3. "NoSQL não tem transação"

Isso deixou de valer em 2018. O MongoDB tem transação multi-documento em replica set desde a versão 4.0 e em cluster shardeado desde a 4.2. O DynamoDB tem TransactWriteItems com garantia ACID declarada na documentação. O Cosmos DB declara "full ACID compliant transactions with snapshot isolation" dentro de uma partição lógica.

MongoDB Manual, Transactions · DynamoDB Developer Guide · Microsoft Learn. Consultados em 02/08/2026.

4. "Então a transação do NoSQL é igual à do relacional"

O mito contrário também é falso, e os limites estão publicados. No DynamoDB, no máximo 100 itens e 4 MB por transação, e nada atravessa Região. No Cosmos DB, uma partição lógica só, 100 operações, 2 MB e 5 segundos. No MongoDB, o tempo de vida padrão fica abaixo de um minuto. No Cassandra, um batch em várias partições não tem isolamento, e o cliente pode ler metade do trabalho. O Redis não faz rollback, e a documentação explica que isso foi decisão de projeto.

DynamoDB, Transaction APIs · MongoDB, Production Considerations · Cassandra, Guarantees · Redis, Transactions.

5. "Banco relacional não lida com dado flexível"

O PostgreSQL tem o tipo jsonb desde a versão 9.4, lançada em 18/12/2014, com índice GIN e linguagem de caminho própria. O MySQL tem tipo JSON nativo desde a 5.7, com validação na inserção. A convergência aconteceu nas duas direções, e faz mais de dez anos.

PostgreSQL, JSON Types · Release Notes 9.4 · MySQL 8.4 Reference Manual.

6. "Quem nasceu NoSQL fica NoSQL"

O Spanner do Google fez o caminho inverso e publicou o porquê: "o Spanner começou como um key-value store, e nos últimos 7 anos evoluiu para um sistema de banco de dados relacional". O motivo declarado foi a dificuldade dos próprios desenvolvedores do Google de construir aplicações sem schema forte, transação entre linhas e linguagem de consulta.

Bacon et al., Spanner: Becoming a SQL System. SIGMOD, 05/2017.

7. "BASE nasceu com o Dynamo, na onda NoSQL"

BASE é bem mais velho. Brewer conta que o termo saiu do grupo dele no fim dos anos 1990, quase dez anos antes do paper do Dynamo, para descrever escolhas de projeto que já estavam aparecendo. O trabalho de origem que ele aponta é de 1997.

Eric Brewer, CAP Twelve Years Later, quadro lateral. IEEE Computer, 02/2012.

Um detalhe que confunde quase todo mundo

A letra C de ACID e a letra C de CAP não querem dizer a mesma coisa. Brewer explica no mesmo artigo: no ACID, o C significa que a transação preserva todas as regras do banco, como chave única. No CAP, o C fala só de ter uma cópia única e atualizada do dado, o que é um subconjunto estrito do C de ACID. Discussões inteiras já morreram nessa confusão.

Nem ACID é um selo binário. O paper que definiu Snapshot Isolation mostrou em 1995 que as definições ANSI de isolamento são ambíguas, e o PostgreSQL documenta os próprios desvios: Read Uncommitted se comporta como Read Committed, e Repeatable Read não deixa passar phantom read.

Como escolher, sem torcida

  1. Liste as perguntas antes dos campos. A documentação do Cassandra chama isso de modelagem dirigida por consulta, e diz na cara que os padrões de acesso determinam a estrutura. Se você ainda não sabe o que vai perguntar, formato fixo vai te atrapalhar cedo.
  2. Veja se o dado nasce junto. O princípio que o MongoDB publica é curto: dado acessado junto fica guardado junto. Quando isso é verdade no seu caso, documento paga. Quando o mesmo dado é acessado de cinco ângulos diferentes, ele começa a doer.
  3. Conte quantos lugares precisam concordar ao mesmo tempo. Transação existe nos dois lados hoje. O que muda é o alcance. Se a sua operação toca 300 itens em duas Regiões, os limites publicados já respondem por você.
  4. Pergunte quem vai operar. A doc de sharding do MongoDB avisa que cluster shardeado exige planejamento, execução e manutenção cuidadosos, e que migrar faixas de dado é lento e pesado. Escala horizontal é uma conta de operação, não só de arquitetura.
  5. Desconfie de comparação sem data. Metade do que se acha sobre isso descreve 2015.

Fontes

Duas honestidades sobre o levantamento. O acrônimo ACID é atribuído a Härder e Reuter, 1983, e o texto está atrás de paywall, então esta página não cita frase literal dele. O padrão ISO/IEC 9075-2 é pago, então em nenhum lugar aqui se afirma o que o padrão diz com todas as letras. E os links da ACM ficaram de fora porque o site bloqueia acesso automatizado, o que impede a conferência.

Achou imprecisão? Fala com a gente que a gente corrige e registra a correção nesta página.

// conteúdo exclusivo

A próxima comparação, com as fontes na mesa.

Cada decisão de arquitetura destrinchada assim, com documento oficial e data em tudo. Chega no seu e-mail junto com o aviso de curso gratuito novo no ar.

Seu e-mail é usado só pra isso. Dá pra sair em um clique em qualquer mensagem, como está na política de privacidade.