o problema
Em 2005, Stonebraker assinou um capítulo do Red Book que revisava quarenta anos de modelagem de dados — hierárquico, CODASYL, relacional, orientado a objetos, semiestruturado — e concluía que o modelo relacional com sistema de tipos extensível tinha ganho de todos, e que o SQL vinha engolindo as boas ideias dos rivais em vez de ser substituído por elas. A conclusão era confortável demais para envelhecer sem checagem. Nos vinte anos seguintes veio a era do Big Data, a onda NoSQL, a nuvem, os data lakes e, no fim, os bancos vetoriais, cada um anunciado como o fim do SQL.
O custo de errar essa leitura não é acadêmico. Empresas compraram clusters de Hadoop inteiros para descobrir que ninguém queria a funcionalidade. Times escolheram document stores sem join e sem índice secundário para aplicações que precisavam dos dois. E dado é grudento: os autores lembram que ainda existem bancos IMS rodando não porque o IMS seja bom, mas porque trocar é caro e arriscado. Uma escolha de modelo de dados dura mais que a empresa que a fez.
a ideia
O padrão que o paper descreve não é que os desafiantes estejam errados sobre o problema. Eles costumam estar certos sobre o problema — o SQL era ruim de escalar em 2008, o “primeiros cinco minutos” de um RDBMS é pior que o de um key-value store, embeddings precisam de busca por similaridade. O erro é achar que a resposta é um sistema novo.
Duas forças fazem a convergência acontecer. A primeira: o SQL absorve. A boa ideia do desafiante vira tipo de dado, índice ou extensão do padrão. A segunda: o desafiante paga tarde um pedágio que subestimou. Otimizador, transação, catálogo, recuperação — os autores dizem que o otimizador é a parte mais difícil de construir um DBMS e suspeitam que foi exatamente esse peso de engenharia que levou os sistemas NoSQL a não suportarem SQL no início. Quando o cliente pede ACID e join, o desafiante precisa construir aquilo tudo; o incumbente só precisa adicionar um índice.
como funciona
O método é um julgamento categoria por categoria, com critérios fixos: o modelo suporta join? Tem índice secundário? Tem transação? O que a linguagem própria ganha em troca do que perde? São oito categorias de modelo de dados — MapReduce, key-value, documento, column-family, busca textual, array, vetorial, grafo — e seis de arquitetura: colunar, nuvem, data lake/lakehouse, NewSQL, aceleradores de hardware e blockchain.
A prova da absorção está no calendário do padrão. SQL:1999 trouxe arrays de dimensão única e tamanho fixo; SQL:2003 estendeu para arrays aninhados sem cardinalidade máxima; o padrão de 2016 adicionou tipo JSON e operações sobre ele; SQL:2023 trouxe arrays multidimensionais de verdade, o SQL/MDA inspirado na linguagem do Rasdaman, e o SQL/PGQ para consulta de grafos, construído em cima da sintaxe do Cypher, do PGQL e do GSQL. Do outro lado, o mesmo movimento em espelho: Cloudera trocou o Hadoop por um RDBMS próprio sobre o HDFS, a MapR fez o Drill sobre o HDFS, e a Meta criou o Presto para substituir o Hive.
o que isso custou
Isto é um paper de opinião, não um estudo. Os autores não medem nada; citam medições de terceiros e assumem o resto. Duas décadas de acerto na tese anterior não são evidência de que a próxima previsão vale, e eles mesmos sabotam a base técnica do argumento ao abrir os comentários finais dizendo que produto ruim com marketing forte ganha de produto bom — se é assim, convergência técnica não prevê nada sobre mercado.
As concessões estão espalhadas pelo texto e valem mais que o veredito. Arrays: aplicações científicas vão continuar ignorando RDBMSs, e os autores admitem que bancos relacionais não armazenam nem analisam arrays com eficiência mesmo com o SQL/MDA. Busca textual: a integração de search no SQL é desajeitada e diverge entre fornecedores, o que ainda justifica polystore. Grafos analíticos: o melhor caminho é comprimir o grafo em memória num único nó, porque algoritmo distribuído raramente vence implementação de nó único. NewSQL: fracassou não por ser tecnicamente pior, mas porque o que já existia era bom o bastante e ninguém migra OLTP por gosto. E data lakes criaram um problema que o modelo relacional não resolve — sem estatística sobre arquivos recém-ingeridos, o otimizador escolhe mal e precisa adaptar o plano durante a execução.
onde isso aparece hoje
O verbete direto do antecessor é What Goes Around Comes Around, de 2005. A trajetória do MapReduce até o Bigtable é o caso central de sistema que morreu como interface e sobreviveu como ideia. O Dynamo vira DynamoDB com PartiQL e depois com transações distribuídas; a Cassandra troca a API Thrift pelo CQL; o Spanner larga consistência eventual em 2012 e depois apaga os restos de Bigtable de dentro de si.
Do lado da implementação, o C-Store é a origem da virada colunar que tomou o mercado de data warehouse, o Snowflake introduziu o serverless que os outros copiaram, e o Lakehouse é o arquétipo que os autores apostam para os próximos dez anos. Para a categoria mais nova, o levantamento sobre bancos vetoriais e a biblioteca FAISS mostram o que o paper afirma: o diferencial é um índice, e índice se integra.