# SurrealKV 1.0: por que o SurrealDB vai trocar o RocksDB
> Entenda o SurrealKV 1.0, a troca do RocksDB, o benchmark de quase 8× nas leituras e o que velocidade, durabilidade e memória mudam no seu aplicativo.
**Autores:** Mauro Mequelussi
**Publicado:** 2026-10-13T16:53:44.992048631Z
**Atualizado:** 2026-10-13T17:00:37.723259725Z
**Tags:** banco-de-dados, surrealkv, desenvolvimento-web, backend, arquitetura, surrealdb
---
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

::video-player{src="https://www.youtube.com/watch?v=MIiDyYoIsQU" title="SurrealKV: quase 8× mais rápido? Por que o SurrealDB vai trocar o RocksDB"}
::

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:

| Operação | SurrealKV | RocksDB | Relação publicada |
|---|---:|---:|---:|
| Leituras pontuais | 6.804.864 por segundo | 855.851 por segundo | 7,95× |
| Atualizações | 221.341 por segundo | 36.263 por segundo | 6,10× |
| Exclusões | 264.089 por segundo | 32.043 por segundo | 8,24× |
| Varreduras por intervalo | 905.132 por segundo | 852.661 por segundo | 1,06× |

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.

::read-more{slug="surrealmx-motor-memoria-surrealdb" title="SurrealMX: entenda também o motor em memória do SurrealDB"}
::

## 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](https://www.escoladeaplicativos.com.br/blog/surrealdb-para-engenheiros-de-ia) e a [comparação entre SurrealDB e Postgres](https://www.escoladeaplicativos.com.br/blog/surrealdb-vs-postgres).

[Crie sua conta no SurrealDB pelo link de indicação da Escola](https://l.escoladeaplicativos.com.br/surrealdb).

## 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](https://surrealdb.com/blog/we-are-replacing-rocksdb-with-surrealkv-1-0).
- [Todos os vídeos de SurrealDB na Escola de Aplicativos](https://www.youtube.com/playlist?list=PLWC_rl-n97nQ).
- [Curso gratuito de SurrealDB em português](https://l.escoladeaplicativos.com.br/curso-surrealdb).