I årtier har organisationer opretholdt to separate verdener for deres data. Online transaktionssystemer (OLTP) håndterer den daglige drift – ordrer, lageropdateringer, kundekartoteker – mens online analysesystemer (OLAP) står for rapportering, dashboards og modeltræning. At flytte data mellem dem kræver ETL-pipelines, som introducerer latenstid, omkostninger og hovedbrud omkring datagovernance.

LTAP sigter mod at forene disse arbejdsbyrder på én enkelt kopi af data, der ligger i data lake'en. Ifølge Databricks eliminerer arkitekturen designmæssigt ETL, replikaer og dataflytning . Transaktionsdata bliver øjeblikkeligt tilgængelige for analyse uden transformation eller vedligeholdelse af pipelines.

Fundamentet for LTAP er Lakebase, Databricks' serverløse Postgres-tjeneste bygget på åben objektlagring. Lakebase betjener allerede tusindvis af kunder og håndterer 12 millioner databaselaunches om dagen på tværs af platformen . Under LTAP-modellen gemmer Lakebase data direkte i Unity Catalog i åbne formater – Delta Lake og Apache Iceberg – således at styrede transaktionsdata øjeblikkeligt kan forespørges til analytiske formål .

Virksomheden beskriver flere centrale egenskaber for arkitekturen: samlet governance med én kilde til sandhed, uafhængig skalering af transaktions- og analyseworkloads, fulde ACID-semantikker for Postgres-workloads og ingen skjulte pipelines eller konnektorer at vedligeholde .

Nye funktioner i Lakebase

Sideløbende med LTAP-udmeldingen afslørede Databricks flere forbedringer til selve Lakebase:

• Disaster recovery på tværs af cloud og regioner til produktions-Postgres-databaser.
• Forgrening og snapshots i Git-stil, hvilket muliggør sikker eksperimentering direkte på produktionsdata.
• Autonom database-drift, der overvåger for nedbremsninger, opdager anomalier og udløser automatisk recovery .

Disse funktioner signalerer Databricks' intention om at gøre serverløs Postgres til en førsteklasses operationel database for applikationer og AI-agenter – og ikke bare et bekvemmelighedslag til analyse.

Lakehouse//RT: real-time analyse på styrede data

Den anden store infrastrukturmeddelelse var Lakehouse//RT, et real-time lakehouse drevet af en ny beregningsmotor kaldet Reyden (en forkortelse for “Reynold’s Dream Engine,” opkaldt efter medstifter Reynold Xin) . Databricks siger, at Reyden leverer millisekund-forespørgselstider med titusindvis af samtidige brugere og agenter, der kører direkte på styrede Delta Lake- og Apache Iceberg-tabeller .

Implikationen er markant: virksomheder behøver ikke længere at opsætte separat serveringsinfrastruktur – som cachinglag, materialiserede views eller eksterne forespørgselsmotorer – for at opnå real-time performance. Sigma Computing kom med som lanceringspartner og forbinder sig direkte til Lakehouse//RT til indlejret analyse .

Databricks' medstifter Reynold Xin beskrev lanceringen som “sandsynligvis den største enkeltstående introduktion, vi har lavet siden lanceringen af Lakehouse” .

Det agentiske fremstød: Genie One, Agent Bricks og bredere AI-værktøjer

Databricks brugte topmødet til at positionere sin platform som fundamentet for virksomheders AI-agenter. Meddelelserne omfattede:

• Genie One: En AI-agentisk medarbejder designet til at hjælpe forretningsteams med at automatisere arbejde funderet i reelle forretningsdata, med forbedringer til agentisk kontekst .
• Genie Agents og Agent Bricks: Værktøjer til at bygge og implementere AI-agenter, der kan observere, ræsonnere og handle på tværs af virksomhedens data. Agent Bricks er præbyggede komponenter, der auto-optimerer agenter ved brug af styrede data .
• Unity AI Gateway: Multi-AI-governance og omkostningsstyring for organisationer, der håndterer flere AI-modeludbydere .

Den bredere fortælling, som brancheanalytikere har opsnappet, er, at LTAP og Lakehouse//RT er de dataleverende lag under en agentisk virksomhedsarkitektur. Ved at placere operationelle data i åbne formater på styret lagring, tror Databricks på, at AI-agenter kan tilgå, ræsonnere over og handle på produktionsdatabaser uden at flytte eller kopiere data .

