Voltar aos materiais
NOVIDADESDESENVOLVIMENTO-WEBSURREALMXSURREALDB

SurrealMX: o novo motor em memória do SurrealDB explicado

Entenda o SurrealMX 1.0, o benchmark de 21,5 milhões de leituras por segundo e quando memória, transações e persistência fazem sentido no seu app.

Por Mauro Mequelussi

8_MIN
SurrealMX: o novo motor em memória do SurrealDB explicado
Em resumo

Entenda o SurrealMX 1.0, o benchmark de 21,5 milhões de leituras por segundo e quando memória, transações e persistência fazem sentido no seu app.

O SurrealMX 1.0 é o motor de armazenamento em memória anunciado pela SurrealDB em 12 de outubro de 2026. Ele guarda chaves e valores na RAM e foi pensado para cenários nos quais acessar dados rapidamente importa mais do que trabalhar com uma base maior que a memória disponível.

O número que chama atenção é 21,5 milhões de leituras pontuais por segundo, publicado pela própria equipe. Mas a pergunta útil para quem desenvolve um produto no Brasil é outra: isso resolve qual problema do meu aplicativo? Vamos separar a novidade, o benchmark e os cuidados, em linguagem direta.

Veja o caminho dos dados no vídeo

SurrealMX: 21 milhões de leituras por segundo? O novo motor do SurrealDB

O diagrama acompanha aplicação, banco, motor em memória e persistência opcional. É uma ilustração dos conceitos; não é uma gravação de um teste de desempenho executado pela Escola.

SurrealMX não é um banco novo para substituir tudo

Uma aplicação envia uma consulta ao SurrealDB. O banco interpreta o pedido e usa uma camada de armazenamento para acessar os registros. O SurrealMX é uma opção para essa camada: um motor transacional de chave e valor, escrito em Rust.

Uma analogia ajuda: a consulta é o pedido feito ao balcão; o motor decide como encontrar e movimentar o que está guardado. Trocar essa peça pode melhorar determinados acessos, mas o tempo total também depende do trabalho feito nas outras etapas.

O anúncio apresenta a versão 1.0 do motor. Rodar o SurrealDB em memória já era possível: a documentação da linha 3.x menciona o backend SurrealMX desde a versão 3.0. Portanto, a novidade não deve ser lida como “antes não existia banco em memória”.

O que muda quando os dados ficam na RAM?

RAM é a memória de trabalho do computador. O SurrealMX parte dela como meio principal de armazenamento, em vez de adaptar um motor voltado a disco para um uso em memória.

Para um produto, a questão é identificar dados que precisam estar disponíveis rapidamente e cujo volume cabe nessa memória. Exemplos ilustrativos:

  • Cache de um catálogo: uma loja brasileira pode guardar dados recuperáveis de produtos para reduzir buscas repetidas. A origem confiável desses dados precisa continuar definida.
  • Estado temporário de uma simulação: um sistema calcula alternativas de entrega e descarta o resultado quando a simulação termina.
  • Ambiente de testes: uma equipe cria dados de exemplo, executa cenários e reinicia o ambiente sem precisar preservar a base.

Esses exemplos são aplicações possíveis do conceito, não integrações prontas anunciadas para um ERP, plataforma de comércio ou provedor específico. Dados financeiros, pedidos confirmados e registros que não podem desaparecer exigem uma estratégia de durabilidade compatível com o negócio.

Como várias operações avançam sem uma fila única

Imagine um atendimento em que todo mundo precisa passar pela mesma catraca. Se uma pessoa demora, a fila cresce. Uma trava global em um sistema pode produzir um gargalo parecido.

O artigo descreve uma combinação de árvore de busca concorrente, controle de concorrência por múltiplas versões e um anel de confirmação de operações. A proposta é permitir acessos concorrentes sem uma trava global para tudo. As leituras são descritas como lock-free, ou seja, não precisam adquirir uma trava para percorrer as versões dos dados.

Isso não significa que qualquer escrita acontece sem coordenação, nem que toda aplicação terá o mesmo ganho. Significa que o motor foi projetado para reduzir pontos de contenção quando várias operações disputam acesso ao conjunto de dados.

Velocidade com transações: por que isso importa?

Uma transação reúne alterações que precisam ter um resultado coerente. Pense em mover um item entre duas listas: você não quer que ele suma de uma e deixe de aparecer na outra por uma falha no meio do caminho.

O SurrealMX oferece transações, rollback e savepoints. Rollback desfaz o trabalho da própria transação; savepoint marca um ponto interno para controlar uma recuperação. O motor também suporta isolamento por snapshot e isolamento serializável por snapshot, conforme o anúncio.

O mecanismo de múltiplas versões permite uma visão consistente para uma operação enquanto outras alterações avançam. Ele não deve ser confundido com um recurso de consultar qualquer momento do passado no SurrealQL: a documentação atual informa que o SurrealMX não suporta consultas versionadas na linha 3.3.0.

