SurrealKV 1.0: por que o SurrealDB vai trocar o RocksDB

O SurrealKV 1.0 é o novo motor persistente do SurrealDB, lançado em 13 de outubro de 2026. Ele foi escrito em Rust e será o único motor persistente no SurrealDB 4, substituindo o RocksDB nessa função.

A manchete chama atenção: quase oito vezes mais velocidade nas leituras. Para quem cria um aplicativo, porém, a pergunta principal é entender o que foi medido, como os dados chegam ao disco e se a mudança ajuda o seu produto.

Assista à explicação do SurrealKV

O vídeo explica a arquitetura, a comparação com o RocksDB, os recursos do novo motor e os cenários em que ele ainda perde.

O que é um motor de armazenamento?

Quando seu aplicativo pede os dados de um cliente, existe um caminho entre a consulta e os bytes guardados. O banco interpreta o pedido; o motor de armazenamento cuida da organização e do acesso aos dados.

Uma analogia simples é pensar em uma loja. O aplicativo é o atendimento no balcão, enquanto o motor organiza as mercadorias no estoque. Melhorar o estoque pode acelerar uma etapa, mas o tempo de atendimento também depende das outras partes do processo.

O SurrealKV não é outro banco para substituir o SurrealDB. É uma peça que pode trabalhar sob sua camada de consultas. Ele também pode ser usado como biblioteca embutida em uma aplicação Rust. Seu código é aberto, com licença Apache 2.0.

Por que o SurrealDB vai substituir o RocksDB?

A equipe apresenta uma razão de arquitetura e manutenção: o RocksDB é uma biblioteca grande em C++ que o SurrealDB não controla. Ter um motor próprio permite acompanhar seu código de ponta a ponta, ajustar seu comportamento às necessidades do banco e distribuí-lo no ecossistema Rust.

Para uma equipe brasileira construindo um SaaS, isso interessa menos como disputa entre linguagens e mais como evolução da plataforma. Uma integração mais próxima entre banco e armazenamento pode facilitar o desenvolvimento de recursos e o diagnóstico de problemas. O resultado para cada aplicação continua dependendo de sua carga de trabalho.

O anúncio trata da substituição no SurrealDB 4. Ele não é uma instrução para trocar imediatamente a configuração de qualquer instalação existente. Antes de uma atualização, confirme a versão, o caminho de migração e a recuperação dos seus dados.

Como os dados passam da memória para o disco

O SurrealKV utiliza uma LSM-tree, uma estrutura que organiza gravações e depois mescla dados em camadas. As alterações chegam primeiro a uma estrutura em memória, a memtable. Um registro de alterações, chamado WAL, participa do caminho de persistência.

Imagine um sistema de agendamento recebendo várias reservas ao mesmo tempo. Em vez de tratar cada pequena escrita como um trabalho isolado, o armazenamento pode organizar as alterações e coordenar sua confirmação. O cuidado é fazer isso respeitando a garantia que o sistema oferece ao usuário.

Três escolhas do novo motor ajudam a explicar esse fluxo:

• Memtable com árvore radix concorrente: a estrutura organiza chaves por partes compartilhadas e permite operações concorrentes. Ela utiliza uma área de alocação fixa.
• Commit ring: várias transações podem validar seu trabalho em paralelo. Uma tarefa reúne o grupo acumulado, registra as alterações no WAL, aplica os dados e publica o resultado.
• Leituras com pouco trabalho compartilhado: cada leitura fixa um número de sequência para acessar uma visão consistente dos dados.

O motor oferece transações com isolamento por snapshot. Para entender a ideia, pense em uma operação que precisa enxergar um estado coerente do estoque enquanto outras vendas estão acontecendo.

Durabilidade síncrona: o detalhe que muda a comparação

Em um aplicativo, a mensagem “pedido confirmado” cria uma expectativa. Se o processo parar logo depois, o pedido precisa continuar existindo de acordo com as garantias do sistema.

Durabilidade síncrona significa, no cenário descrito pelo anúncio, que a confirmação espera a gravação no disco antes de retornar. O benchmark com essa configuração compara motores que passam por essa etapa antes de reconhecer a operação.

O commit ring procura diminuir o custo desse trabalho: uma rajada de confirmações pode ser agrupada em uma gravação no log, com no máximo uma sincronização com o disco para o grupo. Agrupar operações não é o mesmo que simplesmente responder antes de persistir.

Isso também explica por que comparar apenas números de operações por segundo pode enganar. Duas configurações rápidas podem oferecer compromissos diferentes sobre o que sobrevive a uma interrupção.

O benchmark: quase 8× em quais operações?

Com durabilidade síncrona, a equipe publicou os seguintes resultados:

O teste usou o crud-bench, um Threadripper 9970X, 128 GB de RAM, SSD NVMe de 4 TB, 500 mil chaves, 48 threads de trabalho e 128 clientes. A configuração do SurrealKV tinha separação de valores ativada e uma memtable maior que o padrão. Cada número corresponde a uma execução.

São resultados do motor de armazenamento publicados pelo fornecedor. Não são uma promessa de que qualquer consulta SurrealQL ou tela do seu aplicativo ficará oito vezes mais rápida.

