Databricks Lakebase Search desafia a pilha de busca separada

A Databricks disponibilizou de forma geral o Databricks Lakebase Search na AWS e no Azure, colocando dois mecanismos de busca dentro de seu serviço Postgres gerenciado. A versão de 28 de setembro oferece recuperação vetorial e classificação por palavras-chave com BM25, sem exigir um banco de dados de busca separado. Isso desafia uma arquitetura conhecida de IA: o Postgres mantém registros operacionais, enquanto outro sistema indexa cópias para recuperação.

A empresa afirma que sua nova extensão vetorial pode pesquisar 100 milhões de vetores com 97% de recall e latência P99 de 71 milissegundos. Também alega ter o dobro da taxa de transferência do segundo melhor sistema em seu benchmark e custo quatro vezes menor que o Postgres em nuvem executando pgvector. Esses resultados são relevantes, mas a Databricks produziu os testes e não publicou uma validação independente completa.

A história maior não é apenas mais um índice vetorial. O Databricks Lakebase Search é uma tentativa de fazer com que o Postgres operacional processe recuperação semântica, por palavras-chave e híbrida em escala de agentes. Se a arquitetura funcionar em cargas de trabalho reais de produção, algumas equipes poderão eliminar um serviço de busca e os pipelines de dados ao seu redor. A pressão recai tanto sobre implantações do pgvector quanto sobre sistemas de busca dedicados que justificavam sua complexidade por meio de maior escala.

Databricks Lakebase Search leva a recuperação ao Postgres

O lançamento transforma a busca de um serviço acoplado em uma capacidade gerenciada do banco de dados operacional.

O anúncio técnico apresenta duas extensões do Postgres. lakebase_vector processa busca aproximada por vizinhos mais próximos, que encontra vetores próximos a uma consulta sem comparar todos os registros possíveis. lakebase_text fornece BM25, um método de classificação que pondera frequência de termos, comprimento do documento e raridade dos termos em uma coleção.

Ambas as extensões estão disponíveis de forma geral para projetos Lakebase na AWS e no Azure. Os desenvolvedores podem instalar qualquer uma das extensões ou combiná-las para recuperação híbrida. A combinação importa porque a busca vetorial e por palavras-chave resolve diferentes modos de falha.

A busca vetorial compara embeddings, que são representações numéricas de significado. Ela pode associar uma consulta como “carro esportivo rápido” a registros que mencionam um modelo de automóvel, mesmo quando essas palavras exatas não estão presentes. A busca por palavras-chave continua sendo melhor para identificadores, nomes, códigos de erro, números de produtos e outros termos cuja forma literal carrega significado.

A busca híbrida executa os dois métodos e combina suas classificações. Um agente de suporte com IA pode usar similaridade semântica para encontrar incidentes conceitualmente relacionados enquanto preserva uma correspondência exata para um código de erro específico. Um agente de ecommerce poderia interpretar a intenção de um comprador sem perder um número de modelo solicitado.

Essas operações são executadas ao lado dos registros transacionais, em vez de contra uma cópia sincronizada separadamente. Um desenvolvedor pode filtrar a recuperação usando campos atuais, como locatário, status de estoque, direitos de acesso ou estado do fluxo de trabalho. A Databricks afirma que lakebase_vector aplica filtros durante a varredura de blocos de índice, reduzindo a necessidade de recuperar um amplo conjunto de candidatos e descartar posteriormente linhas não autorizadas ou irrelevantes.

Esse design aborda um problema persistente em sistemas de recuperação. A versão mais recente de um registro geralmente vive no banco de dados da aplicação, enquanto a versão pesquisável chega depois por meio de um pipeline de extração. Mesmo um atraso curto pode expor um agente a documentos excluídos, permissões desatualizadas ou estoque que já não existe.

Manter a recuperação próxima aos dados operacionais reduz essa janela de sincronização. Também pode diminuir o número de sistemas que os engenheiros precisam monitorar, proteger e reparar. A mudança é especialmente relevante para equipes que constroem uma base de conhecimento pesquisável, em que controles de acesso e alterações nos documentos precisam permanecer alinhados aos resultados de busca.

O Lakebase Search não elimina todas as etapas de movimentação de dados. Os embeddings ainda precisam ser gerados, o conteúdo de origem pode vir de fora do Postgres, e tabelas de lakehouse exigem sincronização antes de servir consultas. A diferença é que as aplicações podem consultar os índices resultantes por meio de tipos e operadores conhecidos do Postgres.

