# 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. **Autores:** Mauro Mequelussi **Publicado:** 2026-10-12T18:14:06.369063711Z **Atualizado:** 2026-10-12T19:00:25.769175425Z **Tags:** desenvolvimento-web, surrealmx, surrealdb, backend, banco-de-dados, arquitetura --- 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 ::video-player{src="https://www.youtube.com/watch?v=2_GHOPcxoQA" title="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ção | Resultado publicado | | --- | ---: | | Leituras pontuais | 21.506.711 por segundo | | Criações | 1.887.149 por segundo | | Atualizações | 1.595.009 por segundo | | Exclusões | 1.814.037 por segundo | | Varreduras por intervalo | 18.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 trabalho | Opção a avaliar | | --- | --- | | Dados na RAM, acesso com baixa latência, testes ou estado reconstruível | SurrealMX | | Armazenamento persistente em disco como prioridade | SurrealKV ou outra opção de disco compatível com a implantação | | Recuperação de dados em memória depois de reiniciar | SurrealMX 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](/blog/surrealdb-para-engenheiros-de-ia). Se ainda está escolhendo o banco do produto, o [guia SurrealDB vs Postgres](/blog/surrealdb-vs-postgres) ajuda a organizar as perguntas de arquitetura. [Crie sua conta no SurrealDB pelo link de indicação da Escola](https://l.escoladeaplicativos.com.br/surrealdb). 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 - [Anúncio original do SurrealMX 1.0, por Tobie Morgan Hitchcock, em 12/10/2026](https://surrealdb.com/blog/introducing-surrealmx-surrealdbs-new-in-memory-storage-engine). - [Documentação oficial: execução em memória, persistência e durabilidade](https://surrealdb.com/docs/running/in-memory). 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.