SurrealDB 4 e Earth: o que a combinação muda para SaaS e agentes de IA

SurrealDB 4 e SurrealDB Earth cumprem papéis complementares: a versão 4 é o motor do banco multimodelo; o Earth é o serviço serverless que o executa na Cloudflare. Para SaaS e agentes de IA, a combinação permite avaliar persistência de documentos, grafos e vetores com computação sob demanda. Lançamento, documentação.

Esse cenário aproxima duas decisões de arquitetura: como representar o conhecimento e como disponibilizar capacidade para acessá-lo. O SurrealDB 4 atua no motor de banco de dados. O SurrealDB Earth oferece uma implantação serverless sobre a Cloudflare. A combinação permite avaliar dados multimodelo com computação que acompanha a atividade, respeitando os recursos e limites do serviço. Visão do lançamento, documentação do Earth.

Qual é a diferença entre SurrealDB 4 e Earth?

A tabela sintetiza as opções da versão 4 e as características do Earth.

O papel de cada peça

O SurrealDB 4.0.0, lançado como estável em 3 de novembro de 2026, introduz um executor unificado, acesso pelos dialetos PostgreSQL e MySQL e mudanças nos tipos, transações e armazenamento. Ele também pode rodar fora do Earth, incluindo servidores próprios e aplicações embarcadas.

O Earth aplica o banco a um modelo operacional específico: instâncias isoladas, capacidade adicionada sob demanda e redução da computação a zero durante a ociosidade. O armazenamento persistente mantém os dados para a próxima execução.

O lançamento inclui ainda o SurrealDS 1.0, responsável por armazenamento distribuído em implantações compatíveis. Embora as tecnologias se conectem, uma avaliação precisa distinguir versão do motor, arquitetura de armazenamento e condições comerciais do serviço. Notas do SurrealDB 4, arquitetura do Earth.

Um exemplo: atendimento com contexto e relações

Considere um SaaS de atendimento. A aplicação precisa armazenar clientes e conversas, relacionar chamados a produtos e buscar trechos de documentação semanticamente semelhantes à pergunta recebida.

Uma proposta de modelagem com SurrealDB pode combinar documentos para as conversas, relações para conectar entidades e vetores para recuperar conteúdo. A aplicação pode usar esses resultados para montar o contexto enviado a um modelo de linguagem. Essa é uma possibilidade de arquitetura; a qualidade da resposta continua dependendo dos documentos, da recuperação e das regras do assistente.

No Earth, essa proposta precisa usar recursos efetivamente disponíveis. A documentação permite índices HNSW e live queries, mas exclui DiskANN, change feeds, funções JavaScript embutidas e extensões WebAssembly. A seleção dos recursos influencia o desenho do produto desde o começo. Capacidades e restrições do Earth.

Um database por cliente pode se tornar uma opção prática

A apresentação do Earth propõe instâncias isoladas para clientes, usuários ou agentes. Isso abre uma alternativa à concentração de todos os clientes nas mesmas tabelas, especialmente quando os ambientes passam muito tempo ociosos.

Para um SaaS, a hipótese é interessante: separar estado e dados por cliente sem manter capacidade permanentemente ativa para todos. A separação exige, porém, provisionamento, credenciais, aplicação de schemas, monitoramento e controle de acesso no roteamento da aplicação. O isolamento oferecido pelo serviço não elimina essas responsabilidades.

Há também uma diferença entre capacidade tecnológica e plano contratado. A página apresenta escala para milhares de instâncias, enquanto os planos de autosserviço consultados publicam até 100 databases por conta. Uma plataforma maior precisa validar condições e limites antes de basear o produto nessa distribuição. Proposta de isolamento, limites comerciais atuais.

O efeito sobre agentes que trabalham em intervalos

Um agente de pesquisa pode executar por alguns minutos, persistir resultados e voltar a trabalhar dias depois. Nesse padrão, manter dados duráveis enquanto a computação dorme pode ser útil. A próxima tarefa recupera o estado salvo e continua a partir dele.