A Databricks também está vinculando o recurso à sua plataforma lakehouse mais ampla. Sua documentação de produto explica como tabelas do Unity Catalog podem ser sincronizadas com o Lakebase. Durante esse processo, uma coluna de embedding pode se tornar um vetor do Postgres, enquanto o texto-fonte pode se tornar um tsvector, a representação otimizada do PostgreSQL para recuperação de texto.

A mudança imediata é, portanto, concreta. O Lakebase agora oferece índices gerenciados nativos para busca baseada em significado e em termos exatos, e as aplicações podem consultá-los junto com campos operacionais. A tensão começa com o que essa consolidação substitui.

Agentes de IA pressionam o pipeline de busca separado

Cargas de trabalho de agentes tornam mais difícil justificar erros de sincronização e infraestrutura ociosa.

Uma arquitetura de busca tradicional geralmente contém ao menos dois armazenamentos de dados. O Postgres registra transações e o estado da aplicação. Um mecanismo de busca ou banco de dados vetorial recebe cópias transformadas por meio de um pipeline de extração, transformação e carregamento.

Essa divisão pode funcionar bem em escala, mas cria obrigações operacionais. As equipes precisam detectar atualizações com falha, reproduzir registros ausentes, coordenar alterações de esquema, preservar a semântica de exclusão e reproduzir permissões do banco de dados em outro sistema. Também precisam de um plano para reconstruir índices sem interromper a aplicação.

Os agentes de IA amplificam essas obrigações porque a recuperação se torna parte de um ciclo de decisão. Uma página de busca convencional pode tolerar um resultado imperfeito enquanto o usuário analisa alternativas. Um agente pode agir imediatamente após recuperar um registro, tornando atualização e autorização mais importantes.

Um agente de gestão de contas ilustra o problema. Ele pode pesquisar notas de reunião semanticamente, corresponder a um identificador exato de contrato e filtrar resultados pelas permissões atuais do usuário. Se esses três sinais vivem em sistemas diferentes, a aplicação precisa reconciliá-los antes que o modelo possa responder com segurança.

O mesmo problema aparece no comércio. Um agente de compras pode interpretar uma solicitação ambígua por meio de embeddings, mas disponibilidade e restrições regionais vêm de colunas operacionais que mudam rapidamente. Pesquisar uma cópia desatualizada pode produzir uma resposta convincente para um item indisponível.

O uso em picos cria outra fonte de pressão. A busca empresarial voltada a humanos frequentemente segue horários de trabalho previsíveis. Agentes podem gerar muitas chamadas de recuperação paralelas ao planejar, verificar e revisar uma tarefa. Uma única solicitação de usuário pode acionar várias buscas em vez de uma.

A Databricks projetou o Lakebase Search em torno dessa demanda irregular. O Lakebase separa armazenamento durável de computação, mantendo os dados em armazenamento de objetos e usando memória e NVMe local como caches. A computação de busca pode ser suspensa quando ociosa e retomada quando outra consulta chega.

A empresa relata uma latência P90 de 1,13 segundo para a primeira consulta após escalar a zero em um índice com 100 milhões de vetores de 768 dimensões. Também afirma que a mesma coleção pode ser atendida com uma Lakebase Compute Unit. São medições da empresa, não expectativas universais, mas mostram o modelo operacional pretendido.

Uma consulta fria de um segundo não servirá a todas as aplicações interativas. No entanto, ela pode ser aceitável para um agente interno usado com pouca frequência se evitar a execução contínua de um grande cluster de busca. As equipes podem manter a computação ativa quando a latência importa e permitir que ambientes mais tranquilos sejam suspensos.

A construção de índices também se afasta do caminho principal de transações. A Databricks afirma que pode treinar centróides a partir de uma amostra, distribuir a atribuição e a quantização de vetores e então gravar blocos de índice independentes. O descarregamento futuro para mecanismos distribuídos como o Spark faz parte da direção da empresa, embora o anúncio diga para aguardar essa capacidade mais ampla.

Isso importa porque grandes construções de índices competem com cargas de trabalho transacionais quando consomem os mesmos recursos de processador, memória e armazenamento. Afastar esse trabalho do banco de dados primário pode reduzir interferências. Também muda o modelo de custo, de manter um servidor de índice permanentemente provisionado para pagar por computação de recuperação ativa e armazenamento durável.

