NoSQL: quando faz sentido

O termo "NoSQL" foi cunhado em 2009 numa conferência informal em San Francisco, e por uma década carregou sentido moralista: SQL era legado, NoSQL era o futuro. A onda gerou uma pluralidade de sistemas — MongoDB, Cassandra, Redis, Neo4j, DynamoDB, e dezenas de outros — cada um com modelo de dados próprio, garantias próprias e armadilhas próprias. Quinze anos depois, a poeira assentou. NoSQL não substituiu SQL; conviveu com ele. Mais importante: o entendimento maduro hoje é que cada storage tem cabimento específico, e a habilidade sênior é saber reconhecer quando.

Este conceito é menos "tutorial de Mongo" e mais "framework de decisão". O foco é entender as quatro grandes famílias NoSQL (mais a emergente família vector), o que cada uma sacrifica em troca do que oferece, e os critérios para escolher conscientemente. Termina com o caminho de retorno: como sistemas que começaram em NoSQL frequentemente migram (parcial ou totalmente) para SQL — e o que aprender desses casos.

O contexto histórico — por que NoSQL apareceu

No fim dos anos 2000, três pressões reais empurraram a indústria para fora de SQL relacional puro. Empresas web tinham volumes de dados que rompiam a verticalização (Google, Facebook, Amazon operavam escalas que Oracle/MySQL/Postgres não escalavam horizontalmente bem). Schemas evoluíam mais rápido que migrations podiam acompanhar — produtos que iteravam diariamente brigavam com schemas rígidos. E tipos de dados específicos (séries temporais, grafos sociais, logs) eram mal-servidos por tabelas relacionais.

Os trabalhos que detonaram a onda: Bigtable (Chang et al., 2006) descreveu a abordagem column-family do Google; Dynamo (DeCandia et al., 2007) descreveu o sistema key-value altamente disponível da Amazon, e o teorema CAP (Eric Brewer, 2000; provado por Gilbert e Lynch em 2002) formalizou os trade-offs entre consistência, disponibilidade e tolerância a partições. Esses três artigos juntos fizeram pensar que o relacional teria que ser substituído. Não aconteceu — mas mudou o que se construiu em paralelo.

CAP, BASE e o que de fato significa

O teorema CAP diz: em sistema distribuído, na presença de partições de rede (P inevitável), você escolhe entre Consistência forte (C) e Disponibilidade (A). Não é os três; é dois. Em operação normal sem partição, sistemas podem oferecer ambos — o trade-off só pesa durante falha.

Sistemas SQL tradicionais tendem ao "CP": diante de partição, preferem indisponibilidade a inconsistência. NoSQLs como Cassandra e Dynamo tendem ao "AP": diante de partição, preferem responder com possível dado stale a recusar atender. A escolha depende do domínio: sistema bancário precisa CP (saldo errado é inaceitável); cache de feed social pode AP (timeline atrasada por segundos é tolerável).

BASE — Basically Available, Soft state, Eventual consistency — é o oposto deliberado de ACID. Reconhece que consistência forte tem custo, e propõe modelo onde o sistema converge para consistência ao longo do tempo, em vez de garantir instantaneamente. Em sistemas AP, BASE é o vocabulário operacional: você escreve em qualquer nó, propagação acontece em background, leitura pode ver versão antiga até convergir.

A nuance perdida: "eventually consistent" sem prazo é só "inconsistent". Sistemas BASE bem-projetados definem janelas — em condições normais, propagação em milissegundos; em falha, segundos a minutos; SLA de convergência. Sem esse cuidado, "eventual" vira hand-wave.

Document — MongoDB, CouchDB, DocumentDB

Documentos são objetos JSON-like com schema implícito. Cada documento é independente: pode ter campos diferentes do vizinho. Coleções agrupam documentos relacionados. Não há joins (em formas mais puras); relacionamentos são embedados ou referenciados.

O que MongoDB e similares fazem bem:

• Agregados naturalmente embedados: um pedido com itens pode ser um único documento. Toda a "transação" cabe em um lugar; leitura/escrita do agregado é atômica.
• Schemas em evolução rápida: adicionar campo é trivial. Útil onde o dado realmente é heterogêneo.
• Sharding nativo: MongoDB shard-a por chave de partição automaticamente. Escala horizontal sem re-arquitetura.

Onde costuma falhar:

