Arquitetura

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.

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.

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.

Databricks Apps ou Model Serving pra hospedar seu agente? A resposta depende de três coisas

Databricks Apps virou o host recomendado pra agente novo, mas Model Serving ainda vence em cenário de baixo custo e alta escala, e a diferença de timeout entre os dois muda qual opção funciona pra que tipo de agente.

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.

Omnigent: a Databricks aposta que orquestrar agentes importa mais do que escolher um só

O Omnigent propõe uma camada compartilhada para orquestrar múltiplos agentes de código sem perder contexto entre eles. Acho que essa é a pergunta certa, mas a resposta ainda depende de execução.

DeltaBus: o padrão que usa Delta Lake e Change Data Feed em vez de Kafka

Em vez de mais um cluster Kafka pra manter, o padrão DeltaBus usa tabela Delta e Change Data Feed como barramento de eventos. O Databricks MVP Dr. Alan L. Dennis destacou o argumento por trás dessa escolha de arquitetura.

Quando a chamada síncrona vira gargalo em escala de dezenas de milhões de VMs por dia

A Databricks trocou um caminho de configuração de rede baseado em chamadas síncronas a múltiplos serviços por um pipeline assíncrono orientado a eventos, separando o caminho de gerenciamento do caminho de atendimento crítico. O resultado publicado: latência p99 caindo de cerca de 5 segundos pra 125 milissegundos e disponibilidade subindo de 99,8% para 99,99%.

Quando o Unity Catalog vira coordenador de transação, não só o dicionário de tabelas

Catalog Commits tira a coordenação de transação do Delta Lake do object storage e coloca dentro do Unity Catalog, habilitando transação atômica entre várias tabelas e leitura de metadado sem round-trip pra nuvem. O recurso central já é GA desde maio de 2026, com Delta Spark, Flink, Trino e DuckDB entre os engines suportados, mas escrita de engine externo continua em Beta e tabela Iceberg gerenciada em Private Preview.

Por que juntar SIEM e lakehouse na mesma tabela muda o cálculo de custo e velocidade em SecOps

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.