I flere tiår har virksomheter opprettholdt to separate verdener for dataene sine. Online Transactional Processing (OLTP)-systemer håndterer daglig drift – ordre, lagerbeholdning, kundeoppføringer – mens Online Analytical Processing (OLAP)-systemer kjører rapporter, dashbord og trening av modeller. Å flytte data mellom dem krever ETL-pipelines, noe som fører til forsinkelser, høye kostnader og styringshodebry.

LTAP har som mål å forene disse arbeidsmengdene på én enkelt kopi av data lagret i datasjøen. Ifølge Databricks eliminerer arkitekturen ETL, replikaer og dataflytting helt fra designstadiet . Transaksjonsdata blir umiddelbart tilgjengelige for analyse, uten transformasjon eller vedlikehold av pipelines.

Selve kjernen i LTAP er Lakebase, Databricks’ serverløse Postgres-tjeneste bygget på åpen objektlagring. Lakebase betjener allerede tusenvis av kunder og håndterer 12 millioner databaseoppstarter per dag på plattformen . Under LTAP-modellen lagrer Lakebase data direkte i Unity Catalog ved hjelp av åpne formater – Delta Lake og Apache Iceberg – slik at styrt transaksjonsdata umiddelbart kan spørres mot for analytiske formål .

Selskapet beskriver flere nøkkelegenskaper for arkitekturen: enhetlig styring med én sannhetskilde, uavhengig skalering for transaksjons- og analysearbeidsmengder, full ACID-semantikk for Postgres-arbeidsmengder, og ingen skjulte pipelines eller koblinger å vedlikeholde .

Ny funksjonalitet i Lakebase

Sammen med LTAP-kunngjøringen avduket Databricks flere forbedringer av selve Lakebase:

• Katastrofegjenoppretting på tvers av skyer og regioner for produksjons-Postgres-databaser.
• Git-aktig forgrening og snapshots, som muliggjør trygg eksperimentering direkte på produksjonsdata.
• Autonome databaseoperasjoner som overvåker treghet, oppdager anomalier og utløser automatisk gjenoppretting .

Disse funksjonene signaliserer Databricks’ ambisjon om å gjøre serverløs Postgres til en fullverdig operativ database for applikasjoner og AI-agenter, og ikke bare et praktisk lag for analyse.

Lakehouse//RT: sanntidsanalyse på styrte data

Den andre store infrastrukturlanseringen var Lakehouse//RT, et sanntids-lakehouse drevet av en ny beregningsmotor kalt Reyden (en forkortelse for «Reynold's Dream Engine», oppkalt etter medgründer Reynold Xin) . Databricks hevder at Reyden leverer spørre-svartider på millisekunder for titusenvis av samtidige brukere og agenter, og kjører direkte på styrte Delta Lake- og Apache Iceberg-tabeller .

Konsekvensen er betydelig: Bedrifter trenger ikke lenger å sette opp separat serveringsinfrastruktur – som caching-lag, materialiserte views eller eksterne spørremotorer – for å oppnå sanntidsytelse. Sigma Computing ble med som lanseringspartner og kobler seg direkte til Lakehouse//RT for innebygd analyse .

Databricks-medgründer Reynold Xin beskrev lanseringen som “antakelig den største enkeltintroduksjonen vi har gjort siden lanseringen av Lakehouse” .

Satsningen på AI-agenter: Genie One, Agent Bricks og mer

Databricks brukte konferansen til å posisjonere plattformen som grunnmuren for bedriftens AI-agenter. Kunngjøringene inkluderte:

• Genie One: En AI-drevet «kollega» designet for å hjelpe forretningsteam med å automatisere arbeid basert på virksomhetens reelle data, med forbedringer for agentkontekst .
• Genie Agents og Agent Bricks: Verktøy for å bygge og distribuere AI-agenter som kan observere, resonnere og handle på tvers av bedriftsdata. Agent Bricks er forhåndsbygde komponenter som automatisk optimaliserer agenter ved hjelp av styrte data .
• Unity AI Gateway: Fler-AI-styring og kostnadskontroll for organisasjoner som håndterer flere AI-modell-leverandører .

Den overordnede fortellingen, slik bransjeanalytikere fanger den, er at LTAP og Lakehouse//RT er dataleveringslagene under en agentisk bedriftsarkitektur. Ved å plassere operative data i åpne formater på styrt lagring, mener Databricks at AI-agenter kan få tilgang til, resonnere over og handle på produksjonsdatabaser uten å flytte eller kopiere data .