• Quando o dado tem relacionamentos: o "embed everything" colapsa quando o cliente é referenciado em pedidos, faturas e tickets. Atualizar o nome do cliente em todos os lugares vira saga distribuída — em SQL é um update.
• Transações multi-documento: MongoDB suporta desde 4.0, mas a primitiva é cara. O modelo encoraja agregados como unidade transacional; quando o domínio quer mais, atrita.
• Queries ad-hoc analíticas: SELECT SUM(...) FROM ... JOIN ... GROUP BY ... em SQL é uma linha; em Mongo, uma aggregation pipeline complexa.

Quando MongoDB faz sentido: domínio que genuinamente é catálogo de objetos heterogêneos com poucos relacionamentos cruzados — catálogos de produto com atributos por categoria muito variados, configurações por tenant, eventos brutos antes de processamento. Em domínios relacionais reais, Postgres com JSONB cobre 90% do que MongoDB ofereceria, com transações fortes.

Key-Value — Redis, Memcached, DynamoDB

A primitiva: set(key, value), get(key). Sem schema, sem queries em valor, sem joins. Apenas lookup por chave, na ordem de microssegundos quando em memória.

Categoria menos sobre "armazenar dados" e mais sobre acelerar acesso. Redis se tornou ferramenta universal para:

• Cache: a aplicação mais clássica. Memoizar resultado de query SQL com TTL. Reduz P99 dramaticamente.
• Sessions: dado pequeno, acessado a cada request, lifetime conhecido. Redis encaixa bem.
• Rate limiting: contadores TTL com operações atômicas. INCR, EXPIRE são primitivas exatamente para isso.
• Leaderboards: estruturas de sorted set implementam ranking eficiente.
• Filas leves: listas com LPUSH/ BRPOP dão fila básica. Para volumes maiores, ferramentas dedicadas (RabbitMQ, Kafka) são melhores.
• Pub/Sub e streams: Redis Streams (5.0+) oferece event log persistente.

DynamoDB é diferente: KV gerenciado da AWS com modelo de capacidade pré-paga, sharding automático, e disponibilidade altíssima por design. Escolha para sistemas com perfis de acesso muito conhecidos e necessidade de latência consistente em escala. Modelagem em DynamoDB é arte própria — Rick Houlihan da AWS é referência aqui.

Quando KV faz sentido: caches, sessões, rate limiting, contadores, lookups por chave conhecida, estruturas auxiliares onde latência sub-milissegundo importa. Não é substituto para banco — é complemento. Sistemas maduros usam Redis e Postgres, cada um onde brilha.

Column-family — Cassandra, ScyllaDB, HBase, BigTable

Modelo derivado do Bigtable do Google. Visualize uma estrutura esparsa onde cada linha tem chave primária composta (partition key + clustering key), e colunas podem ser adicionadas dinamicamente por linha. Linhas de uma partição ficam fisicamente juntas; queries leem partições inteiras eficientemente.

Cassandra (e seu sucessor mais rápido, ScyllaDB) brilham em:

• Volumes massivos com escrita pesada: bilhões de linhas, taxa de escrita absurda. Distribuído por design.
• Time-series e logs: partition key por entidade + clustering key por timestamp dá leitura sequencial dentro de partição, ideal para "últimos N eventos do usuário X".
• Disponibilidade priorizada: sistema AP por excelência. Tolera nós em queda; quórum configurável por operação.

Onde sofre:

• Consultas ad-hoc: queries que não seguem o padrão da chave primária custam caro. CQL parece SQL mas é restrito; JOIN não existe; secondary indexes têm pegadinhas conhecidas.
• Modelagem é por query: você desenha tabelas para queries específicas. Mudar o padrão de acesso exige nova tabela e backfill. O que SQL deixa flexível, Cassandra cobra antecipadamente.
• Transações: Lightweight Transactions (Paxos) existem mas são caras. Não é o ponto de Cassandra.

Quando faz sentido: dados time-series em escala (métricas de IoT, logs de aplicação), feeds onde writes superam reads em ordens de magnitude, sistemas distribuídos geograficamente onde disponibilidade trumps consistência forte. Para sistema de negócio comum, Cassandra é overkill cuja complexidade não compensa.

Graph — Neo4j, Amazon Neptune, ArangoDB

Modelo onde nós (entidades) e arestas (relacionamentos) são cidadãos de primeira classe. Queries percorrem o grafo naturalmente — "amigos de amigos do João que moram em São Paulo" é uma travessia direta, não um auto-join encadeado.

