1. Contexto de decisão: critérios-chave

Eu começo pela prática: cada projeto tem padrões de leitura/escrita, consistência exigida e evolução do modelo de dados. As perguntas centrais são: qual é o padrão de consulta principal? precisamos de transações ACID multi-documentos? quanta escalabilidade horizontal é necessária? há necessidade de relacionamentos complexos ou grafos? Com base nisso, o MongoDB deixa de ser a única opção viável. Abaixo, destaco categorias e sinais que guiam a escolha.

• Modelagem de dados: schema flexível vs. esquema rígido com validação; necessidade de joins frequentes.
• Consistência e transações: exige ACID entre várias entidades, ou é aceitável eventual/consistente para grande escala?
• Escalabilidade: operações de escrita contínuas, com retenção de dados histórica, faixa de latência aceitável e replicação regional.
• Ecossistema e operações: suporte a consultas ad hoc, tooling de análise, monitoramento, migração e backups.

Em resumo: para cargas simples com documentos, MongoDB pode ser excelente; para padrões com consultas SQL fortes, grafos complexos ou microserviços com escalabilidade agressiva, vale explorar alternativas específicas que otimizam esses casos.

2. PostgreSQL (JSONB): SQL + flexibilidade

Para quem precisa de linguagem SQL familiar, transações ACID e, ao mesmo tempo, suporte a dados semi-estruturados, o PostgreSQL com JSONB é uma escolha poderosa. Você ganha queries ricas, índices avançados e compatibilidade com integrações existentes, sem abrir mão da consistência.

• Vantagens: SQL completo, ACID, JSONB com indexação eficiente (GIN), consultas ad hoc com operadores JSON, regras de validação e migração gradual de esquemas.
• Quando usar: dados semi-estruturados, evolução de esquemas sobre várias coleções, necessidade de joins entre tabelas tradicionais e campos JSON.
• Limitações: pode exigir modelagem de dados mais cuidadosa para evitar sopradas de complexidade; operações de leitura intensivas em JSON podem ser mais pesadas que consultas puramente relacionais.

Exemplo prático de modelagem e consulta:

-- Criação de tabela com payload JSONB
CREATE TABLE events (
  id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  payload JSONB NOT NULL,
  ts TIMESTAMPTZ NOT NULL DEFAULT now()
);

-- Índice para acelerar consultas em campos dentro do JSONB
CREATE INDEX idx_events_payload_gin ON events USING GIN (payload);

-- Consulta para filtrar por tipo e data
SELECT id, payload->>'type' AS type
FROM events
WHERE payload->>'type' = 'user_signup'
  AND ts >= NOW() - INTERVAL '7 days';
        

Dicas rápidas: use JSONB para dados semia-notados, crie índices em caminhos específicos (ponteiros com operators -> e ->>), e combine com tabelas relacionais para agregações ou validações críticas.

3. Alto escalonamento horizontal: Cassandra/ScyllaDB e DynamoDB

Para workloads com alto volume de escrita, necessidade de particionamento e baixa latência global, bancos de dados orientados a colunas/dados distribuídos são uma boa aposta. Nesses cenários, a modelagem de dados se apoia no padrão de consultas, com desnormalização explícita e controle de consistência configurável.

• Cassandra/ScyllaDB: modelo wide-column, particionamento por chave de particionamento, escrita rápida, consistência ajustável por nível de replicação. Bom para logs, séries temporais e dados de telemetria.
• DynamoDB: serviço gerenciado, escalável horizontalmente, com tabelas e keys bem definidas, TTL, índices secundários e capacidades provisionadas. Excelente para aplicações serverless e requisitos de disponibilidade elevada.
• Quando usar: padrões de leitura previsíveis, sem necessidade de joins fortes, e necessidade de replicação global com latência baixa.

Exemplos de modelagem (CQL para Cassandra):

CREATE TABLE events_by_device (
  device_id text,
  event_time timestamp,
  payload text,
  PRIMARY KEY (device_id, event_time)
) WITH CLUSTERING ORDER BY (event_time DESC);

-- Inserção de evento
INSERT INTO events_by_device (device_id, event_time, payload) VALUES ('dev-42', toTimestamp(now()), '{ "temp": 22.5 }');
        

Observação: nessas opções, não é comum usar joins do tipo relacional; o desenho de consultas guia o modelo de dados. Planeje particionamento, retries e políticas de consistência com antecedência.

4. Grafos para relacionamentos complexos

Quando os seus casos envolvem redes de relacionamentos, caminhos longos ou queries recorrentes sobre conectividade, bancos de grafos entregam desempenho superior e clareza de modelagem. Neo4j (Cypher) e soluções multi-modelo (ArangoDB) são opções sólidas.

• Vantagens: traversais profundos, consulta de vizinhos a várias etapas, padrões de relacionamento com propriedades e grafos dinâmicos.
• Quando usar: redes sociais, detecção de fraude com padrões de comportamento, recomendações baseadas em relacionamentos.
• Considerações: grafos podem exigir investimento na modelagem de nós/relacionamentos; para dados em que a cardinalidade é baixa, outras abordagens podem ser mais simples.

Exemplo de consulta Cypher (Neo4j):

-- Encontrar amigos de amigos até 2 degraus
MATCH (u:User {id: $id})-[:FOLLOWS|FRIEND*1..2]-(v:User)
RETURN DISTINCT v.id;
        

Caso prefira AQL (ArangoDB) ou outro modelo, a ideia é manter grafos como primeiro approach para grafos pesados, enquanto dados tabulares podem permanecer em SQL/NoSQL tradicional para eficiência de operações simples.