O alvo da pressão não é toda implantação de busca dedicada. Grandes equipes de busca frequentemente precisam de analisadores especializados, pipelines de classificação personalizados, observabilidade avançada ou recursos desenvolvidos ao longo de anos. Em vez disso, o Lakebase pressiona a arquitetura comum em que um segundo sistema existe principalmente porque a busca do Postgres deixou de escalar confortavelmente.

Essa distinção mantém o anúncio com os pés no chão. A Databricks não argumenta que um banco de dados deva executar toda carga de trabalho de busca. Ela argumenta que mais aplicações de IA podem adiar, simplificar ou evitar a divisão.

Lakebase Vector Search mira o modelo de memória do pgvector

A disputa principal é entre o Lakebase Search apoiado por armazenamento e os índices pgvector intensivos em memória em grande escala.

O Pgvector tornou o Postgres um ponto de partida prático para recuperação semântica. Ele adiciona tipos vetoriais, operadores de distância, busca exata e índices aproximados sem forçar os desenvolvedores a usar uma interface de banco de dados desconhecida. Continua sendo open source e amplamente disponível em serviços Postgres hospedados.

Suas opções aproximadas padrão incluem HNSW e IVFFlat. O HNSW cria um grafo multicamada que conecta vetores próximos. Ele oferece um equilíbrio favorável entre velocidade e recall, mas a construção do grafo leva tempo e o índice consome memória significativa. O IVFFlat agrupa vetores em listas e pesquisa os grupos mais promissores, reduzindo custos de memória e construção, embora geralmente ofereça desempenho de consulta inferior.

A própria orientação do pgvector documenta essas compensações. Ela observa que os índices HNSW são construídos muito mais rapidamente quando o grafo cabe em maintenance_work_mem. Também alerta que aumentar os candidatos de busca melhora o recall ao custo da velocidade de consulta.

A Databricks argumenta que essas restrições se tornam mais difíceis quando um grafo HNSW cresce além da memória de uma máquina. Buscar uma cadeia de nós do grafo no armazenamento remoto de objetos pode gerar muitas leituras pequenas e aleatórias. Um design otimizado para memória residente se torna menos eficiente quando o conjunto de trabalho está frio.

A busca vetorial do Lakebase usa agrupamento hierárquico de arquivos invertidos para mudar esse padrão de acesso. Os vetores são agrupados em blocos contíguos. Uma consulta primeiro pontua os centróides dos clusters e, depois, lê os blocos associados aos clusters mais promissores.

A extensão combina esse layout com a quantização binária RaBitQ, que comprime cada vetor para aproximadamente um bit por dimensão na pontuação inicial de candidatos. A Databricks descreve essa representação como cerca de 32 vezes menor que um vetor padrão de ponto flutuante de 32 bits. Em seguida, o sistema reclassifica um conjunto limitado de candidatos usando vetores de precisão total.

Esse mecanismo torna o índice mais adequado tanto ao armazenamento de objetos quanto ao cache local. Uma consulta fria lê vários blocos relevantes em vez de seguir centenas de ligações de grafo. Uma consulta quente pode varrer códigos binários compactos enquanto mantém uma pegada ativa menor na memória.

Databricks afirma que um único índice lakebase_ann pode armazenar mais de um bilhão de vetores. A documentação também sustenta que a criação de índices é 50 a 100 vezes mais rápida do que HNSW. Esses números descrevem a implementação da empresa e não devem ser aplicados automaticamente a todos os esquemas, modelos de embedding ou distribuições de filtros.

O benchmark de destaque utilizou 100 milhões de vetores do conjunto de dados LAION. Segundo a Databricks, o Lakebase entregou o dobro da taxa de processamento do segundo melhor sistema testado. A empresa relatou 97% de recall com P99 de 71 milissegundos, o que significa que 99% das consultas medidas foram concluídas dentro dessa latência, recuperando os vizinhos verdadeiros na taxa informada.

O benchmark também gerou a alegação de custo quatro vezes menor em comparação com um fornecedor não identificado de Postgres em nuvem que usa pgvector. A Databricks observa que pgvector e DiskANN foram testados em instâncias únicas de grande porte. Essa ressalva limita a comparação, pois arquitetura, configuração, hardware, concorrência e premissas de preço podem alterar materialmente os resultados.

