Vijf jaar geleden bedacht Databricks de term ‘data lakehouse’ om een nieuw type data-architectuur te beschrijven dat een datameer combineert met een datawarehouse. Die term en data-architectuur 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 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 technologie die Databricks heeft verworven via de overname van PostgreSQL-databaseprovider Neon. Het werd in oktober 2025 verder verbeterd met de overname van Mooncake, wat mogelijkheden bood om PostgreSQL te helpen een brug te slaan met lakehouse-gegevensformaten.
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, verkorten de levertijden van applicaties met 75 tot 95%, maar de 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 rekenkracht die draait op data lake-opslag in plaats van 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’s, nodig om op hun gemak te zijn met de tsunami aan apps en databases”, vertelde Databricks mede-oprichter Reynold Xin aan VentureBeat. “Klassieke databases kunnen daar simpelweg niet op schalen, omdat ze het zich niet kunnen veroorloven om een DBA per database en per app in te voeren.”
92% snellere levering: van twee maanden tot vijf dagen
De productiecijfers laten een onmiddellijke impact zien die verder gaat dan de visie op het bevoorraden van agenten. Hafnia verkortte de levertijd voor productieklare applicaties van twee maanden naar vijf dagen – of 92% – door Lakebase te gebruiken als transactionele motor voor hun interne operationele portal. 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 naar vier maanden – een reductie van 56% – en bouwde tegelijkertijd een webgebaseerde hub voor inkomstenbeheer op Lakebase ter vervanging van een tien jaar oude desktop-app en een van Europa’s grootste oudere SQL Server-omgevingen.
Warner Music Group verplaatst inzichten rechtstreeks naar productiesystemen met behulp van de uniforme basis, terwijl Quantum Capital Group deze gebruikt om consistente, beheerde gegevens bij te houden voor het identificeren en evalueren van olie- en gasinvesteringen – waardoor de gegevensduplicatie wordt geëlimineerd die teams voorheen dwong meerdere kopieën in verschillende formaten bij te houden.
De versnelling komt voort uit het elimineren van twee grote knelpunten: het klonen van databases voor testomgevingen en het onderhoud van ETL-pijplijnen voor het synchroniseren van operationele en analytische gegevens.
Technische architectuur: waarom dit niet alleen door Postgres wordt beheerd
Traditionele databases koppelen opslag en rekenkracht: organisaties voorzien een database-instance van gekoppelde opslag en schaalbaarheid door meer instances of opslag toe te voegen. AWS Aurora innoveerde door deze lagen te scheiden met behulp van eigen opslag, maar de opslag bleef opgesloten in het ecosysteem van AWS en was niet onafhankelijk toegankelijk 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 essentie standaard PostgreSQL, waardoor volledige compatibiliteit met het Postgres-ecosysteem behouden blijft, maar elke schrijfbewerking gaat naar lakehouse-opslag in formaten die Spark, Databricks SQL en andere analyse-engines onmiddellijk kunnen opvragen zonder ETL.
“Het unieke technische inzicht was dat datameren opslag loskoppelen van rekenkracht, wat geweldig was, maar we moeten databeheermogelijkheden zoals governance en transactiebeheer in het datameer introduceren”, legt Xin uit. “We verschillen eigenlijk niet zoveel van het Lakehouse-concept, maar we bouwen er lichtgewicht, kortstondige rekenkracht voor OLTP-databases bovenop.”
Databricks heeft Lakebase gebouwd met de technologie die het heeft verkregen door 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 hadden niet de enterprise-ervaring, en ze hadden niet de cloudschaal”, zei Xin. “We hebben het nieuwe architecturale idee van het Neon-team samengebracht met de robuustheid van de Databricks-infrastructuur en deze gecombineerd. Dus nu hebben we een superschaalbaar platform gecreëerd.”
Van honderden databases tot miljoenen die zijn gebouwd voor agent-AI
Xin schetste een visie die rechtstreeks verband houdt met de economie van AI-coderingstools en die verklaart waarom de Lakebase-constructie van belang is buiten de huidige gebruiksscenario’s. Nu 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 van softwareontwikkeling dalen, wat we vandaag de dag zien als gevolg van AI-coderingstools, zal deze verschuiven van de proliferatie van SaaS in de afgelopen tien tot vijftien jaar naar de proliferatie van interne applicatieontwikkeling”, aldus Xin. “In plaats van misschien honderden applicaties te bouwen, zullen ze in de loop van de tijd miljoenen op maat gemaakte apps bouwen.”
Dit creëert een onmogelijk wagenparkbeheerprobleem 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 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 de grafiek kijken om te zien of er iets mis is gegaan”, legt Xin uit. “Databasebeheer lijkt erg op een analyseprobleem. 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, zou de telemetriegegevens kunnen opvragen om problemen te diagnosticeren, waarbij databasebewerkingen als een zoveelste 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 duidt op 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 kortstondige, zelfbedieningsbronnen die programmatisch kunnen worden geschaald zoals cloud computing.
Het maakt niet uit of autonome agents zo snel tot stand komen 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 in de hele 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 uiteindelijk zelf adopteerden. Xin verwacht hetzelfde traject voor Lakebase.
“Het is gewoon logisch om opslag en rekenkracht te scheiden en alle opslag in het meer te plaatsen – het maakt zoveel mogelijkheden en mogelijkheden mogelijk”, zei hij.
