Spanner Omni chega à disponibilidade geral e roda fora da infraestrutura do Google

O Google anunciou a disponibilidade geral (GA) do Spanner Omni, a versão "deploy anywhere" do seu banco de dados↳Banco de dados134 conteúdosSQL ou NoSQL: eis a questão!!Data · mar 2020Banco de dados: como organizar e dar segurança para milhões de dados de loteriasData · mai 20215 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data → distribuído Spanner, segundo reportagem do InfoQ. O produto roda no data center do próprio cliente, em outra nuvem ou até num notebook, e a engenharia por trás disso é o que torna esta GA diferente de qualquer outro lançamento de banco gerenciado: o Spanner original depende de dois componentes exclusivos da infraestrutura do Google, o sistema de arquivos distribuído Colossus e o serviço de tempo TrueTime, baseado em relógios atômicos e GPS. Tirar o Spanner dali significou substituir os dois por software.

Para quem avalia bancos de dados globais com replicação entre regiões, o Spanner Omni muda o cálculo: não é mais "Spanner gerenciado contra outro banco", é "Spanner gerenciado contra Spanner Omni", com o preço pago em latência de cauda e esforço operacional, não em paridade de recursos.

O que foi trocado por software

No lugar do Colossus, o Spanner Omni introduz o que o Google chama de camada de abstração parecida com Colossus: ela escreve em sistemas de arquivos locais anexados e os disponibiliza pela rede para outros nós, com divisão e rebalanceamento de shards automatizados. O Google é direto sobre a limitação: essa camada não é o Colossus, mas funciona como substituto suficiente para ter desempenho comparável ao serviço gerenciado na maioria das cargas de trabalho.

O TrueTime recebeu o mesmo tratamento. A alternativa em software oferece sincronização de tempo com margem de erro limitada entre servidores, do mesmo jeito que o original faz com relógios atômicos e GPS. A explicação do Google para isso funcionar está em como o Spanner já se comporta: o banco sobrepõe as esperas de incerteza de tempo com outros trabalhos, então tolera margens de incerteza mais fracas do que o TrueTime entrega na prática. É essa folga que permite medir tempo em hardware heterogêneo sem limitar disponibilidade ou desempenho.

Consenso Paxos, sharding automático e replicação síncrona continuam sem mudanças, e os benchmarks internos do Google afirmam milhões de queries por segundo em petabytes de dados numa única implantação regional.

A reação de quem vai operar isso

A reação de praticantes tem focado no que isso significa para operar o sistema no dia a dia. Carlos Pérez Martín, CTO da Q2BSTUDIO, argumentou que a mudança não é primariamente uma questão de arquitetura:

A mudança interessante é operacional, não arquitetural: quando o mesmo motor roda nos seus racks, os domínios de falha passam a ser seus.

The interesting shift is operational, not architectural: once the same engine runs in your racks, the failure domains become yours.Carlos Pérez Martín, CTO da Q2BSTUDIO

Ele apontou três consequências práticas. A topologia de quórum e testemunhas precisa ser recalculada para o orçamento de latência local, e quando um data center inteiro vira a unidade de falha, é o p99, não a média, o que a aplicação sente. Aplicar patches, versionar upgrades e fazer rollback deixam de ser fila de ticket de outra empresa e passam a ser problema de gestão de mudanças com o nome do cliente na etiqueta. E mover a residência dos dados para um data center privado traz junto o fardo de backup, gestão de chaves e auditoria.

O teste que ele recomenda é mais estreito do que uma comparação de funcionalidades:

Um piloto comparável ao serviço gerenciado, medido em latência de cauda e esforço operacional em vez de paridade de recursos, é a forma mais barata de precificar essa troca.

A like-for-like pilot against the managed service, measured on tail latency and ops toil instead of feature parity, is the cheapest way to price that trade.Carlos Pérez Martín, CTO da Q2BSTUDIO

Sem SLA, com topologias no lugar dele

A própria documentação do Google sustenta essa leitura. Como o Spanner Omni roda em infraestrutura gerenciada pelo cliente, o Google não oferece SLA de disponibilidade, e indica em vez disso arquiteturas de referência que ajudariam a alcançar alta disponibilidade comparável. No lugar do SLA entram topologias:

• Servidor único: upgrades causam indisponibilidade.
• Zona única: mínimo de três servidores.
• Multi-zona: no mínimo três zonas com três servidores cada.
• Multi-cluster: três zonas em dois ou mais clusters.