Um benchmark pode mostrar que uma abordagem merece ser avaliada sem, contudo, decidir uma compra. A Databricks não demonstrou que todas as cargas de trabalho com pgvector devem migrar. Índices menores podem caber confortavelmente na memória, e uma instalação existente de pgvector pode ser barata, portátil e fácil de operar.

O pgvector também oferece suporte a quantização binária, indexação de meia precisão, varreduras iterativas, particionamento e esforço de busca configurável. Equipes com implantações ajustadas têm mais opções do que um gráfico de linha de base simples sugere. A extensão de código aberto funciona em muitos ambientes Postgres, enquanto o Lakebase Search pertence a um serviço gerenciado da Databricks.

A compatibilidade reduz o custo de migração, porém. A Databricks afirma que lakebase_vector usa os tipos de vetor, operadores de distância e sintaxe de consulta do pgvector. Uma aplicação pode manter SQL familiar enquanto cria um índice lakebase_ann em vez de um índice HNSW ou IVFFlat.

Esse é um movimento competitivo deliberado. A Databricks não está pedindo aos desenvolvedores que abandonem o modelo de programação do pgvector. Ela oferece um mecanismo diferente de armazenamento e indexação por trás de grande parte da mesma interface.

A evidência de clientes oferece um sinal prático. A Conexiom disse à Databricks que executa busca híbrida BM25 em mais de 100 milhões de linhas usando metade da capacidade computacional de sua configuração anterior com pgvector. O relato é útil por descrever uma carga operacional, mas continua sendo uma declaração de cliente selecionada pelo fornecedor, sem metodologia publicada de forma independente.

O argumento a favor da busca vetorial do Lakebase é mais forte quando a coleção é grande, a demanda por consultas é irregular e filtros operacionais importam. O argumento se enfraquece quando as equipes priorizam portabilidade de infraestrutura, têm demanda previsível e contínua ou já cumprem metas de latência com pgvector.

O BM25 Nativo Muda a Equação da Busca de Texto Completo

A parte mais discreta do lançamento pode ser mais importante do que o benchmark de vetores.

Muitos produtos de busca com IA supervalorizam embeddings. A correspondência semântica ajuda quando usuários e documentos expressam a mesma ideia com palavras diferentes. Ela é menos confiável quando uma consulta contém um identificador exato que um modelo de embedding considera fraco ou desconhecido.

Considere um agente procurando por “CVE-2026-1234”, um número de conta de cliente ou o nome de um componente específico. A busca por similaridade pode retornar registros conceitualmente relacionados, mas não reconhecer a importância da string exata. A classificação por palavras-chave fornece um sinal de recuperação separado que preserva correspondências literais.

A extensão lakebase_text do Lakebase adiciona um índice lakebase_bm25 compatível com valores tsvector do PostgreSQL e operadores de consulta de texto. O BM25 incorpora a frequência de termos em toda a coleção e o tamanho dos documentos, ajudando termos raros a contribuir mais do que termos comuns.

O PostgreSQL já oferece recursos substanciais de texto completo. Ele pode analisar documentos, normalizar palavras, remover stop words, criar índices GIN e classificar resultados com ts_rank ou ts_rank_cd. A documentação oficial de classificação observa que suas funções integradas de rank usam frequência lexical, proximidade e informações estruturais.

Essas funções não usam estatísticas globais da coleção da mesma forma que o BM25. Essa diferença importa quando um produto precisa de relevância no estilo de mecanismos de busca, e não de simples correspondência. Historicamente, as equipes adicionaram lógica de classificação personalizada ou moveram o texto para um mecanismo dedicado.

A Databricks afirma que lakebase_text usa Block-Max WAND para recuperação top-K. Esse algoritmo ignora regiões que não podem produzir um resultado competitivo com as maiores pontuações atuais. Em vez de pontuar completamente cada documento correspondente, o mecanismo concentra o trabalho nos candidatos que podem entrar no conjunto de resultados solicitado.

A abordagem complementa a recuperação vetorial. Uma consulta de suporte poderia usar lakebase_bm25 para texto exato de erros e lakebase_ann para descrições semanticamente semelhantes de incidentes. A fusão recíproca de rankings pode então combinar ambas as listas ordenadas sem presumir que suas pontuações brutas compartilham a mesma escala.

