# SurrealDB 4: SQL, novo executor e o que muda para quem cria aplicações > O SurrealDB 4 é a versão estável lançada em 3 de novembro de 2026. Traz novo executor, SQL PostgreSQL e MySQL e mudanças de armazenamento; migrar um datastore 3.x no próprio local continua experimental. **Autores:** Mauro Mequelussi **Publicado:** 2026-11-03T17:36:13.392813086Z **Atualizado:** 2026-11-03T18:00:52.723737739Z **Tags:** backend, banco-de-dados, desenvolvimento-web, surrealdb, arquitetura --- O **SurrealDB 4** é a versão do banco de dados multimodelo lançada como estável em **3 de novembro de 2026**. Ela reúne documentos, grafos e vetores e acrescenta um executor unificado, execução de SQL pelos protocolos PostgreSQL e MySQL e mudanças em tipos, transações e armazenamento. [Release oficial](https://surrealdb.com/releases/4.0). O **SurrealDB 4.0.0 foi lançado como versão estável em 3 de novembro de 2026**. Entre os destaques estão um executor unificado, suporte aos dialetos PostgreSQL e MySQL, novos tipos numéricos e mudanças na evolução de schemas. Para quem já usa a versão 3, há uma distinção decisiva: o lançamento é estável, mas a atualização de um datastore existente no próprio local continua classificada como experimental. [Notas oficiais do lançamento](https://surrealdb.com/releases/4.0), [guia de migração](https://surrealdb.com/docs/build/migrating/from-old-surrealdb-versions/3x-to-4x). ## Um executor para todas as consultas Versões anteriores ofereciam estratégias diferentes de planejamento. O SurrealDB 4 substitui esses caminhos por um executor que compila instruções em bytecode e mantém esse trabalho em cache. As permissões de leitura da tabela entram no plano de execução junto com os filtros da consulta. O lançamento também distribui varreduras seletivas por várias threads e permite que operações como ordenações, agrupamentos e joins usem disco quando ultrapassam sua parcela de memória. Isso amplia os recursos disponíveis para consultas grandes, embora o resultado dependa da configuração e do ambiente de execução. O navegador, por exemplo, não recebe as mesmas varreduras paralelas dos demais ambientes. Uma consequência aparece no código da aplicação: **sem `ORDER BY`, a ordem dos registros pode variar**. Uma tela que dependia da ordem observada anteriormente precisa declarar sua ordenação. Essa mudança afeta paginação, testes e qualquer rotina que interprete “o primeiro resultado” como algo previsível. [Mudanças do executor](https://surrealdb.com/releases/4.0). ## PostgreSQL e MySQL passam a ser portas de entrada O SurrealDB 4 aceita conexões pelos protocolos de PostgreSQL e MySQL e executa os respectivos dialetos SQL sobre as mesmas tabelas acessadas por SurrealQL. Isso permite aproveitar clientes, drivers e ferramentas familiares para conversar com o banco. Na versão 3.3, um cliente PostgreSQL podia estabelecer conexão, mas ainda precisava enviar SurrealQL. A versão 4 acrescenta execução de SQL. A documentação detalha recursos como joins, agregações, instruções preparadas, transações e funções de janela, além das diferenças de comportamento de cada dialeto. Para equipes com aplicações existentes, essa compatibilidade abre um caminho de avaliação. É necessário verificar as consultas reais, as operações de schema e os recursos usados pelo ORM. Compatibilidade de protocolo e suporte a SQL não equivalem a reproduzir toda extensão, ferramenta ou comportamento de um servidor PostgreSQL ou MySQL. [Notas da versão](https://surrealdb.com/releases/4.0), [referência do protocolo MySQL](https://surrealdb.com/docs/reference/rest-api/mysql-protocol). ## Tipos mais precisos e evolução dos registros existentes Os tipos numéricos passam a permitir larguras explícitas. Um campo pode representar um inteiro sem sinal de 16 bits, como `u16`, ou um número de ponto flutuante de 32 bits, como `f32`. Valores que não cabem no tipo declarado são recusados. Outro avanço envolve mudanças de schema. Uma alteração de tipo pode definir como converter registros existentes, com uma migração identificada por nome e uma regra de fallback. O banco aplica a conversão durante a leitura enquanto um trabalho em segundo plano reescreve os registros. Isso ajuda a tratar uma dificuldade comum em produtos que evoluem: o schema muda, mas os dados antigos continuam presentes. Ainda assim, a escolha da conversão e do fallback pertence à aplicação. Transformar um valor inválido em zero, por exemplo, pode preservar a execução e alterar o significado de um dado de negócio. [Tipos e migrações na versão 4](https://surrealdb.com/releases/4.0). ## Transações: a garantia depende do motor O lançamento acrescenta transações explicitamente somente de leitura e a seleção de isolamento serializável. Este último permite detectar conflitos que podem passar pelo isolamento por snapshot, como duas transações tomando decisões incompatíveis a partir da mesma disponibilidade inicial. A disponibilidade depende do armazenamento: as notas informam suporte a `SERIALIZABLE` no motor em memória e no SurrealDS. O SurrealKV recusa esse nível em vez de executar silenciosamente com uma garantia mais fraca. Portanto, a arquitetura precisa conferir tanto a versão do banco quanto o motor escolhido. [Garantias transacionais](https://surrealdb.com/releases/4.0). ## SurrealKV e SurrealDS têm papéis diferentes O SurrealKV unifica o armazenamento persistente local entre servidor, aplicações embarcadas e navegador. No navegador, utiliza o Origin Private File System. RocksDB e IndexedDB deixam de existir como motores próprios nessa versão, e os dados antigos exigem os procedimentos de conversão descritos na documentação. Já o **SurrealDS 1.0** atende ao armazenamento distribuído da edição Enterprise e dos clusters gerenciados compatíveis. Os dados ficam em armazenamento de objetos, enquanto os nós mantêm logs e caches. Na política padrão de duas zonas, a confirmação de uma escrita depende de sua persistência nos discos de ambas as zonas. São mecanismos com responsabilidades distintas. Ao avaliar uma implantação, é preciso identificar qual deles está em uso antes de assumir propriedades de escalabilidade ou tolerância a falhas. [Armazenamento na versão 4](https://surrealdb.com/releases/4.0). ## Desempenho: ganhos que precisam de contexto A apresentação do lançamento relata construção de um índice HNSW com um milhão de vetores, de 768 dimensões, em 986 segundos, contra 7.290 segundos no cenário anterior. Também informa queda de 27 ms para 1,1 ms em um teste específico de busca vetorial com filtro de 1%. Esses resultados foram divulgados pelo fornecedor em condições determinadas. Eles ajudam a identificar melhorias para investigar, mas não antecipam a latência de um SaaS ou de um agente. A página de benchmarks também identifica resultados projetados para consultas indexadas; esses números precisam manter essa qualificação quando usados em comparações. [Apresentação do SurrealDB 4](https://surrealdb.com/4), [benchmarks e metodologia](https://surrealdb.com/surrealdb/benchmarks). ## O que conferir antes de migrar da versão 3 A migração no próprio datastore exige consentimento explícito por configuração. Depois de aplicada, uma versão 3 não consegue reabrir aquele datastore. Voltar exige restaurar um export ou uma cópia anterior, com as consequências para os dados escritos depois da migração. O procedimento merece um ambiente de teste com cópia dos dados, export verificado e revisão dos índices que precisam ser reconstruídos. O guia também documenta um verificador de compatibilidade disponível na linha 3.3 atual. Seu relatório cobre o estado armazenado, mas não substitui a validação dos SDKs, das consultas enviadas pela aplicação e dos scripts de schema externos. [Procedimento completo de atualização](https://surrealdb.com/docs/build/migrating/from-old-surrealdb-versions/3x-to-4x). Para um projeto novo, o SurrealDB 4 amplia as opções de acesso e modelagem. Para um produto existente, a oportunidade vem acompanhada de uma decisão de engenharia: medir os benefícios com a própria carga e executar a migração como uma mudança de formato de dados. ## Perguntas frequentes sobre o SurrealDB 4 ### O SurrealDB 4 já é estável? Sim. A versão 4.0.0 foi lançada como estável em 3 de novembro de 2026. A atualização de um datastore 3.x no próprio local, porém, continua experimental e exige opt-in explícito. [Release e status](https://surrealdb.com/releases/4.0). ### O SurrealDB 4 substitui PostgreSQL e MySQL sem alterações? A versão 4 aceita seus protocolos e executa os dialetos SQL documentados. A equipe precisa validar consultas, tipos, extensões e operações do ORM; isso não garante equivalência integral com os servidores originais. [Referência técnica](https://surrealdb.com/docs/reference/rest-api/mysql-protocol). ### É possível voltar à versão 3 depois de migrar? Uma versão 3 não reabre o datastore convertido. O retorno exige restaurar um export ou uma cópia anterior em um ambiente 3.x, sem os dados escritos depois da migração. [Guia de atualização](https://surrealdb.com/docs/build/migrating/from-old-surrealdb-versions/3x-to-4x). **Última checagem das fontes:** 3 de novembro de 2026. ## Continue a leitura [SurrealDB Earth: como funciona o banco serverless na Cloudflare](/blog/surrealdb-earth-serverless-cloudflare) [SurrealDB 4 e Earth: o que a combinação muda para SaaS e agentes de IA](/blog/surrealdb-4-earth-saas-agentes-ia)