Integrationer med Azure og Microsofts økosystem

Databricks uddybede sin integration i Azure-økosystemet med flere fælles annoncerede kapabiliteter:

• Copilot Studio og GitHub Copilot: Brugere kan forfatte Copilot Studio-agenter, der ræsonnerer over et helt Azure Databricks-arbejdsområde via en enkelt MCP-forbindelse (Model-Centric-Protocol) .
• Genie til Microsoft Teams og M365 Copilot (Beta): Brugere kan tagge Genie i en Teams-tråd og modtage kontekstbevidste svar direkte fra deres Azure Databricks-miljø .
• Azure Databricks Excel Add-in (Public Preview) og native Excel-indtagelse (GA) muliggør førerløs analyse fra regneark .
• Databricks CustomerLake: Den første lakehouse-native kundedataplatform, præsenteret til Azure Databricks .

Disse integrationer antyder en strategi om at indlejre Databricks' governance- og AI-kapaciteter i de samarbejdsværktøjer, hvor forretningsbeslutninger træffes, i stedet for at kræve, at brugerne skifter til en separat analyseflade.

Hvad det betyder for virksomheders dataarkitektur

Samlet set repræsenterer topmødeudmeldingerne et sammenhængende platformsvæddemål: At den næste generation af virksomhedsapplikationer vil være agentiske, køre i realtid og være fuldt ud styrede. LTAP fjerner den transaktionelle/analytiske kløft, Lakehouse//RT fjerner latenstidskompromiset for analytiske forespørgsler, og Genie-familien leverer agent-orkestreringslaget.

Hvis det lykkes, kan denne arkitektur reducere antallet af bevægelige dele i en typisk virksomheds datastak – færre databaser, færre pipelines, færre serveringslag – samtidig med at den giver AI-agenter den styrede, real-time kontekst, de har brug for til at handle autonomt på forretningsdata.

Databricks er ikke alene om at forfølge denne konvergens, men med Lakebase, der allerede håndterer 12 millioner daglige databaselaunches, og et topmøde med 30.000 deltagere, der styrker økosystemet, markerer LTAP-udmeldingen en væsentlig milepæl i lakehouse-arkitekturens udvikling fra en analyseplatform til en operationel datarygrad .

I årtier har organisationer opretholdt to separate verdener for deres data. Online transaktionssystemer (OLTP) håndterer den daglige drift – ordrer, lageropdateringer, kundekartoteker – mens online analysesystemer (OLAP) står for rapportering, dashboards og modeltræning. At flytte data mellem dem kræver ETL-pipelines, som introducerer latenstid, omkostninger og hovedbrud omkring datagovernance.

LTAP sigter mod at forene disse arbejdsbyrder på én enkelt kopi af data, der ligger i data lake'en. Ifølge Databricks eliminerer arkitekturen designmæssigt ETL, replikaer og dataflytning . Transaktionsdata bliver øjeblikkeligt tilgængelige for analyse uden transformation eller vedligeholdelse af pipelines.

Fundamentet for LTAP er Lakebase, Databricks' serverløse Postgres-tjeneste bygget på åben objektlagring. Lakebase betjener allerede tusindvis af kunder og håndterer 12 millioner databaselaunches om dagen på tværs af platformen . Under LTAP-modellen gemmer Lakebase data direkte i Unity Catalog i åbne formater – Delta Lake og Apache Iceberg – således at styrede transaktionsdata øjeblikkeligt kan forespørges til analytiske formål .

Virksomheden beskriver flere centrale egenskaber for arkitekturen: samlet governance med én kilde til sandhed, uafhængig skalering af transaktions- og analyseworkloads, fulde ACID-semantikker for Postgres-workloads og ingen skjulte pipelines eller konnektorer at vedligeholde .

Nye funktioner i Lakebase

Sideløbende med LTAP-udmeldingen afslørede Databricks flere forbedringer til selve Lakebase:

• Disaster recovery på tværs af cloud og regioner til produktions-Postgres-databaser.
• Forgrening og snapshots i Git-stil, hvilket muliggør sikker eksperimentering direkte på produktionsdata.
• Autonom database-drift, der overvåger for nedbremsninger, opdager anomalier og udløser automatisk recovery .

Disse funktioner signalerer Databricks' intention om at gøre serverløs Postgres til en førsteklasses operationel database for applikationer og AI-agenter – og ikke bare et bekvemmelighedslag til analyse.