Os 21 milhões por segundo, com o contexto completo

A equipe publicou os seguintes resultados para o motor chave/valor:

OperaçãoResultado publicado
Leituras pontuais21.506.711 por segundo
Criações1.887.149 por segundo
Atualizações1.595.009 por segundo
Exclusões1.814.037 por segundo
Varreduras por intervalo18.031.692 por segundo

O teste utilizou um AMD Ryzen Threadripper 9970X, 128 GB de RAM DDR5, 15 milhões de chaves, 48 threads de trabalho e 128 clientes. Para cada motor e operação, foi escolhido o melhor resultado de três execuções.

São medições publicadas pelo fornecedor, não reproduzidas por nós. Também não são 21 milhões de consultas completas do seu aplicativo por segundo. Uma consulta com filtros, relações, autorização, rede ou busca vetorial envolve trabalho adicional. Para dimensionar um produto, meça a operação real que seu usuário faz, com os dados e a infraestrutura que você pretende usar.

Se reiniciar, os dados desaparecem?

Sem persistência, sim: os dados em memória são perdidos quando o processo termina. Isso pode ser aceitável em testes e informações reconstruíveis, mas não em uma base que precisa sobreviver a uma interrupção.

O SurrealMX permite configurar persistência opcional, com registro sequencial de alterações, snapshots periódicos e diferentes comportamentos de gravação e sincronização. Um snapshot é uma cópia do estado do banco; o log registra alterações para ajudar na recuperação.

O equilíbrio muda conforme a configuração. Só guardar snapshots pode deixar alterações recentes fora da última cópia. Gravar um log de forma assíncrona não oferece a mesma proteção que esperar a gravação e a sincronização a cada confirmação. A documentação compara esses cenários; escolher exige definir a perda de dados aceitável e testar a recuperação.

Persistência opcional não elimina o limite de memória: o conjunto de dados continua precisando caber na RAM. Ela também não transforma automaticamente o motor em uma solução equivalente a armazenamento em disco para bases grandes e de longo prazo.

SurrealMX ou SurrealKV: qual escolher?

Prioridade do trabalhoOpção a avaliar
Dados na RAM, acesso com baixa latência, testes ou estado reconstruívelSurrealMX
Armazenamento persistente em disco como prioridadeSurrealKV ou outra opção de disco compatível com a implantação
Recuperação de dados em memória depois de reiniciarSurrealMX com persistência configurada e validada

A comparação descreve prioridades, não uma recomendação universal. Verifique a versão do SurrealDB, o modelo de implantação e o suporte do SDK que sua aplicação usa. O anúncio informa suporte a execução embutida e WebAssembly, mas isso não prova que toda integração esteja disponível da mesma forma em qualquer linguagem.

Como avaliar no seu projeto

Comece por uma operação concreta: ler um produto, atualizar o estado de uma sessão ou processar um cenário de teste. Meça latência, consumo de memória, concorrência e comportamento ao reiniciar. Compare com a opção atual usando o mesmo conjunto de dados e a mesma máquina.

Para aprender a camada de dados em português, consulte o curso gratuito SurrealDB para Engenheiros de IA. Se ainda está escolhendo o banco do produto, o guia SurrealDB vs Postgres ajuda a organizar as perguntas de arquitetura.

Crie sua conta no SurrealDB pelo link de indicação da Escola. Este é um link de afiliado/indicação. O cadastro na nuvem é uma opção para explorar o ecossistema; não é um requisito geral para usar um banco local em memória.

Perguntas frequentes

O SurrealMX substitui o SurrealDB?

Não. É um motor de armazenamento que pode ficar sob a camada de consultas do SurrealDB.

A velocidade anunciada vale para o meu aplicativo?

Não automaticamente. É um benchmark específico do motor, com hardware, concorrência e conjunto de dados documentados. Meça o fluxo completo da sua aplicação.

Posso ter persistência e continuar usando RAM?

Sim, com configuração de log e snapshots. A proteção contra falhas depende das opções escolhidas, e os dados continuam precisando caber na memória.

Preciso migrar meu produto agora?

O lançamento é uma oportunidade de avaliação. A decisão deve vir do gargalo observado e dos requisitos de recuperação, não apenas de um número de desempenho.

Fontes e data de verificação

Adaptação editorial em português pela Escola de Aplicativos, com exemplos próprios para o público brasileiro. Informações verificadas em 12 de outubro de 2026. Confira a documentação da versão utilizada antes de definir a implantação.

Mentoria Ecosystem

Quer parar de alugar o seu negócio? Na Mentoria Ecosystem você troca a pilha de SaaS por um ecossistema seu — checkout, financeiro, atendimento e CRM num painel só.

CONHECER_A_MENTORIA →
Continue explorando
Ver todos os artigos →