Essa persistência não cria, sozinha, uma memória confiável. A aplicação precisa decidir o que registrar, associar informações às suas fontes, respeitar permissões e atualizar fatos que mudaram. Uma busca vetorial encontra conteúdo semelhante, mas a semelhança não comprova que uma informação é atual ou correta.

A combinação do banco com o Earth fornece componentes para essa construção. O desenho da memória e sua avaliação continuam pertencendo ao produto. Essa é uma análise de aplicação das capacidades documentadas, e não um resultado medido em uma implantação nossa.

SQL pode facilitar a avaliação de uma arquitetura multimodelo

Os protocolos PostgreSQL e MySQL do SurrealDB 4 permitem experimentar ferramentas e bibliotecas já conhecidas pela equipe. Dados acessados por SQL também podem ser consultados por SurrealQL, dentro das regras de cada interface.

Isso pode reduzir parte do trabalho de integração em um teste de conceito. A equipe ainda precisa verificar consultas, tipos, migrações e comportamento de transações. No Earth, há exigências próprias para conexões SQL, incluindo TLS e autenticação com usuários definidos no nível do database. Compatibilidade da versão 4, conexões SQL no Earth.

Economia depende do padrão de uso

O Earth cobra conforme franquias e métricas de requisições, armazenamento e horas ativas de database. Esse modelo pode combinar bem com uso intermitente, mas o número de databases ativos importa: muitos agentes ocupados simultaneamente acumulam consumo.

Um cálculo útil considera quantos clientes ficam ativos, quanto tempo suas tarefas duram, quantas consultas executam e quanto contexto armazenam. A comparação com capacidade dedicada deve usar esse perfil, além das necessidades de latência e dos recursos exigidos. A documentação apresenta Start e Scale como opções para quem precisa de capacidade escolhida ou de funcionalidades ausentes no Earth. Preços, quando escolher cada implantação.

Como avaliar a combinação em um produto real

Um teste de conceito pode começar por um fluxo completo: receber uma pergunta, buscar contexto autorizado, registrar a execução e recuperar o estado em uma nova sessão. Esse fluxo permite observar custos, latência após ociosidade, conflitos e comportamento das conexões sem extrapolar um benchmark de laboratório.

Para projetos que já usam SurrealDB 3, a atualização merece uma frente própria. A versão 4 é estável, mas a migração do datastore no próprio local continua experimental e irreversível após aplicada. Um relatório de compatibilidade, uma cópia dos dados e a validação das consultas são parte dessa avaliação. Guia de atualização.

O valor potencial da combinação está em aproximar persistência multimodelo, ferramentas SQL e capacidade sob demanda. Para um SaaS ou agente, isso pode simplificar partes da infraestrutura quando o padrão de uso se encaixa no serviço. A decisão fica mais clara ao medir um fluxo do próprio produto e conferir quais responsabilidades continuam na aplicação.

Perguntas frequentes sobre a combinação

Preciso do Earth para usar o SurrealDB 4?

Não. O SurrealDB 4 também pode rodar em infraestrutura própria e em aplicações embarcadas. Earth é uma opção gerenciada de implantação serverless. Opções de execução.

Posso criar um database para cada agente de IA?

Esse é um dos cenários propostos pelo Earth. Os planos de autosserviço consultados limitam a conta a até 100 databases e compartilham franquias, portanto a quantidade pretendida precisa ser confrontada com as condições comerciais. Limites oficiais.

O Earth garante menor custo para qualquer SaaS?

A economia depende do perfil de tráfego, do armazenamento, das requisições e das horas ativas somadas dos databases. Compare uma carga representativa do produto com alternativas de capacidade dedicada. Modelo de cobrança.

Última checagem das fontes: 3 de novembro de 2026.

Continue a leitura

SurrealDB 4: SQL, novo executor e o que muda para quem cria aplicações

SurrealDB Earth: como funciona o banco serverless na Cloudflare