Lakehouse//RT: real-time analyse på styrede data

Den anden store infrastrukturmeddelelse var Lakehouse//RT, et real-time lakehouse drevet af en ny beregningsmotor kaldet Reyden (en forkortelse for “Reynold’s Dream Engine,” opkaldt efter medstifter Reynold Xin) . Databricks siger, at Reyden leverer millisekund-forespørgselstider med titusindvis af samtidige brugere og agenter, der kører direkte på styrede Delta Lake- og Apache Iceberg-tabeller .

Implikationen er markant: virksomheder behøver ikke længere at opsætte separat serveringsinfrastruktur – som cachinglag, materialiserede views eller eksterne forespørgselsmotorer – for at opnå real-time performance. Sigma Computing kom med som lanceringspartner og forbinder sig direkte til Lakehouse//RT til indlejret analyse .

Databricks' medstifter Reynold Xin beskrev lanceringen som “sandsynligvis den største enkeltstående introduktion, vi har lavet siden lanceringen af Lakehouse” .

Det agentiske fremstød: Genie One, Agent Bricks og bredere AI-værktøjer

Databricks brugte topmødet til at positionere sin platform som fundamentet for virksomheders AI-agenter. Meddelelserne omfattede:

• Genie One: En AI-agentisk medarbejder designet til at hjælpe forretningsteams med at automatisere arbejde funderet i reelle forretningsdata, med forbedringer til agentisk kontekst .
• Genie Agents og Agent Bricks: Værktøjer til at bygge og implementere AI-agenter, der kan observere, ræsonnere og handle på tværs af virksomhedens data. Agent Bricks er præbyggede komponenter, der auto-optimerer agenter ved brug af styrede data .
• Unity AI Gateway: Multi-AI-governance og omkostningsstyring for organisationer, der håndterer flere AI-modeludbydere .

Den bredere fortælling, som brancheanalytikere har opsnappet, er, at LTAP og Lakehouse//RT er de dataleverende lag under en agentisk virksomhedsarkitektur. Ved at placere operationelle data i åbne formater på styret lagring, tror Databricks på, at AI-agenter kan tilgå, ræsonnere over og handle på produktionsdatabaser uden at flytte eller kopiere data .

Integrationer med Azure og Microsofts økosystem

Databricks uddybede sin integration i Azure-økosystemet med flere fælles annoncerede kapabiliteter:

• Copilot Studio og GitHub Copilot: Brugere kan forfatte Copilot Studio-agenter, der ræsonnerer over et helt Azure Databricks-arbejdsområde via en enkelt MCP-forbindelse (Model-Centric-Protocol) .
• Genie til Microsoft Teams og M365 Copilot (Beta): Brugere kan tagge Genie i en Teams-tråd og modtage kontekstbevidste svar direkte fra deres Azure Databricks-miljø .
• Azure Databricks Excel Add-in (Public Preview) og native Excel-indtagelse (GA) muliggør førerløs analyse fra regneark .
• Databricks CustomerLake: Den første lakehouse-native kundedataplatform, præsenteret til Azure Databricks .

Disse integrationer antyder en strategi om at indlejre Databricks' governance- og AI-kapaciteter i de samarbejdsværktøjer, hvor forretningsbeslutninger træffes, i stedet for at kræve, at brugerne skifter til en separat analyseflade.

Hvad det betyder for virksomheders dataarkitektur

Samlet set repræsenterer topmødeudmeldingerne et sammenhængende platformsvæddemål: At den næste generation af virksomhedsapplikationer vil være agentiske, køre i realtid og være fuldt ud styrede. LTAP fjerner den transaktionelle/analytiske kløft, Lakehouse//RT fjerner latenstidskompromiset for analytiske forespørgsler, og Genie-familien leverer agent-orkestreringslaget.

Hvis det lykkes, kan denne arkitektur reducere antallet af bevægelige dele i en typisk virksomheds datastak – færre databaser, færre pipelines, færre serveringslag – samtidig med at den giver AI-agenter den styrede, real-time kontekst, de har brug for til at handle autonomt på forretningsdata.

Databricks er ikke alene om at forfølge denne konvergens, men med Lakebase, der allerede håndterer 12 millioner daglige databaselaunches, og et topmøde med 30.000 deltagere, der styrker økosystemet, markerer LTAP-udmeldingen en væsentlig milepæl i lakehouse-arkitekturens udvikling fra en analyseplatform til en operationel datarygrad .