É nesse ponto que o Databricks Lakebase Search se torna mais do que um índice vetorial mais rápido. Ele oferece uma pilha de busca com dois modelos distintos de recuperação dentro do mesmo banco de dados. A linha operacional, o embedding, a representação textual e os atributos de filtragem podem permanecer juntos.

Essa consolidação afeta a segurança tanto quanto a conveniência. Uma aplicação pode expressar limites de tenant e verificações de permissão como predicados SQL junto à recuperação. Os engenheiros ainda precisam testar se todos os caminhos de índice aplicam os filtros corretamente, mas evitam recriar todo um modelo de autorização em um serviço separado.

Ela também simplifica o comportamento de escrita. Um registro recém-inserido pode se tornar pesquisável sem esperar que um segundo banco de dados confirme um evento. Atualizações e exclusões permanecem em um ambiente transacional familiar, embora o tempo de manutenção dos índices e as fontes sincronizadas do lakehouse ainda exijam medição.

Mecanismos dedicados mantêm vantagens importantes. Elasticsearch e sistemas semelhantes oferecem ampla análise linguística, pontuação personalizada, agregações, destaque de resultados, ferramentas de consulta e controles operacionais desenvolvidos especificamente para busca. O suporte a BM25 do Lakebase não elimina essas diferenças.

Portanto, a comparação relevante é arquitetural. Se uma aplicação precisa de recuperação semântica, classificação de termos exatos, filtros operacionais atualizados e SQL convencional, o Lakebase pode abranger uma parcela maior dessa carga em um só lugar. Se a própria busca é o produto, recursos especializados ainda podem justificar um sistema separado.

O Benchmark Deixa Questões de Produção Sem Resposta

A Databricks mostrou um mecanismo atraente, mas os compradores ainda precisam de evidências específicas para suas cargas de trabalho.

A maior incerteza é a independência do benchmark. A Databricks selecionou os sistemas, configurações, conjunto de dados, tipos de instância e premissas de custo por trás de sua comparação publicada. A empresa identifica o VectorDBBench e o conjunto de dados LAION de 100 milhões, mas o anúncio não fornece detalhes suficientes para reproduzir todos os resultados apenas com base no artigo.

Recall e latência também interagem. A recuperação aproximada evita deliberadamente a comparação exaustiva, portanto os engenheiros ajustam quantos clusters ou candidatos uma consulta examina. Recall maior frequentemente exige mais trabalho. Um único ponto de desempenho não pode descrever toda a curva em diferentes níveis-alvo de recall.

Os filtros podem alterar essa curva novamente. Consultas comerciais reais podem restringir resultados por tenant, geografia, tempo, estado de inventário ou autorização. Um benchmark com distribuição uniforme não representa necessariamente filtros de produção altamente seletivos ou desiguais.

O formato dos dados também importa. Embeddings de imagem do LAION diferem de embeddings de documentos empresariais, catálogos de produtos, código-fonte ou registros de clientes. As dimensões variam, duplicatas surgem, atualizações chegam de forma desigual e alguns tenants dominam o tráfego. Cada fator pode afetar o comportamento do cache e a qualidade do índice.

O desempenho de inicialização a frio merece interpretação cuidadosa. O P90 relatado de 1,13 segundo se aplica a uma configuração específica de 100 milhões de vetores e 768 dimensões. Aplicações com metas interativas rígidas podem precisar de capacidade computacional ativa, em vez de scale-to-zero. As equipes devem testar tanto a primeira consulta quanto o pico de consultas seguinte.

As restrições operacionais também exigem atenção. Segundo a documentação, habilitar o Lakebase Search reinicia todos os recursos computacionais de um projeto, interrompe conexões ativas e não pode ser revertido. Isso torna a ativação uma mudança planejada de infraestrutura, e não uma simples alternância inofensiva de extensão.

A portabilidade é outro trade-off. O Lakebase apresenta tipos padrão do Postgres e sintaxe familiar do pgvector, mas seus novos métodos de acesso a índices são recursos proprietários gerenciados. Uma equipe pode manter grande parte de seu SQL de aplicação e ainda assim ficar dependente da Databricks para comportamento dos índices, escalabilidade e preços.

A mesma preocupação se aplica ao BM25. Colunas padrão tsvector continuam sendo objetos reconhecíveis do Postgres, mas o índice lakebase_bm25 e suas características de execução são específicos do Lakebase. Sair da plataforma pode exigir a reconstrução de índices e novos testes de qualidade de classificação em outro lugar.

