Bancos de dados e por que sua complexidade agora é desnecessária

Artigo original ↗ Discussão no Hacker News ↗

Uma postagem argumentando que bancos de dados relacionais tradicionais são complexos demais e fundamentalmente falhos provocou debate sobre quando suas restrições na verdade são uma força. Os comentários contrastam a simplicidade de “um grande banco SQL” para a maioria das startups e sistemas de negócios com as necessidades de arquiteturas orientadas a eventos em escala de petabytes, onde logs + views materializadas e ferramentas como Rama, Kafka ou Datomic podem se destacar. Muitos continuam céticos quanto às alegações do Rama de substituir bancos de dados — citando complexidade operacional, dependência da JVM e lições difíceis do event sourcing — ao mesmo tempo em que reconhecem que ferramentas melhores para evolução de esquema, indexação e processamento de dados em larga escala ainda são um problema não resolvido.

Banco de dados único vs. múltiplos bancos de dados

  • Forte apoio a “um grande banco de dados” como superpoder: semântica mais simples, sem transações distribuídas, depuração mais fácil e, muitas vezes, escala suficiente para a maioria das empresas.
  • Contra-argumentos:
    • Você inevitavelmente tem pelo menos outro datastore para infraestrutura (por exemplo, etcd/ZooKeeper/K8s metadata).
    • Em escalas maiores ou com necessidades mais rígidas de isolamento, dividir dados (por serviço, locatário ou carga de trabalho) pode reduzir o raio de impacto e permitir evolução independente.
    • Para muitas startups, um único RDBMS escalado verticalmente + algumas réplicas é suficiente; sharding horizontal muitas vezes é prematuro.

Modelos relacionais, esquemas e complexidade

  • Alguns argumentam que qualquer domínio pode ser modelado de forma limpa com tuplas e relações; desempenho, não expressividade, é o limite real.
  • Outros enfatizam que esquemas restritivos e normalização são uma feature: eles forçam reflexão, protegem a qualidade dos dados e permitem consultas poderosas.
  • As reclamações se concentram mais na evolução do esquema, no risco de migração e no vazamento da ORM do que no próprio modelo relacional.

Event sourcing + views materializadas

  • Muitos apontam que a maioria dos bancos de dados sérios já são “views materializadas sobre um log” (WAL/binlog).
  • Event sourcing é elogiado em ambientes de alta escala e muito voltados a engenharia de dados, mas:
    • Muitos relatam que ele adiciona boilerplate, carga cognitiva, dores de cabeça com versionamento, problemas de GDPR/anonimização e depuração dolorosa.
    • Vários dizem que se arrependeram de adotá-lo fora de casos de uso estreitos e bem justificados.
  • Outros relatam sucesso quando usado seletivamente, muitas vezes com padrões Kafka/CDC/outbox e RDBMS tradicional como armazenamento canônico.

Rama: arquitetura e reações

  • Rama é descrito como: “depots” append-only (logs de eventos) + dataflows distribuídos que constroem “PStates” arbitrários (índices materializados) + topologias de consulta.
  • Ele roda na JVM com APIs em Java e Clojure, visa substituir o stack usual “Postgres + queue + search + ETL” e afirma oferecer forte consistência, semântica semelhante a ACID e alta escalabilidade.
  • Comentários entusiasmados: gostam do modelo coeso, da telemetria embutida e da integração apertada entre ingestão, processamento e consulta.
  • Ceticismo:
    • Marketing pesado (“bancos de dados desnecessários”, “escala do Twitter com 100x menos código”) parece exagerado; a demonstração é sintética, não uma migração real de produção.
    • A API parece uma DSL embutida em Java; ser apenas JVM é uma barreira; a curva de aprendizado e o modelo mental não são claros.
    • Há dúvidas de que simplifique apps de negócios típicos (por exemplo, carrinhos de compras, contabilidade) em comparação com um bom RDBMS.

Estado global mutável, transações e evolução

  • Há acordo de que estado global mutável é inerentemente inevitável; logs de eventos ainda mudam conforme novos eventos chegam.
  • Transações e constraints de RDBMS continuam altamente valorizadas para cargas de trabalho semelhantes a dinheiro; alguns veem o modelo do Rama apenas como uma realocação, não uma remoção, da complexidade.
  • Muitos gostariam de melhores ferramentas para evolução de esquema, migrações blue/green e “schema as code”, independentemente de usarem bancos de dados ou logs de eventos.