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 term en data-architectuur zijn nu gebruikelijk in de data-industrie voor analytische workloads.
Nu probeert Databricks opnieuw een nieuwe categorie te creëren met zijn Lakebase-service, die nu algemeen beschikbaar is. Terwijl de Data Lakehouse-constructie zich bezighoudt met OLAP-databases (online analytische verwerking), draait Lakebase helemaal om OLTP (online transactieverwerking) en operationele databases. De Lakebase-service is sinds juni 2025 in ontwikkeling en is gebaseerd op Databricks-technologie die is verworven door de overname van PostgreSQL Neon-databaseprovider. Het werd in oktober 2025 verder verbeterd met de overname van Mooncake, die functionaliteit bracht om PostgreSQL te helpen verbinden met Lakehouse-gegevensformaten.
Lakebase is een operationele serverloze database die een fundamentele heroverweging vertegenwoordigt van hoe databases werken in het tijdperk van autonome AI-agenten. Early adopters, waaronder easyJet, Hafnia en Warner Music Group, verkorten de levertijden van applicaties met 75 tot 95 procent, maar diepere architecturale innovatie positioneert databases als kortstondige, zelfbedieningsinfrastructuur die AI-agenten kunnen aanbieden en beheren zonder menselijke tussenkomst.
Dit is niet zomaar een beheerde Postgres-service. Lakebase beschouwt operationele databases als lichtgewicht, wegwerpbare computerbronnen die draaien op opslagdatameren, in plaats van als monolithische systemen die een zorgvuldige capaciteitsplanning en toezicht op de databasebeheerder (DBA) vereisen.
“Echt, om de vibe-coding-trend van de grond te krijgen, heb je ontwikkelaars nodig die geloven dat ze daadwerkelijk heel snel nieuwe apps kunnen maken, maar je hebt ook het centrale IT-team, of DBA, nodig om zich op hun gemak te voelen met de tsunami aan apps en databases”, vertelde Databricks mede-oprichter Reynold Xin aan VentureBeat. “Klassieke databases kunnen dit niveau simpelweg niet bereiken omdat ze het zich niet kunnen veroorloven om een DBA per database en per app in te voeren.”
92% snellere levering: van twee maanden naar vijf dagen
Productiecijfers laten een onmiddellijke impact zien die verder gaat dan de visie van agenten. Hafnia verkortte de doorlooptijd voor productieklare applicaties van twee maanden naar vijf dagen (ofwel 92%) door Lakebase te gebruiken als transactionele motor voor het interne operationele portaal. De rederij stapte 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 bracht de ontwikkelingscycli terug van negen maanden naar vier maanden (een reductie van 56 procent), terwijl een webgebaseerde hub voor inkomstenbeheer op Lakebase werd gebouwd ter vervanging van een tien jaar oude desktop-app en een van de grootste oudere SQL Server-omgevingen in Europa.
Warner Music Group verplaatst informatie rechtstreeks naar productiesystemen met behulp van de uniforme basis, terwijl Quantum Capital Group deze gebruikt om consistente, beheerde 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 te bewaren.
De versnelling komt voort uit het elimineren van twee grote knelpunten: het klonen van databases voor testomgevingen en het onderhouden van de ETL-pijplijn voor het synchroniseren van operationele en analytische gegevens.
Technische architectuur: Omdat dit niet alleen door Postgres wordt beheerd
Traditionele databases combineren opslag en rekenkracht: Organisaties bieden één database-exemplaar met daaraan gekoppelde opslag en schaalbaarheid door meer exemplaren of opslag toe te voegen. AWS Aurora innoveerde door deze lagen te scheiden met behulp van eigen opslag, maar de opslag bleef vergrendeld binnen het AWS-ecosysteem en was niet onafhankelijk toegankelijk voor analyses.
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, waardoor volledige compatibiliteit met het Postgres-ecosysteem behouden blijft, maar elke schrijfbewerking wordt naar Lakehouse-opslag gestuurd in formaten die Spark, Databricks SQL en andere analyse-engines onmiddellijk kunnen opvragen zonder ETL.
“Het unieke technische inzicht was dat datameren opslag scheiden van rekenkracht, wat geweldig is, maar we moeten databeheermogelijkheden zoals governance en transactiebeheer in het datameer introduceren”, legt Xin uit. “Eigenlijk verschillen we niet zoveel van het Lakehouse-concept, maar we bouwen voort op lichtgewicht, kortstondige berekeningen voor OLTP-databases.”
Databricks heeft Lakebase gebouwd met technologie die is verkregen uit de overname van Neon. Maar Xin wees erop dat Databricks de oorspronkelijke mogelijkheden van Neon aanzienlijk heeft uitgebreid om iets fundamenteel anders te creëren.
“Ze hadden niet de ervaring op ondernemingsniveau en niet de schaalbaarheid van de cloud”, aldus Xin. “We hebben het nieuwe architecturale idee van het Neon-team gecombineerd met de robuustheid van de Databricks-infrastructuur en deze gecombineerd. Nu hebben we een superschaalbaar platform gecreëerd.”
Van honderden databases tot miljoenen databases gemaakt voor agent AI
Xin schetste een visie die rechtstreeks verband houdt met de economie van AI-coderingstools en die verklaart waarom Lakebase problemen opbouwt die verder gaan dan de huidige gebruiksscenario’s. Naarmate de ontwikkelingskosten dalen, zullen bedrijven overstappen van de aanschaf van honderden SaaS-applicaties naar het bouwen van miljoenen op maat gemaakte interne applicaties.
“Naarmate de kosten van softwareontwikkeling dalen, zoals we vandaag de dag zien dankzij AI-coderingstools, zullen we overgaan van de proliferatie van SaaS in de afgelopen tien tot vijftien jaar naar de proliferatie van interne applicatieontwikkeling”, aldus Xin. “In plaats van misschien wel honderden applicaties te bouwen, zullen ze in de loop van de tijd miljoenen op maat gemaakte apps maken.”
Dit creëert een vlootbeheerprobleem dat onmogelijk is met traditionele benaderingen. 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 dataprobleem in plaats van als een operationeel probleem.
Lakebase slaat alle telemetrie en metadata (queryprestaties, resourcegebruik, verbindingspatronen, foutpercentages) rechtstreeks op in Lakehouse, waar deze kunnen worden geanalyseerd met behulp van standaard data-engineering en data science-tools. In plaats van dashboards op te zetten 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 elke 50 of 100 databases een dashboard te maken, kun je daadwerkelijk naar de grafiek kijken om te zien of er iets mis is gegaan”, 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. Een AI-agent die prestatieproblemen ondervindt, kan telemetriegegevens opvragen om problemen te diagnosticeren, waarbij databasebewerkingen als een eenvoudige analysetaak 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
Het Lakebase-construct signaleert een fundamentele verschuiving in de manier waarop bedrijven moeten denken over operationele databases: niet als waardevolle, zorgvuldig beheerde infrastructuur waarvoor gespecialiseerde DBA’s nodig zijn, maar als programmatisch schaalbare, self-service, kortstondige bronnen zoals cloud computing.
Het maakt niet uit of autonome agents zo snel tot stand komen als Databricks voorspelt, 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 in de sector. Wanneer schrijfbewerkingen naar een operationele database onmiddellijk kunnen worden opgevraagd door analyse-engines zonder ETL, vervagen de traditionele grenzen tussen transactionele systemen en datawarehouses. Deze uniforme architectuur vermindert de operationele overhead die gepaard gaat met het onderhouden van afzonderlijke systemen, maar vereist ook een heroverweging van de datateamstructuren die rond deze grenzen zijn opgebouwd.
Toen Lakehouse werd gelanceerd, verwierpen concurrenten het concept voordat ze het zelf adopteerden. Xin verwacht hetzelfde traject voor Lakebase.
“Het is gewoon logisch om de opslag en de rekenkracht te scheiden en alle opslag in het meer te plaatsen – het biedt zoveel mogelijkheden en mogelijkheden”, zei hij.