As alegações de custo exigem medição direta. A suspensão serverless pode reduzir despesas para uso irregular, mas alta concorrência sustentada pode favorecer outro modelo. Geração de embeddings, tabelas sincronizadas, armazenamento, transferência de dados e serviços Databricks ao redor contribuem para a arquitetura total.

Portanto, as equipes devem avaliar o Lakebase Search com consultas representativas, e não com um ranking genérico. Um corpus de teste útil inclui registros atuais, registros excluídos, documentos com controle de acesso, identificadores raros, consultas ambíguas em linguagem natural e os filtros com maior probabilidade de reduzir o recall.

Elas também devem comparar resultados operacionais. Meçam atualização dos dados, recuperação de falhas, impacto da criação de índices, consistência de permissões e o tempo da equipe necessário para gerenciar pipelines. Remover um serviço externo pode ser valioso mesmo quando a latência bruta das consultas muda pouco.

Nenhuma dessas questões invalida o lançamento. Elas definem o que “estado da arte” precisa significar fora de um benchmark de fornecedor. A arquitetura tem uma justificativa técnica crível, mas a evidência de produção precisa mostrar que suas vantagens sobrevivem à distribuição de dados e à carga de trabalho de cada comprador.

O Que Observar Após o Lakebase Search Chegar à GA

Três sinais determinarão se o Lakebase Search se tornará um recurso padrão do Postgres ou continuará sendo uma opção específica da Databricks.

O primeiro sinal é o desempenho reproduzível. Testes independentes devem comparar o Lakebase com pgvector ajustado, serviços baseados em DiskANN e mecanismos de busca dedicados em vários alvos de recall. Eles devem publicar especificações de instâncias, concorrência, seletividade de filtros, estado de cache, tempo de criação de índices e premissas completas de custo.

Resultados próximos às alegações da Databricks fortaleceriam o argumento de que índices clusterizados apoiados em armazenamento se adaptam melhor a grandes coleções serverless do que grafos orientados à memória. Uma diferença ampla enfraqueceria a narrativa de desempenho, mesmo que a consolidação ainda ofereça benefícios operacionais.

O segundo sinal é a adoção entre equipes que substituem arquiteturas de dois sistemas. A Conexiom fornece um exemplo inicial, mas o mercado precisa de mais relatos que descrevam escala de produção, frequência de atualizações, volume de consultas e modelos de permissão. As histórias mais persuasivas documentarão um cluster de busca ou pipeline ETL removido, e não apenas uma demonstração bem-sucedida.

A adoção também revelará se a sintaxe familiar do Postgres reduz o atrito da migração. Se as equipes puderem alterar definições de índice mantendo seu modelo de dados e suas consultas, o Lakebase Search terá uma rota prática para aplicações existentes. Se as migrações exigirem mudanças extensas de classificação, a alegação de compatibilidade terá menos peso.

O terceiro sinal é a resposta competitiva. O pgvector continua adicionando opções de quantização, filtragem e varreduras iterativas. Fornecedores de Postgres gerenciado podem aprimorar a arquitetura de armazenamento ou introduzir suas próprias extensões de busca. Provedores dedicados de busca podem destacar controles maduros de classificação, flexibilidade de implantação e recursos de recuperação híbrida.

A Databricks começou a posicionar o Lakebase como Postgres gerenciado para aplicações de IA em seu anúncio de lançamento de 2025. Esta versão torna esse posicionamento mais concreto. Transações, por si só, não tornam um banco de dados pronto para agentes se toda consulta séria de recuperação ainda precisa sair do sistema.

A conclusão imediata é mais restrita e mais útil. O Databricks Lakebase Search oferece aos desenvolvedores um único ambiente gerenciado para registros operacionais, similaridade vetorial, classificação BM25 e filtragem SQL. Seu índice vetorial clusterizado e quantizado aborda diretamente o modelo de memória que limita grandes implantações de pgvector.

A próxima decisão cabe às equipes de engenharia. Crie um teste de recuperação representativo, inclua tráfego frio e aquecido, aplique filtros reais de permissões e compare toda a carga operacional. Se o Lakebase preservar a relevância enquanto elimina a infraestrutura de sincronização, a simplificação arquitetural importará mais do que qualquer barra isolada de benchmark.