Para quem opera no Brasil, onde o Google Cloud↳Google Cloud13 conteúdosPrograma da Google Cloud no Brasil projeta formar de forma gratuita 30 mil universitáriosDev (Back & Front) · mar 2026Google Cloud OnBoard capacita estudantes e desenvolvedores de TIGestão Dev & TI · mai 2019Desenvolvedores poderão participar de treinamento gratuito do Google CloudGestão Dev & TI · mai 2019Ver tudo em DevSecOps → mantém apenas a região de São Paulo, essa lista importa de um jeito específico: o próprio Google cita como caso de uso a alta disponibilidade multirregional em jurisdições onde opera só um data center mas a soberania de dados é exigida. É exatamente o cenário de quem precisa manter dados no país e, ao mesmo tempo, replicar entre instalações físicas distintas sem depender de uma segunda região do Google por aqui.

A carga operacional também aparece no ferramental. Manutenção de rotina, upgrades de versão e monitoramento de infraestrutura passam a ser internos, com monitoramento via alertas do Prometheus e dashboards do Grafana em vez do Cloud Monitoring, além de um comando de diagnóstico que coleta logs, traces e thread stacks.

Limites que pesam na avaliação

Duas fronteiras importam na hora de decidir migrar. Integrações que dependem do Google Cloud ficam de fora, incluindo BigQuery, Knowledge Catalog e Gemini Enterprise, e o Google reconhece lacunas de funcionalidades remanescentes em relação ao serviço gerenciado, sem nomear quais nem quando fecham. A documentação lista Google Cloud e Amazon como nuvens públicas suportadas, além de instalações on-premises e notebooks; o Azure não é mencionado, o que pesa para quem já padronizou infraestrutura crítica na nuvem da Microsoft.

O que o banco mantém

O que não muda é o banco em si. O Spanner Omni suporta GoogleSQL, PostgreSQL e Spanner Graph Language, e combina modelos relacional, de grafo, chave-valor e vetorial com busca full-text e um mecanismo colunar. Suporte ao Model Context Protocol↳MCP7 conteúdosArquitetura de Sistemas Cognitivos: Integração de RAG, MCP e LLMs no Ecossistema .NETDev (Back & Front) · abr 2026MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025Agentes de IA com LLMs de Código Aberto: Integração Prática com o Model Context Protocol (MCP)AI · ago 2025Ver tudo em AI → via MCP Toolbox permite que agentes inspecionem schemas e usem o banco como camada de memória operacional entre implantações.

A GA adiciona criptografia TLS, autenticação e autorização, logs de auditoria, backup e restore, e worker nodes, nós de computação stateless que tiram operações em segundo plano dos servidores primários.

Licenciamento em duas camadas

O licenciamento tem duas camadas. A Developer Edition é gratuita para uso fora de produção, com licença padrão de 90 dias que exclui backups e worker nodes, embora uma implantação de servidor único com 4 vCPUs ou menos não expire e inclua backup e restore; estender além de 90 dias exige preencher um formulário do Google. A Commercial Edition é uma assinatura anual baseada em vCPU, sem preço publicado.

Quem já está usando

Os padrões de implantação relatados por early adopters confirmam o enquadramento operacional. Uma empresa roda o Spanner gerenciado como banco primário e o Spanner Omni em outro lugar como failover hot-cold. Outra padroniza uma única camada de banco de dados entre ambientes diferentes. Uma terceira moderniza sistemas on-premises usando hardware já existente.

O Mercado Livre, que construiu um gateway interno de desenvolvedores oferecendo um serviço NewSQL baseado em Spanner, deu o argumento de resiliência quando a versão de preview foi lançada em abril de 2026. O gerente técnico sênior Diego Oscar Narducci afirmou que a empresa mantinha vigilância de longa data contra ameaças internas, ransomware e quedas de nuvem, e que o Spanner Omni permite resiliência entre nuvens que seria significativamente mais complexa de implementar com outros provedores de nuvem.

Um detalhe de linha do tempo marca a pressa do lançamento: a visão geral do Spanner Omni na documentação do Google foi atualizada pela última vez em 28 de setembro de 2026, dois dias antes do anúncio de GA, e ainda trazia o selo de Preview com limitações que a versão final remove, incluindo ausência de criptografia TLS, de backups e restores, e implantações que paravam de aceitar gravações após 90 dias.

Fonte: InfoQ