<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Lakebase on Wiliam Rosa | Lakehouse, Dados &amp; IA</title>
    <link>https://wiliamrosa.github.io/tags/lakebase/</link>
    <description>Recent content in Lakebase on Wiliam Rosa | Lakehouse, Dados &amp; IA</description>
    <image>
      <title>Wiliam Rosa | Lakehouse, Dados &amp; IA</title>
      <url>https://wiliamrosa.github.io/images/wiliam-rosa-blog-og.png</url>
      <link>https://wiliamrosa.github.io/images/wiliam-rosa-blog-og.png</link>
    </image>
    <generator>Hugo</generator>
    <language>pt-br</language>
    <lastBuildDate>Thu, 10 Sep 2026 15:00:00 -0300</lastBuildDate>
    <atom:link href="https://wiliamrosa.github.io/tags/lakebase/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>A lacuna entre aplicações e analytics, e como o Lakebase a resolve</title>
      <link>https://wiliamrosa.github.io/articles/lakebase-lacuna-aplicacoes-analytics/</link>
      <pubDate>Thu, 10 Sep 2026 15:00:00 -0300</pubDate>
      <guid>https://wiliamrosa.github.io/articles/lakebase-lacuna-aplicacoes-analytics/</guid>
      <description>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.</description>
    </item>
    <item>
      <title>Por que o cache padrão do Postgres não funciona dentro de um banco desagregado</title>
      <link>https://wiliamrosa.github.io/articles/lakebase-postgres-cache-huge-pages-shared-buffers/</link>
      <pubDate>Thu, 10 Sep 2026 09:00:00 -0300</pubDate>
      <guid>https://wiliamrosa.github.io/articles/lakebase-postgres-cache-huge-pages-shared-buffers/</guid>
      <description>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.</description>
    </item>
    <item>
      <title>Agente que sobrevive à queda de worker: durabilidade real combinando Temporal e Lakebase</title>
      <link>https://wiliamrosa.github.io/articles/agentes-duraveis-temporal-lakebase-postgres/</link>
      <pubDate>Wed, 09 Sep 2026 09:00:00 -0300</pubDate>
      <guid>https://wiliamrosa.github.io/articles/agentes-duraveis-temporal-lakebase-postgres/</guid>
      <description>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.</description>
    </item>
    <item>
      <title>Uma falha no PostGIS expôs todo tenant do Lakebase Postgres, e a Databricks corrigiu antes de qualquer exploração</title>
      <link>https://wiliamrosa.github.io/posts/databricks-vulnerabilidade-postgis-lakebase-postgres/</link>
      <pubDate>Wed, 02 Sep 2026 08:30:00 -0300</pubDate>
      <guid>https://wiliamrosa.github.io/posts/databricks-vulnerabilidade-postgis-lakebase-postgres/</guid>
      <description>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.</description>
    </item>
    <item>
      <title>Lakebase Postgres decide sozinho quando trocar de tamanho de máquina, usando HyperLogLog</title>
      <link>https://wiliamrosa.github.io/posts/lakebase-postgres-autoscaling-hyperloglog/</link>
      <pubDate>Tue, 01 Sep 2026 10:00:00 -0300</pubDate>
      <guid>https://wiliamrosa.github.io/posts/lakebase-postgres-autoscaling-hyperloglog/</guid>
      <description>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.</description>
    </item>
    <item>
      <title>Por que o Lakebase colocou object storage embaixo de um Postgres transacional</title>
      <link>https://wiliamrosa.github.io/posts/linkedin-lakebase-postgres-object-storage/</link>
      <pubDate>Tue, 01 Sep 2026 00:05:00 -0300</pubDate>
      <guid>https://wiliamrosa.github.io/posts/linkedin-lakebase-postgres-object-storage/</guid>
      <description>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.</description>
    </item>
    <item>
      <title>Lakebase Postgres: por que o banco transacional da era dos agentes começa pelo object storage</title>
      <link>https://wiliamrosa.github.io/posts/databricks-lakebase-postgres-arquitetura-agentes/</link>
      <pubDate>Tue, 01 Sep 2026 00:00:00 -0300</pubDate>
      <guid>https://wiliamrosa.github.io/posts/databricks-lakebase-postgres-arquitetura-agentes/</guid>
      <description>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.</description>
    </item>
    <item>
      <title>Vector Store no Databricks virou três produtos diferentes, e escolher errado sai caro</title>
      <link>https://wiliamrosa.github.io/posts/databricks-vector-store-tres-opcoes/</link>
      <pubDate>Mon, 31 Aug 2026 12:00:00 -0300</pubDate>
      <guid>https://wiliamrosa.github.io/posts/databricks-vector-store-tres-opcoes/</guid>
      <description>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.</description>
    </item>
    <item>
      <title>Lakebase ganha disaster recovery entre regiões, mas ainda deixa Delta table de fora</title>
      <link>https://wiliamrosa.github.io/posts/databricks-lakebase-disaster-recovery-preview/</link>
      <pubDate>Sat, 29 Aug 2026 09:00:00 -0300</pubDate>
      <guid>https://wiliamrosa.github.io/posts/databricks-lakebase-disaster-recovery-preview/</guid>
      <description>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.</description>
    </item>
    <item>
      <title>O DNA do Neon Postgres dentro do Lakebase: o que a separação compute/storage muda para quem provisiona banco</title>
      <link>https://wiliamrosa.github.io/posts/databricks-lakebase-neon-postgres-compute-storage/</link>
      <pubDate>Tue, 25 Aug 2026 09:00:00 -0300</pubDate>
      <guid>https://wiliamrosa.github.io/posts/databricks-lakebase-neon-postgres-compute-storage/</guid>
      <description>Na conversa com Nikita Shamgunov, VP de Engenharia da Databricks, fica mais claro de onde vem a arquitetura do Lakebase, e por que &amp;lsquo;agente provisionando banco sozinho&amp;rsquo; deixou de ser ficção científica.</description>
    </item>
    <item>
      <title>Databricks compra a Electric e leva Postgres em WASM pra dentro do sandbox de agente</title>
      <link>https://wiliamrosa.github.io/posts/databricks-adquire-electric-pglite-lakebase/</link>
      <pubDate>Wed, 12 Aug 2026 09:30:00 -0300</pubDate>
      <guid>https://wiliamrosa.github.io/posts/databricks-adquire-electric-pglite-lakebase/</guid>
      <description>A Databricks adquiriu a Electric, criadora do PGlite, um Postgres compilado para WebAssembly que roda embutido dentro de sandbox de agente, sincronizado em tempo real com o Lakebase central.</description>
    </item>
    <item>
      <title>Lakebase chega ao Azure com branch de banco pra debugar agente do GitHub Copilot</title>
      <link>https://wiliamrosa.github.io/posts/azure-databricks-lakebase-github-copilot-branching/</link>
      <pubDate>Wed, 17 Jun 2026 09:00:00 -0300</pubDate>
      <guid>https://wiliamrosa.github.io/posts/azure-databricks-lakebase-github-copilot-branching/</guid>
      <description>A combinação Lakebase + branching de banco resolve um problema bem específico: como debugar um agente em produção sem tocar nos dados reais.</description>
    </item>
    <item>
      <title>Lakebase ganhou CDC de graça, e o Postgres nem percebe</title>
      <link>https://wiliamrosa.github.io/posts/databricks-lakebase-cdf-wal2delta-unity-catalog/</link>
      <pubDate>Tue, 02 Jun 2026 09:00:00 -0300</pubDate>
      <guid>https://wiliamrosa.github.io/posts/databricks-lakebase-cdf-wal2delta-unity-catalog/</guid>
      <description>Lakebase Change Data Feed (ex-Lakehouse Sync) usa uma extensão de WAL do Postgres pra replicar toda escrita direto pra tabelas Delta no Unity Catalog, sem tocar na aplicação.</description>
    </item>
    <item>
      <title>Por que juntar SIEM e lakehouse na mesma tabela muda o cálculo de custo e velocidade em SecOps</title>
      <link>https://wiliamrosa.github.io/articles/databricks-lakehouse-nativo-ciberseguranca/</link>
      <pubDate>Wed, 01 Oct 2025 09:00:00 -0300</pubDate>
      <guid>https://wiliamrosa.github.io/articles/databricks-lakehouse-nativo-ciberseguranca/</guid>
      <description>Data Intelligence for Cybersecurity une Agent Bricks, Lakebase e o padrão aberto OCSF sobre Delta Lake pra tratar telemetria de segurança como dado de lakehouse governado, em vez de um silo isolado dentro de um SIEM proprietário caro por volume ingerido.</description>
    </item>
  </channel>
</rss>