Azure- og Microsoft-integrasjoner

Databricks utdypet sin integrasjon med Azure-økosystemet gjennom flere felles annonserte funksjonaliteter:

• Copilot Studio og GitHub Copilot: Brukere kan utvikle Copilot Studio-agenter som resonnerer over et helt Azure Databricks-arbeidsområde via én enkelt MCP-tilkobling (Model-Centric-Protocol) .
• Genie for Microsoft Teams og M365 Copilot (Beta): Brukere kan tagge Genie i en Teams-tråd og motta kontekstbevisste svar direkte fra sitt Azure Databricks-miljø .
• Azure Databricks Excel-tillegg (offentlig forhåndsvisning) og innebygd Excel-inntak (GA) muliggjør «førerløs» analyse fra regneark .
• Databricks CustomerLake: Den første lakehouse-nasjonale kundedataplattformen, avduket for Azure Databricks .

Disse integrasjonene antyder en strategi om å bake Databricks’ styring og AI-funksjoner inn i samarbeidsverktøyene der forretningsbeslutninger faktisk tas, i stedet for å kreve at brukerne bytter til et separat analysegrensesnitt.

Hva dette betyr for moderne dataarkitektur

Samlet utgjør kunngjøringene fra konferansen et helhetlig plattformveddemål: at neste generasjons bedriftsapplikasjoner vil være agentiske, sanntidsbaserte og styrt. LTAP fjerner skillet mellom transaksjon og analyse, Lakehouse//RT fjerner ventetiden for analytiske spørringer, og Genie-familien utgjør agent-orkestreringslaget.

Dersom dette lykkes, kan arkitekturen redusere antall bevegelige deler i en typisk bedriftsdatastakk – færre databaser, færre pipelines, færre serveringslag – samtidig som den gir AI-agenter den styrte, sanntids-konteksten de trenger for å handle autonomt på forretningsdata.

Databricks er ikke alene om å jakte på denne konvergensen, men med Lakebase på 12 millioner daglige databaseoppstarter og en konferanse med 30 000 deltakere som forsterker økosystemet, markerer LTAP-lanseringen en betydelig milepæl i lakehouse-arkitekturens utvikling fra analyseplattform til operativ data-ryggrad .

I flere tiår har virksomheter opprettholdt to separate verdener for dataene sine. Online Transactional Processing (OLTP)-systemer håndterer daglig drift – ordre, lagerbeholdning, kundeoppføringer – mens Online Analytical Processing (OLAP)-systemer kjører rapporter, dashbord og trening av modeller. Å flytte data mellom dem krever ETL-pipelines, noe som fører til forsinkelser, høye kostnader og styringshodebry.

LTAP har som mål å forene disse arbeidsmengdene på én enkelt kopi av data lagret i datasjøen. Ifølge Databricks eliminerer arkitekturen ETL, replikaer og dataflytting helt fra designstadiet . Transaksjonsdata blir umiddelbart tilgjengelige for analyse, uten transformasjon eller vedlikehold av pipelines.

Selve kjernen i LTAP er Lakebase, Databricks’ serverløse Postgres-tjeneste bygget på åpen objektlagring. Lakebase betjener allerede tusenvis av kunder og håndterer 12 millioner databaseoppstarter per dag på plattformen . Under LTAP-modellen lagrer Lakebase data direkte i Unity Catalog ved hjelp av åpne formater – Delta Lake og Apache Iceberg – slik at styrt transaksjonsdata umiddelbart kan spørres mot for analytiske formål .

Selskapet beskriver flere nøkkelegenskaper for arkitekturen: enhetlig styring med én sannhetskilde, uavhengig skalering for transaksjons- og analysearbeidsmengder, full ACID-semantikk for Postgres-arbeidsmengder, og ingen skjulte pipelines eller koblinger å vedlikeholde .

Ny funksjonalitet i Lakebase

Sammen med LTAP-kunngjøringen avduket Databricks flere forbedringer av selve Lakebase:

• Katastrofegjenoppretting på tvers av skyer og regioner for produksjons-Postgres-databaser.
• Git-aktig forgrening og snapshots, som muliggjør trygg eksperimentering direkte på produksjonsdata.
• Autonome databaseoperasjoner som overvåker treghet, oppdager anomalier og utløser automatisk gjenoppretting .

Disse funksjonene signaliserer Databricks’ ambisjon om å gjøre serverløs Postgres til en fullverdig operativ database for applikasjoner og AI-agenter, og ikke bare et praktisk lag for analyse.