Onde graph databases ganham claramente do relacional: queries de profundidade variável (5+ saltos) sobre conexões. Com SQL, cada salto é um JOIN; cinco saltos viram queries impossíveis de otimizar. Graph DB executa em tempo proporcional ao subgrafo explorado.

Casos canônicos:

• Detecção de fraude (caminhos suspeitos entre contas).
• Recomendação ("usuários como você também...").
• Redes sociais (graph é literalmente o modelo).
• Knowledge graphs em IA.
• Gestão de identidade complexa (RBAC com herança aninhada).

O desafio operacional: graph databases são, em geral, menos maduros que Postgres em durabilidade, ferramentas, comunidade. Postgres com extensão Apache AGE oferece grafos sobre Postgres, e é boa opção quando o sistema é majoritariamente relacional com algumas queries de grafo.

Vector — pgvector, Pinecone, Weaviate, Qdrant

A categoria emergente. Vetores (arrays de números, tipicamente 384-1536 dimensões) representam embeddings semânticos produzidos por modelos como text-embedding-3, BGE, E5. Vector DBs especializam-se em busca por similaridade — "documentos mais similares a este texto", "imagens mais parecidas a essa".

Algoritmos centrais: HNSW (Hierarchical Navigable Small World), IVFFlat, ScaNN. Todos balanceiam precisão vs latência via aproximação — busca exata em milhões de vetores não escala; busca aproximada (ANN) entrega 95%+ de precisão em milissegundos.

A questão de 2024-2026: Postgres com pgvector é suficiente para o seu caso, ou você precisa de DB dedicado? Para volumes até dezenas de milhões de vetores e necessidade de filtragem combinada (vetor + metadados SQL), pgvector é excelente. Para bilhões de vetores ou necessidade de indexação especializada (filtros multi-vetor, multi-tenancy em escala), DBs dedicados ainda ganham.

Padrão emergente sênior: RAG sobre Postgres — embeddings em pgvector, dado relacional na mesma instância, JOINs naturais entre semântica e SQL. Reduz infra, mantém ACID sobre o conjunto.

Polyglot persistence — usar vários, com critério

Sistemas maduros raramente usam só um banco. Padrão típico:

• Postgres como source of truth para dados de domínio.
• Redis para cache, sessões, contadores.
• Elasticsearch ou OpenSearch para busca full-text avançada (quando Postgres FTS não basta).
• Object storage (S3) para blobs.
• ClickHouse, BigQuery ou Snowflake para analytics OLAP.

A regra é: cada storage adicionado é complexidade adicional. Backups separados, monitoramento separado, runbooks separados, expertise no time. Adicione apenas quando o ganho do storage especializado supera o custo operacional — e quando o time tem capacidade para cuidar de todos.

Sistemas pequenos a médios fazem bem com Postgres-only por muito tempo. "Just use Postgres for everything" virou provocação justamente porque é defensável: full-text search via tsvector, filas via SKIP LOCKED, cache via tabelas e UNLOGGED, vetores via pgvector, time-series via partitioning ou TimescaleDB. Postgres come um terço da complexidade que vinha justificada por usar quatro bancos.

O caminho de volta — quando NoSQL volta a SQL

Casos públicos de migração reversa formaram um sub-gênero da indústria nos últimos anos:

• Etsy moveu workloads de MongoDB para Postgres após anos de operação difícil.
• Foursquare, Discourse, Disqus — todos relataram migrar parte dos dados de NoSQL de volta para SQL conforme amadureciam.
• Crunchbase documentou volta de MongoDB para Postgres. Tom Wilkie (Grafana Labs) escreveu sobre o mesmo movimento na infraestrutura deles.

Padrões comuns nessas histórias:

1. Domínio se mostrou mais relacional do que parecia.
2. Operação de NoSQL exigiu times maiores que SQL equivalente.
3. Garantias de consistência viraram requisito (compliance, audit).
4. Custo total (infra + pessoas) ficou maior que SQL bem-tunado.

A lição não é "NoSQL é ruim". É: escolha consciente bate moda. Hype te faz adotar; entender o trade-off te permite ficar.

Acesso aos diferentes storages — visão geral

// Postgres (relacional + JSONB + pgvector)
await using var conn = await npgsqlDataSource.OpenConnectionAsync();
await conn.ExecuteAsync(
    "INSERT INTO docs(id, conteudo, embedding) VALUES (@id, @c, @v)",
    new { id, c = conteudo, v = new Vector(embedding) });

// Redis (StackExchange.Redis)
var db = redis.GetDatabase();
await db.StringSetAsync($"sess:{token}", json, TimeSpan.FromMinutes(30));
await db.SortedSetAddAsync("ranking:diario", userId, score);