Uma busca de produto pode incluir filtros, índices, relações, transporte pela rede e renderização da página. Se o maior tempo está na rede, mudar o motor de armazenamento pode ter um efeito pequeno no tempo total.

O artigo também apresenta um ganho maior em criação de registros, mas informa que a taxa do RocksDB naquele cenário ainda não foi explicada. Por isso, esse número não é uma boa manchete para decidir uma migração.

Onde o RocksDB ainda vence?

Sem durabilidade síncrona, o RocksDB foi mais rápido nas gravações medidas: criação, atualização e exclusão. Os motores, nesse cenário, também podem oferecer garantias diferentes após uma falha.

Outras operações têm resultados próprios. Nas varreduras sem sincronização, o LMDB ficou à frente do SurrealKV em alguns tipos de acesso, incluindo retornar os primeiros pares de chave e valor, pular entradas e contar o intervalo completo.

A memória também exige duas medidas. O SurrealKV ficou com o menor consumo em repouso entre os motores avaliados, mas seu pico foi maior que o do RocksDB: 1,79 GiB contra 1,02 GiB. Esses valores foram amostrados no benchmark sem durabilidade síncrona. As confirmações paralelas mantêm lotes ativos em buffers, o que ajuda a explicar esse pico.

Para quem roda um SaaS em uma máquina com memória limitada, olhar apenas o consumo em repouso seria insuficiente. Vale medir o momento de maior concorrência, como uma importação de contatos ou uma campanha que traz vários usuários ao mesmo tempo.

Versões dos dados, valores grandes e criptografia

O SurrealKV também inclui recursos que podem ser habilitados conforme a necessidade:

• Árvores versionadas: permitem ler uma chave em um momento e consultar seu histórico, com retenção configurável.
• Separação de valores maiores que 1 KiB: reduz o trabalho de reescrever valores grandes durante a compactação.
• Criptografia em repouso: o motor oferece AES-256-GCM ou XChaCha20-Poly1305.

Esses recursos pertencem à camada do motor. Sua disponibilidade no fluxo de uma aplicação depende da integração e da versão utilizada. Não convém assumir que um método da biblioteca Rust já corresponde a uma consulta disponível no seu SDK.

O projeto também descreve testes diferenciais: o comportamento do motor é comparado a um modelo de referência em milhões de operações no CI. Isso é uma evidência sobre o processo de desenvolvimento; a validação do seu próprio aplicativo continua necessária.

Como avaliar a mudança no seu projeto

Comece pelo fluxo que importa para o negócio. Para um sistema de gestão, pode ser confirmar uma venda e atualizar o estoque. Para um app de agendamento, verificar disponibilidade e salvar uma reserva. Para um agente de IA, recuperar e atualizar seu estado persistente.

Faça a comparação com os mesmos dados e com garantias equivalentes. Observe latência, concorrência, memória e comportamento após reiniciar o processo. Inclua consultas completas da aplicação, além de operações simples do motor.

Uma sequência prática é:

1. Identificar a versão e o motor da implantação atual.
2. Separar uma cópia dos dados e escolher operações representativas.
3. Medir o comportamento atual para ter uma referência.
4. Testar a configuração candidata em um ambiente separado.
5. Validar backup, restauração e recuperação antes de planejar a mudança em produção.

O anúncio fornece o comando e a configuração do crud-bench para reproduzir a comparação em outra máquina. Use esse material junto com medições do seu produto, sem tratar uma tabela isolada como decisão de arquitetura.

SurrealKV e SurrealMX: qual é a diferença?

O foco do SurrealKV é o armazenamento persistente, com dados organizados para disco. O SurrealMX parte de um conjunto de dados em memória, com opções de persistência e limites próprios.

A escolha começa pela necessidade: dados recuperáveis e temporários têm um papel diferente de pedidos, reservas e outros registros que precisam sobreviver a uma interrupção. Para ampliar o contexto, veja o guia de SurrealDB para Engenheiros de IA e a comparação entre SurrealDB e Postgres.

Crie sua conta no SurrealDB pelo link de indicação da Escola.

Perguntas frequentes

O SurrealKV substitui o SurrealDB?

Não. É um motor de armazenamento que pode trabalhar sob a camada de consultas do SurrealDB e também como biblioteca embutida.

O SurrealKV é oito vezes mais rápido em tudo?

Não. O resultado de 7,95× corresponde a leituras pontuais com durabilidade síncrona no benchmark publicado. Outras operações e configurações têm resultados diferentes.

Posso trocar o RocksDB imediatamente?

O anúncio apresenta o papel do SurrealKV no SurrealDB 4. A atualização da sua instalação depende da versão e do caminho de migração suportado. Valide a mudança em um ambiente separado.

Usar menos memória em repouso significa precisar de menos RAM?

Não necessariamente. O pico sob concorrência também importa e, no teste publicado, foi maior que o do RocksDB.

Fontes e próximos passos

• Anúncio oficial do SurrealKV 1.0 e resultados do benchmark.
• Todos os vídeos de SurrealDB na Escola de Aplicativos.
• Curso gratuito de SurrealDB em português.