Lakebase

A lacuna entre aplicações e analytics, e como o Lakebase a resolve

Lakebase é um Postgres totalmente gerenciado e nativo da Databricks Data Intelligence Platform, pensado pra unificar workload transacional e analítico com governança única via Unity Catalog, sincronização bidirecional e recursos como autoscaling, scale-to-zero e database branching.

Por que o cache padrão do Postgres não funciona dentro de um banco desagregado

O Lakebase separa compute de storage, e isso quebra a lógica de cache que o Postgres tradicional assume há décadas. A Databricks detalhou como resolveu isso combinando um cache local autoscaling, shared buffers maiores em compute fixo e huge pages na stack inteira, com ganhos de até 5x em leitura de storage.

Agente que sobrevive à queda de worker: durabilidade real combinando Temporal e Lakebase

Agente de IA de longa duração falha de um jeito diferente de API request-response: o processo pode cair no meio de uma etapa que já produziu efeito parcial. Um projeto de referência combina Temporal para reexecução determinística de workflow com Lakebase Postgres para estado operacional consultável, mas a idempotência de cada passo continua sendo responsabilidade de quem escreve o código do agente.

Uma falha no PostGIS expôs todo tenant do Lakebase Postgres, e a Databricks corrigiu antes de qualquer exploração

Um pesquisador encontrou uma falha de bounds-check na extensão address_standardizer do PostGIS, explorável por qualquer usuário comum do Lakebase Postgres e do Neon, e a Databricks corrigiu antes da divulgação pública.

Lakebase Postgres decide sozinho quando trocar de tamanho de máquina, usando HyperLogLog

A Databricks detalhou como o Lakebase Postgres faz autoscaling automático de VM sem derrubar conexão, combinando uso de CPU, uso de memória e uma estimativa de working set feita com uma variante de HyperLogLog sensível a tempo.

Por que o Lakebase colocou object storage embaixo de um Postgres transacional

A resposta não é sobre velocidade: é sobre onde fica a fonte da verdade quando quem opera o banco pode ser um agente, não um humano.

Lakebase Postgres: por que o banco transacional da era dos agentes começa pelo object storage

A Databricks anunciou os detalhes de arquitetura do Lakebase Postgres. Minha leitura sobre por que separar compute e armazenamento pode ser o passo que faltava para bancos operacionais aguentarem cargas geradas por agentes.

Vector Store no Databricks virou três produtos diferentes, e escolher errado sai caro

AI Search, o novo lakebase_vector em beta e a variante em batch via SQL resolvem o mesmo problema, guardar e buscar embedding, de formas bem diferentes.

Lakebase ganha disaster recovery entre regiões, mas ainda deixa Delta table de fora

Lakebase Disaster Recovery replica metadado do Unity Catalog, dado de tabela gerenciada e ativos de workspace pra uma região secundária, mas Delta table e pipelines de sincronização ficam fora da replicação por enquanto.

O DNA do Neon Postgres dentro do Lakebase: o que a separação compute/storage muda para quem provisiona banco

Na conversa com Nikita Shamgunov, VP de Engenharia da Databricks, fica mais claro de onde vem a arquitetura do Lakebase, e por que ‘agente provisionando banco sozinho’ deixou de ser ficção científica.