// MongoDB (oficial driver)
var pedidos = mongoDb.GetCollection<Pedido>("pedidos");
await pedidos.InsertOneAsync(new Pedido {
    ClienteId = id, Itens = items, CriadoEm = DateTime.UtcNow });

// Neo4j (driver oficial)
await using var session = neo4j.AsyncSession();
await session.RunAsync(
    "MATCH (u:Usuario {id: $id})-[:SEGUE*1..3]->(amigo) RETURN amigo",
    new { id });

# Postgres + pgvector via SQLAlchemy
from sqlalchemy import insert
from pgvector.sqlalchemy import Vector
session.execute(insert(Doc), {"id": id, "conteudo": c, "embedding": v})

# Redis (redis-py async)
async with redis_client.pipeline() as pipe:
    await pipe.set(f"sess:{token}", json_data, ex=1800).execute()
    await pipe.zadd("ranking:diario", {user_id: score}).execute()

# MongoDB (motor async)
await motor_db.pedidos.insert_one({
    "cliente_id": id, "itens": items, "criado_em": datetime.utcnow()
})

# Neo4j
async with neo4j_driver.session() as session:
    result = await session.run(
        "MATCH (u:Usuario {id: $id})-[:SEGUE*1..3]->(a) RETURN a",
        id=user_id)

// Postgres (pgx)
_, err := pool.Exec(ctx,
    `INSERT INTO docs(id, conteudo, embedding) VALUES ($1, $2, $3)`,
    id, conteudo, pgvector.NewVector(embedding))

// Redis (go-redis/v9)
err = rdb.Set(ctx, "sess:"+token, json, 30*time.Minute).Err()
rdb.ZAdd(ctx, "ranking:diario", redis.Z{Score: score, Member: userID})

// MongoDB (mongo-go-driver)
_, err = mongoDB.Collection("pedidos").InsertOne(ctx, bson.M{
    "cliente_id": id, "itens": items, "criado_em": time.Now(),
})

// Neo4j (driver oficial)
result, err := neo4j.ExecuteRead(ctx, session,
    func(tx neo4j.ManagedTransaction) (any, error) {
        return tx.Run(ctx,
            "MATCH (u:Usuario {id: $id})-[:SEGUE*1..3]->(a) RETURN a",
            map[string]any{"id": userID})
    })

Framework de decisão — perguntas a fazer

Quando alguém propõe um storage novo no sistema, oito perguntas:

1. Qual problema concreto não resolve com o storage atual? Se a resposta é "nada específico, mas seria moderno", já está respondida.
2. Qual SLA de consistência o domínio exige? Algum dado precisa ser perfeitamente consistente? Pode ficar eventual?
3. Qual o volume real? Linhas, escrita por segundo, leitura por segundo, em produção. Não estimativa, números medidos. Postgres sobre hardware decente cobre uma faixa muito maior do que reflexo de "Postgres não escala" sugere.
4. Quais queries / padrões de acesso? Lookups por chave? Range scans? Joins? Agregações? Filtragem de vetor?
5. Qual a frequência de mudança de schema? Se o modelo muda toda semana, schema-less ajuda — mas considere se a mudança é sintoma de modelagem mal-feita.
6. Quem opera? Time tem expertise? Ferramentas de monitoramento? Backup, DR, upgrade — quem cuida?
7. Qual o custo total? Licença/managed cost + infra + pessoas + tempo de migração. NoSQL gerenciado (DynamoDB, Atlas) reduz dor operacional mas explode custo.
8. Existe um caminho de saída? Como migrar de volta se virar dívida? "Lock-in inicial é dívida latente".

Como praticar

1. Escolha um caso real do seu sistema e modele ele em três storages distintos (Postgres, MongoDB, Cassandra, por exemplo). Implemente as 3-4 queries críticas em cada. Compare verbosity, performance, complexidade operacional.
2. Monte um stack poliglota mínimo com Postgres + Redis. Implemente cache-aside e rate limiting. Meça impacto com e sem cache em latência P50, P95, P99 e em throughput. Quase todo sistema sênior usa esse par — vivê-lo é formativo.
3. Replique um caso clássico de migração reversa. Modele um caso simples primeiro em MongoDB; depois migre os dados para Postgres (talvez mantendo JSONB para os campos flexíveis). Documente o que foi mais simples, o que foi mais difícil, o que melhorou na nova versão.