Lakehouse//RT: sanntidsanalyse på styrte data

Den andre store infrastrukturlanseringen var Lakehouse//RT, et sanntids-lakehouse drevet av en ny beregningsmotor kalt Reyden (en forkortelse for «Reynold's Dream Engine», oppkalt etter medgründer Reynold Xin) . Databricks hevder at Reyden leverer spørre-svartider på millisekunder for titusenvis av samtidige brukere og agenter, og kjører direkte på styrte Delta Lake- og Apache Iceberg-tabeller .

Konsekvensen er betydelig: Bedrifter trenger ikke lenger å sette opp separat serveringsinfrastruktur – som caching-lag, materialiserte views eller eksterne spørremotorer – for å oppnå sanntidsytelse. Sigma Computing ble med som lanseringspartner og kobler seg direkte til Lakehouse//RT for innebygd analyse .

Databricks-medgründer Reynold Xin beskrev lanseringen som “antakelig den største enkeltintroduksjonen vi har gjort siden lanseringen av Lakehouse” .

Satsningen på AI-agenter: Genie One, Agent Bricks og mer

Databricks brukte konferansen til å posisjonere plattformen som grunnmuren for bedriftens AI-agenter. Kunngjøringene inkluderte:

• Genie One: En AI-drevet «kollega» designet for å hjelpe forretningsteam med å automatisere arbeid basert på virksomhetens reelle data, med forbedringer for agentkontekst .
• Genie Agents og Agent Bricks: Verktøy for å bygge og distribuere AI-agenter som kan observere, resonnere og handle på tvers av bedriftsdata. Agent Bricks er forhåndsbygde komponenter som automatisk optimaliserer agenter ved hjelp av styrte data .
• Unity AI Gateway: Fler-AI-styring og kostnadskontroll for organisasjoner som håndterer flere AI-modell-leverandører .

Den overordnede fortellingen, slik bransjeanalytikere fanger den, er at LTAP og Lakehouse//RT er dataleveringslagene under en agentisk bedriftsarkitektur. Ved å plassere operative data i åpne formater på styrt lagring, mener Databricks at AI-agenter kan få tilgang til, resonnere over og handle på produksjonsdatabaser uten å flytte eller kopiere data .

Azure- og Microsoft-integrasjoner

Databricks utdypet sin integrasjon med Azure-økosystemet gjennom flere felles annonserte funksjonaliteter:

• Copilot Studio og GitHub Copilot: Brukere kan utvikle Copilot Studio-agenter som resonnerer over et helt Azure Databricks-arbeidsområde via én enkelt MCP-tilkobling (Model-Centric-Protocol) .
• Genie for Microsoft Teams og M365 Copilot (Beta): Brukere kan tagge Genie i en Teams-tråd og motta kontekstbevisste svar direkte fra sitt Azure Databricks-miljø .
• Azure Databricks Excel-tillegg (offentlig forhåndsvisning) og innebygd Excel-inntak (GA) muliggjør «førerløs» analyse fra regneark .
• Databricks CustomerLake: Den første lakehouse-nasjonale kundedataplattformen, avduket for Azure Databricks .

Disse integrasjonene antyder en strategi om å bake Databricks’ styring og AI-funksjoner inn i samarbeidsverktøyene der forretningsbeslutninger faktisk tas, i stedet for å kreve at brukerne bytter til et separat analysegrensesnitt.

Hva dette betyr for moderne dataarkitektur

Samlet utgjør kunngjøringene fra konferansen et helhetlig plattformveddemål: at neste generasjons bedriftsapplikasjoner vil være agentiske, sanntidsbaserte og styrt. LTAP fjerner skillet mellom transaksjon og analyse, Lakehouse//RT fjerner ventetiden for analytiske spørringer, og Genie-familien utgjør agent-orkestreringslaget.

Dersom dette lykkes, kan arkitekturen redusere antall bevegelige deler i en typisk bedriftsdatastakk – færre databaser, færre pipelines, færre serveringslag – samtidig som den gir AI-agenter den styrte, sanntids-konteksten de trenger for å handle autonomt på forretningsdata.

Databricks er ikke alene om å jakte på denne konvergensen, men med Lakebase på 12 millioner daglige databaseoppstarter og en konferanse med 30 000 deltakere som forsterker økosystemet, markerer LTAP-lanseringen en betydelig milepæl i lakehouse-arkitekturens utvikling fra analyseplattform til operativ data-ryggrad .