Vijf jaar geleden bedacht Databricks de term ‘data lakehouse’ om een nieuw type data-architectuur te beschrijven dat een datameer combineert met een datawarehouse. Deze termen en data-architecturen zijn nu gemeengoed in de data-industrie voor analytische workloads.
Nu wil Databricks opnieuw een nieuwe categorie creëren met zijn Lakebase-service, die nu algemeen beschikbaar is. Terwijl de constructie van data lakehouses zich bezighoudt met OLAP-databases (online analytische verwerking), gaat Lakebase over OLTP (online transactieverwerking) en operationele databases. De Lakebase-service is sinds juni 2025 in ontwikkeling en is gebaseerd op technologie die Databricks heeft verworven via de overname van PostgreSQL Neon-databaseprovider. Dit zal in oktober 2025 verder worden verbeterd met maancake acquisitie, wat mogelijkheden biedt om PostgreSQL te helpen overbruggen met data lakehouse-formaten.
Lakebase is een serverloze operationele database die een fundamentele heroverweging vertegenwoordigt van de manier waarop databases werken in het tijdperk van autonome AI-agenten. Early adopters, waaronder easyJet, Hafnia en Warner Music Group, hebben de levertijden van applicaties met 75 tot 95% teruggebracht, maar diepere architectonische innovaties positioneren de database als een tijdelijke, zelfbedieningsinfrastructuur die zonder menselijke tussenkomst door AI-agenten kan worden ingericht en beheerd.
Het is niet alleen een beheerde Postgres-service. Lakebase beschouwt operationele databases als lichtgewicht, wegwerpcomputers die draaien op dataopslag uit het meer, in plaats van monolithische systemen die een zorgvuldige capaciteitsplanning en toezicht op de databasebeheerder (DBA) vereisen.
“Echt, om de vibe-coding-trend een vlucht te laten nemen, heb je ontwikkelaars nodig die geloven dat ze daadwerkelijk heel snel nieuwe applicaties kunnen bouwen, maar je hebt ook het centrale IT-team, of DBA, nodig om op hun gemak te zijn met het enorme aantal applicaties en databases,” vertelde Databricks mede-oprichter Reynold Xin aan VentureBeat. “Klassieke databases konden die schaal niet bereiken omdat ze het zich niet konden veroorloven om een DBA per database en per applicatie in te voeren.”
92% snellere levering: van twee maanden tot vijf dagen
De productiecijfers laten een directe impact zien die verder gaat dan de aanbodvisie van de agent. Hafnia heeft de levertijd van productieklare applicaties teruggebracht van twee maanden naar vijf dagen – of 92% – door Lakebase te gebruiken als transactionele motor voor hun interne operationele portaal. Rederijen stappen over van statische BI-rapporten naar realtime bedrijfsapplicaties voor vloot-, commerciële en financiële workflows.
EasyJet consolideerde meer dan 100 Git-repository’s in slechts twee en verkortte de ontwikkelingscyclus van negen maanden naar vier maanden – een reductie van 56% – terwijl een webgebaseerd inkomstenbeheercentrum op Lakebase werd gebouwd ter vervanging van een tien jaar oude desktopapplicatie en een van de grootste oudere SQL Server-omgevingen in Europa.
Warner Music Group verplaatst inzichten rechtstreeks naar productiesystemen met behulp van een uniforme basis, terwijl Quantum Capital Group deze gebruikt om consistente en georganiseerde gegevens bij te houden om olie- en gasinvesteringen te identificeren en te evalueren, waardoor gegevensduplicatie wordt geëlimineerd die teams voorheen dwong meerdere kopieën in verschillende formaten op te slaan.
Deze versnelling is te danken aan het elimineren van twee belangrijke knelpunten: het klonen van databases voor testomgevingen en het onderhouden van ETL-pijplijnen voor operationele en analytische gegevenssynchronisatie.
Technische architectuur: waarom het niet alleen door Postgres wordt beheerd
Traditionele databases combineren opslag en computergebruik. Organisaties bieden database-instances aan met ingebouwde opslag en schalen deze door meer instances of opslag toe te voegen. AWS Aurora innoveert door deze lagen te scheiden met behulp van eigen opslag, maar die opslag blijft vergrendeld binnen het AWS-ecosysteem en kan niet onafhankelijk worden benaderd voor analyse.
Lakebase brengt de scheiding van opslag en rekenkracht tot een logische conclusie door opslag rechtstreeks in het data lakehouse te plaatsen. De rekenlaag draait in wezen PostgreSQL, waarbij de volledige compatibiliteit met het Postgres-ecosysteem behouden blijft, maar elke schrijfbewerking gaat naar Lakehouse-opslag in een indeling die rechtstreeks kan worden opgevraagd door Spark, Databricks SQL en andere analyse-engines zonder ETL.
“Het unieke technische inzicht is dat datameren opslag loskoppelen van rekenkracht, en dat is iets geweldigs, maar we moeten datamanagementmogelijkheden zoals governance en transactiebeheer in datameren introduceren”, legt Xin uit. “We verschillen eigenlijk niet veel van het lakehouse-concept, maar we bouwen lichte en korte rekenkracht voor OLTP-databases.”
Databricks heeft Lakebase gebouwd met technologie die is verkregen uit de overname van Neon. Maar Xin benadrukte dat Databricks de oorspronkelijke mogelijkheden van Neon aanzienlijk heeft uitgebreid om iets fundamenteel anders te creëren.
“Ze hebben geen ervaring op ondernemingsniveau, en ze hebben geen cloudschaal”, zei Xin. “We hebben de nieuwe architectonische ideeën van het Neon-team gecombineerd met de robuustheid van de infrastructuur van Databricks en deze gecombineerd. Nu hebben we een zeer schaalbaar platform gecreëerd.”
Van honderden databases tot miljoenen databases gemaakt voor AI-agenten
Xin schetst een visie die rechtstreeks verband houdt met de economie van AI-coderingstools en die verklaart waarom de Lakebase-constructie belangrijker is dan de huidige gebruiksscenario’s. Naarmate de ontwikkelingskosten dalen, zullen bedrijven overstappen van het kopen van honderden SaaS-applicaties naar het bouwen van miljoenen op maat gemaakte interne applicaties.
“Naarmate de kosten voor softwareontwikkeling dalen, wat we vandaag de dag zien dankzij AI-coderingstools, zal dit verschuiven van de proliferatie van SaaS in de afgelopen tien tot vijftien jaar naar de proliferatie van interne applicatieontwikkeling”, aldus Xin. “In plaats van honderden apps te bouwen, zullen ze in de loop van de tijd miljoenen op maat gemaakte apps bouwen.”
Dit creëert problemen op het gebied van wagenparkbeheer die met traditionele benaderingen onmogelijk zouden zijn. U kunt niet genoeg DBA’s inhuren om duizenden databases handmatig in te richten, te monitoren en problemen op te lossen. De oplossing van Xin: behandel databasebeheer zelf als een gegevensprobleem en niet als een operationeel probleem.
Lakebase slaat alle telemetrie en metagegevens (queryprestaties, resourcegebruik, verbindingspatronen, foutpercentages) rechtstreeks op in het Lakehouse, waar deze kunnen worden geanalyseerd met behulp van standaard tools voor data-engineering en datawetenschap. In plaats van dashboards te configureren in databasespecifieke monitoringtools, kunnen datateams telemetriegegevens opvragen met SQL of deze analyseren met machine learning-modellen om uitschieters te identificeren en problemen te voorspellen.
“In plaats van een dashboard te maken voor elke 50 of 100 databases, kun je daadwerkelijk naar grafieken kijken om te begrijpen of er iets misgaat”, legt Xin uit. “Databasebeheer gaat veel op een analytisch probleem lijken. Je kijkt naar uitschieters, je kijkt naar trends, je probeert te begrijpen waarom dingen gebeuren. Zo beheer je op schaal wanneer agenten databases programmatisch creëren en vernietigen.”
De implicaties strekken zich uit tot de autonome agenten zelf. AI-agenten die prestatieproblemen ervaren, kunnen telemetriegegevens opvragen om het probleem te diagnosticeren, waarbij databasebewerkingen eenvoudigweg als een analytische taak worden beschouwd in plaats van dat er gespecialiseerde DBA-kennis voor nodig is. Databasebeheer wordt iets dat agenten zelf kunnen doen met dezelfde mogelijkheden voor gegevensanalyse die ze al hebben.
Wat dit betekent voor bedrijfsdatateams
De constructie van Lakebase signaleert een fundamentele verschuiving in de manier waarop bedrijven over operationele databases denken – niet als waardevolle, zorgvuldig beheerde infrastructuur die een speciale DBA vereist, maar als een selfservice-bron die kortstondig en programmatisch schaalbaar is, zoals cloud computing.
Het zal van belang zijn of autonome agenten zo snel werkelijkheid worden als Databricks voor ogen heeft, omdat het onderliggende architecturale principe – het behandelen van databasebeheer als een analytisch probleem in plaats van een operationeel probleem – de vaardigheden en teamstructuren verandert die bedrijven nodig hebben.
Dataleiders moeten aandacht besteden aan de convergentie van operationele en analytische gegevens die in verschillende sectoren voorkomen. Wanneer schrijfbewerkingen naar operationele databases rechtstreeks kunnen worden opgevraagd door analytische machines zonder ETL, vervagen de traditionele grenzen tussen transactionele systemen en datawarehouses. Deze uniforme architectuur verlaagt de operationele kosten van het onderhouden van afzonderlijke systemen, maar vereist ook een heroverweging van de datateamstructuren die rond deze beperkingen zijn opgebouwd.
Toen het Lakehouse werd gelanceerd, verwierpen de concurrenten het concept voordat ze het uiteindelijk zelf overnamen. Xin voorspelt dat hetzelfde zal gebeuren met Lakebase.
“Het is zinvol om opslag en rekenkracht te scheiden en alle opslag in het meer te plaatsen – het maakt zoveel mogelijkheden en mogelijkheden mogelijk”, zei hij.
