--- type: WebPage title: Untitled description: "" resource: https://www.vldb.org/pvldb/vol19/p4385-pandis.pdf tags: [] timestamp: 2026-09-10T22:59:25.440171Z --- Lakebase: Serverless Postgres over Open Lake Storage JasrajDange,AndreiDragus,AliGhodsi,HaoyuHuang,YiheHuang,StasKelvich,Heikki Linnakangas,HansNorheim,IppokratisPandis,NikitaShamgunov,EmSharnoff,JohnSpray,Zhou Sun,ReynoldXin,MateiZaharia lakebase@databricks.com Databricks ABSTRACT 1 INTRODUCTION ModerncloudapplicationsandAI-drivenworkloadsdemandelastic Transactionaldatabasesformtheoperationalcoreofmodernsoft- compute,instantenvironmentisolation,andopendatainteroper- waresystems.Everyapplication—whetherconsumer-facingser- ability.However,productiondatabasesremainlargelybasedon vices,enterprisesystems,financialinfrastructure,orAI-drivenplat- monolithicarchitecturesdesignedinthe1980s,tightlycoupling forms—ultimatelyreliesonatransactionaldatabasetopersiststate storage and compute and creating operational fragility, cost in- andenforcecorrectness.Despitetheradicalevolutionofapplication efficiencies,andvendorlock-in.ThispaperpresentsLakebase,a architecturesoverthepastfourdecades,productiondatabasesys- newopendatabasearchitecturethatdecouplestransactionalcom- temsremainlargelyrootedindesignassumptionsfromthe1980s. putefromstoragewhileplacingdatabasedatadirectlyinlow-cost Thesesystemswerebuiltforanerainwhichstoragewasscarce, cloudobjectstoresinopenformat.Unlikesecond-generationcloud networks were slow, and cloud elasticity did not exist. As a re- databases,suchasAmazonAurora,MicrosoftSocratesandGoogle sult,thearchitectureofmostdeployeddatabasesisincreasingly AlloyDB,whichseparatestorageinternallybutretainproprietary misalignedwithmoderninfrastructureanddevelopmentpractices. formatsandsingle-engineaccess,Lakebaseexposesstorageasan Thismisalignmentmanifestsinthreepersistentchallenges.First, open, durable lake layer while running elastic, serverless Post- tightlycouplingcomputeandstoragewithinasingleprovisioned greSQLtransactionalenginesindependentlyontop.Wedescribethe unitcreatesoperationalfragilityandeconomicinefficiency.Ca- systemdesignprinciplesbehindLakebase,includingopen-format pacitymustbeprovisionedforpeakdemand,leavingexpensive object storage persistence, compute elasticity down to zero, in- resourcesidleduringnormaloperation.Whenloadexceedsprovi- stantbranchingandcloningviacopy-on-writesemantics,anduni- sionedcapacity,performancedegradesabruptly.Routinetaskssuch fied transactional-analytical access over shared lake storage, as assnapshotting,backfills,orcompliance-relatedcleanupqueries deployedintheDatabricksLakebaseservice.Weanalyzehowthis competedirectlywithproductiontrafficandcanthreatenavail- architecturereducesoperationalcomplexity,enablesGit-likedata- ability.Inshort,themonolithicdatabaseremainsoneofthemost baseworkflows,improvesfailurerecoverysemantics,andmitigates delicatecomponentsinmoderninfrastructure. structuralvendorlock-in.Wefurtherdiscussproductiondeploy- Second,traditionaldatabasesarepoorlyalignedwithcontem- mentcharacteristics,performancetrade-offs,durabilityguarantees, porarydevelopmentworkflows.Modernsoftwareengineeringis andsupportformulticloudhighavailability.WeevaluateLakebase builtaroundrapiditerationandisolation.Versioncontrolsystems onstandardOLTPandanalyticalbenchmarks,alongsideproduc- allowdeveloperstobranchentirecodebasesinstantaneously.How- tiontelemetryonbranchingandelasticity.Lakebaserepresentsa ever,provisioningarealisticdatabaseenvironmentoftenrequires thirdgenerationofdatabasearchitecture:transactionalsystems minutesorhoursandsubstantialoperationaloverhead.Asdevel- rebuiltnativelyforcloudobjectstorage,elasticcompute,andAI-era opmentvelocityaccelerates,thedatabaseincreasinglybecomesthe developmentworkflows. bottleneckratherthantheenabler. Third,existingarchitecturesimposestructuralvendorlock-in. Storageformatsaretightlycoupledtoasingleexecutionengine, anddataisaccessibleonlythroughthatengine.Migrationsare PVLDBReferenceFormat: costlyandrisky,analyticalintegrationrequiresdataduplication JasrajDange,AndreiDragus,AliGhodsi,HaoyuHuang,YiheHuang,Stas throughETLpipelines,andcross-cloudportabilityislimited.Once Kelvich,HeikkiLinnakangas,HansNorheim,IppokratisPandis,Nikita Shamgunov,EmSharnoff,JohnSpray,ZhouSun,ReynoldXin,Matei deployedatscale,organizationsbecomedeeplydependentonthe Zaharia.Lakebase:ServerlessPostgresoverOpenLakeStorage.PVLDB, vendor’sproprietarystoragelayer. 19(12):4385-4398,2026. Thehistoricalevolutionofdatabasesystemshelpsexplainhow doi:10.14778/3827998.3828040 thissituationemerged.Mostofthedatabasesystemsusedtoday, suchasMySQL[38],PostgreSQL[4],andOracle[3],inheritedtheir designfromthefirst-generationdatabasesystemssuchasSystem R [13] and Ingres [26], and tightly bound compute and storage ThisworkislicensedundertheCreativeCommonsBY-NC-ND4.0International withinasinglemachine.Thisdesignwasrationalinthepre-cloud License.Visithttps://creativecommons.org/licenses/by-nc-nd/4.0/toviewacopyof era,whenlocaldiskaccessdramaticallyoutperformednetwork thislicense.Foranyusebeyondthosecoveredbythislicense,obtainpermissionby emailinginfo@vldb.org.Copyrightisheldbytheowner/author(s).Publicationrights storageandverticalscalingwastheprimarypathtoperformance. licensedtotheVLDBEndowment. Ascloudinfrastructurematured,second-generationsystemssuch ProceedingsoftheVLDBEndowment,Vol.19,No.12ISSN2150-8097. doi:10.14778/3827998.3828040 asAmazonAurora[46],Socrates[8]andAlloyDB[1],introduced 4385 physical separation between compute and storage, moving per- sistenceintodistributedbackendlayers.Thesesystemsimproved elasticityandavailability,buttheseparationremainedinternalto thevendor’sarchitecture.Thestorageformatsremainedpropri- etary,andthedatacontinuedtobeaccessibleonlythroughthe primarydatabaseengine.Theresultisatransitionalarchitecture thatimprovesperformancecharacteristicswithoutfundamentally addressingportability,openness,ormulti-engineaccess. Compute lifetime Meanwhile, new workloads are placing unprecedented pres- sureontransactionalsystems.TheriseofAI-drivendevelopment andautonomousagentsintroducesafundamentallydifferentin- teraction model with databases. Agents generate code, execute migrations,evaluatehypotheses,andperformexperimentsatma- chinespeed.Theseworkflowsrequiretheabilitytocreateisolated, high-fidelitydatabaseenvironmentsondemand,runexpensiveex- ploratoryquerieswithoutimpactingproductiontraffic,andscale computeelastically—oftenforshort-livedtasks.Traditionalalways- on,tightlycoupleddatabaseinstancesarepoorlysuitedtosuch ephemeralandburstyworkloads. In this paper, we present Lakebase, a third-generation trans- actionaldatabasearchitecture.Lakebasefullyseparatescompute fromstorageandpersistsdatabasedatadirectlyincloudobject storageusingopenformats.TransactionalengineserverlessPost- greSQL operates independently from the storage layer and can scaleelasticallyaccordingtoworkloaddemand.Asthestorageis externalizedandopen,databasescanbebranchedandclonedusing copy-on-writetechniques,enablingnear-instantcreationofiso- latedenvironmentsevenatlargescale.Operationaltaskscanrun onseparatecomputeinstanceswithoutinterferingwithproduction traffic.Furthermore,sharingacommonlake-backedstoragelayer enables unified transactional and analytical processing without costlydataduplication. Lakebaseredefinesthedatabaseaselastictransactionalcom- puteoveropen,durablestorage.Byaligningwithmoderncloud infrastructureandAI-nativeworkflows,itaddresseslong-standing challengesinoperationalcomplexity,developmentvelocity,and vendorlock-in.Wearguethatopen,lake-backedtransactionalsys- temsarethenaturalnextgenerationofdatabasearchitecture. Inthispaperwemakethefollowingcontributions.Wepresent Lakebase,alake-backedtransactionalarchitecturewithfullcompute– storageseparation,inSection3.Lakebasebuildsonanopen,MVCC- compatiblestoragelayerthatsupportsscalablecopy-on-writebranch- ing,presentedinSection4,togetherwithelastic,serverlesscompute, presentedinSection5.LakebasenativelyintegrateswiththeLake- housetoprovideaunifieddatasolution,presentedinSection6. Finally,weempiricallyevaluatethebranching,elasticity,OLTP performance,andLakehouseintegrationofLakebaseinSection7, andpresentrelatedworkinSection8. 2 AGENTSANDDATABASESYSTEMS BeforepresentingLakebase’sdesignandevaluation,weexamine howAIagentsarereshapingdatabaseworkloads. Atthetimeofwriting,Lakebasecreatesandmanagesmorethan 10milliondatabasesdaily,withAIagentsnowcreatingroughly4× moredatabasesthanhumanusers.Largelanguagemodels(LLMs) setupmoC tnecreP 60 40 20 0 0–1 sec 1–10 sec 10 sec–1 hr1 hr–1 day 1-7 days 7-30 days 1+ months Figure1:Computelifetimeobservedinproduction. Branch depth stcejorp tnecreP 80 60 40 20 0 [2] [3-4] [5-8] [9-16] [17-64] [64+] Figure2:Branchdepthobservedinproduction. nowenableagenticframeworksthatgeneratecode,runtests,andit- erativelyrefineapplicationswithminimalhumaninvolvement.The architecturalprimitivesofthird-generationdatabases—elasticcom- pute,storage/computeseparation,branching,andopenformats— predatethistrend,butagenticworkloadsamplifytheirimportance andstressearlierOLTParchitecturesalongthreedimensionsthat directlyshapedatabasedesign. CostSensitivityandProliferationofApplications:Agentic developmentsharplylowersthecostofcreatingapplications,yield- ingaproliferationofshort-lived,experimentalservicesthatare mostlyidle,frequentlydiscarded,andindividuallylow-value.As Figure1shows,takenfromtheDatabricksLakebaseservice,many productiondatabaseinstancesstayactiveforunder10seconds. ThispoorlymatchestraditionalOLTPdeployments,whichas- sumelong-livedinstanceswithcontinuouslyprovisionedcompute. Agenticworkloadsinsteadrequirefine-grainedelasticity,near-zero idlecost,andautomatedlifecyclemanagement—scalingdownnot onlycomputebutoperationalcomplexity,soper-applicationcost staysnegligible. EvolutionaryWorkflows:AtDatabricks,wehaveobservedthat well-specifiedapplicationscannowbegeneratedfromscratchin minutes,andfeaturesthatoncetookquartersofcoordinatedhu- maneffortcanbecompletedindayswithagents.Bycompressing iterationcycles,agenticworkflowsletdevelopersexploremany candidateimplementationsinparallelratherthanasingleplanned path. This extends from source code to database state: each itera- tionbranchesoffboththecodeandthedatabaseoftheprevious one[14].Figure2showsthedatabasebranchdepthweobservein theDatabricksLakebaseservice.Manyproductiondatabaseshave deepbranchinghierarchies,someexceeding500branches.Database 4386 checkpointingandbranchingthusbecomefirst-classprimitives, Proxy Proxy ... Proxy Lakehouse providinga“gitcheckout-b”experiencefordatabases. OpenEcosystems:Agenticsystemsworkbestwithwidelyused Lakebase Compute Compute ... Compute Manager (Postgres) (Postgres) (Postgres) openecosystemswellrepresentedinpublictrainingcorpora,which Write Read stronglyfavorsopen-sourceinterfacesandformats—particularly Multi-tenant Storage PostgreSQLcompatibility. Safekeeper Pageserver Direct ETL Storage read ThisextendsbeyondSQLtothestoragelayer:openformatslet Controller Safekeeper Pageserver Reverse ... ... externaltools,agents,andanalyticalenginesinspectandprocess WAL ETL datawithoutproprietaryinfrastructure,motivatingarchitectures Safekeeper streams Pageserver thatretainstandardPostgreSQLstoragesemanticswhileplacing datainsharedobjectstorage. Cloud Object Storage 3 LAKEBASEARCHITECTURE Figure3:Lakebasearchitecture. Lakebaseisathird-generationtransactionaldatabasethatseparates computefromstorageandpersistsalldatainopenformatsoncloud objectstorage.ItdeliversenterpriseOLTPacrossmultipleclouds, to sub-second using a warm pool of ready computes, and with serving both traditional operational workloads and the agentic fastercrashrecoverybecauseWALredoisoffloadedtodistributed patternsoftheprevioussection.Thissectionpresentsthedesign storage.WeobserveLakebasecomputestartuptypicallyundera goals,thenanoverviewofthearchitectureanditscomponents. second. 3.1 DesignGoals 3.1.4 Zero-copybranchingoperation. Developersbranchcodeto 3.1.1 Leveraginghighlydurableobjectstorage. Themostcritical workonnewfeatures,butthedatabaseisstillsharedacrosscode contractofanOLTPdatabaseisdurability.Cloudobjectstorage branches,andagentsmaycreatemanybranchesperprompt.For offershighdurabilityandavailabilityatafractionofthecostofop- example,anagentbuildinganinventorywebappmaylaterbeasked eratingdisks—e.g.,AWSS3guarantees119sofdurability,replicates totrackorderhistory,updatingbothcodeanddatabaseschemaand acrossavailabilityzones,andautomaticallytiersdatabyaccess data.Copyingdataperpromptwouldaddhighlatency.Lakebase pattern,loweringcostforcolddatawhilekeepinghotdatafast.It insteadofferszero-copybranching:creatingabranchisanO(1) isalsoversionedandsupportsrestores,guardingagainstsoftware metadataoperation,sodev-loopiterationsbranchdataaswellas errors.Lakebasepersistsalldata,includingwrite-aheadlog(WAL) code,shorteningpromptresponsetime. records,inobjectstorage. 3.1.5 Scalingcomputeandscaletozero. Workloadsvarywidely:a StoringdatainopenformatsintheobjectstorageletsLakebase retailOLTPdatabasemaybediurnal,peakingduringbusinesshours, integratenativelywiththeLakehouseecosystem[9],unifyingtrans- whileasocial-mediaappisburstyandevent-driven,surgingon actionalandanalyticalaccess.Spark[49]andLakehouse//RT[31] majorevents.Provisioningforpeakisnotcost-effective.Lakebase canreadobjectstoragedirectlyforreal-timeanalytics,isolated scalescomputewithload,monitoringcomputeresourceusageand fromtransactionalworkloads;reverse-ETLwritesLakehousetables working-setsizetoscaleupintimeforperformanceanddownto intoobjectstorageforPostgreSQLtoconsume;andforward-ETL savecost,andtozerowhenidleforaperiod. streamsPostgreSQLchangestoLakehousetablesnatively. 3.1.6 Easeofoperations. TraditionalOLTPdatabasesimposesig- 3.1.2 Leveragingcloudinfraforhighavailabilityandperformance. nificant operational burden: administrators must plan capacity, AnOLTPdatabasemustalsobehighlyavailableandperformant, managebackups,configurereplicas,orchestratefailovers,andtune typicallyansweringqueriesinafewmilliseconds,whichobject scalingparameters.Lakebasemakestheseautomatic—autoscaling storagealonecannotmeet.Cloudprovidersofferservicesfrom andscale-to-zeroremovemostcapacityplanning,branchingand bare-metalmachinestopurpose-builtofferingsatdifferentperfor- point-in-timerestoresimplifybackupandrecovery,andautomated mance,availability,durability,andpricepoints,enablingalarge cross-AZfailovermaintainsavailability—reducingoperationalcom- designspace.AsFigure3shows,Lakebaseemploysastoragehier- plexityforbothhumanoperatorsandagents. archy:itrunsmanagedPostgreSQLonbare-metalmachineswith localSSDs,cachingfrequentlyaccesseddataoncomputeSSDsfor 3.2 Overview highperformance.Oncachemisses,Pageserversservepagesthey Figure3showstheLakebasearchitecture.Lakebaseseparatescom- continuouslymaterializeandcacheon-disk;rarelyaccessedkeys putefromstorage.Itdecouplesacomputenode’slifetimefrom arefetchedfromobjectstorage.Atransactionisdurableonceits itsstoragesothetwoscaleindependentlyandnon-PostgreSQL WALisreplicatedacrossmultipleSafekeeperdisks. computescanoperatedirectlyonsharedstorage.TheLakebase 3.1.3 Fastcomputestartup. Computestartupisonthecriticalpath ManagermanagesafleetofPostgreSQLComputenodes;theStor- foragenticworkloads.Theagentplatformstartsanewcomputein ageControllermanagesthemulti-tenantstorageofPageservers responsetoeachuserprompt.ManagedOSSPostgreSQLservices (PSs)andSafekeepers(SKs).Alldataisdurablypersistedinobject commonlytakesecondstominutestospinup,dominatedbyVM storage.AwriteisdurableoncereplicatedtoaquorumofSKs,and provisioningandcrashrecovery.Lakebasedrasticallyshortensthis PSscontinuouslymaterializepagesforfastreads. 4387 3.3 PostgreSQLCompute segmentstoobjectstorage.AnSKtimelineacceptswritesfromthe ALakebaseinstancehasonePostgreSQLprimaryandoptionally PostgreSQLprimaryandstreamsWALtoreplicasandPageservers. readreplicas.Theprimaryreplicatesdataacross3Safekeepersand AtimelinereplicatesWALacrossSKsusingaRaft[37]-likepro- is initially assigned one Pageserver; the database shards across tocol:thePostgreSQLprimaryistheWALproposerandtheSKs morePageserversasitgrows. areacceptors.AWALrecordisdurableonceaquorumhaswritten AcomputenoderunsPostgreSQLwithacustomizedstorage ittodisk,andthesystempushesWALfromthemostadvancedSK managerimplementingthePostgreSQLSMGRAPIs,whichtalkto replicatolaggingonesforredundancy. thePageserversandupdatethelocalSSDcache.AnSMGRreadis Topreventsplit-brain(wheremultiplecomputesclaimingto servedfromthelocalcache,oronamissfetchedfromthePage- bewriters)aPostgreSQLcomputemustelectitselfleaderbefore serverandcached.AnSMGRwriteonlyupdatesthelocalcache, writing,andaSKquorumacknowledgesonlyoneleader.ASK sincePostgreSQLneedsonlythepersistedWALtorecover. maintainsamonotonicallyincreasingtermnumber.Anewcompute AcomputealsorunsaWALproposerthatcontinuouslybroad- primaryincrementsthetermandproposesitselftoaSKquorum. caststheWALrecordstoallSafekeepers,advancingonceawriteis SKsacceptonlythehighesttermtheyhaveseen.AWALrecord durableonaquorum. isacknowledgedonlyafteraquorumofSKshasflusheditunder Aprimarystartsupbyrequestingabasebackup—themetadata thecurrentterm.Oncethecomputedetectsatermchange,itmust filesneededtostart—fromthePageserver,avoidingacheckpoint; re-electitselfastheleader. therecoverypointisthelastWALrecordthePageserveringested 3.5.2 Pageserver. A Pageserver (PS) streams WAL from SKs, it ratherthanthelastcheckpoint. maintainstenantsandtheirtimelines,andexposestwoAPIsto Readperformancescaleshorizontallybyaddingreadreplicas, computes:GetPage@LSNandGetBaseBackup.Eachtimelinecon- whichsharetheprimary’sSafekeepersandcontinuouslystream tinuouslyreadsWALfromtheSKandmaterializespages,orga- WALtoupdatetheirlocalcaches.Lakebasealsosupportsstatic nizingdeltaWALrecordsandmaterializedfull-pageimagesinan (read)replicaspinnedatagivenLSNfortime-travelqueries. LSM-tree-likestructure. DuringaGetPage@LSNcall,thePSfindsthelastfull-pageimage 3.4 Non-PostgreSQLCompute atanearlierLSN,replaysthedeltaWALrecordsuptotherequested BeyondPostgreSQLcompute,externalenginescanoperatedirectly LSNontoit,andreturnsthepage.TherequestblocksuntilthePS onthesharedstorage,givingaunifiedviewacrossLakebaseand hasingestedWALuptothatLSN. Lakehousedata.LakehousetablesaresynceddirectlyintoLakebase A PS uploads a snapshot of the tree and metadata to object storage, bypassing PostgreSQL compute. Distributed executors, storageforfastcrashrecovery.Eachtimelinekeepsahotstandby suchasSpark,generatePostgreSQL-compliantpagefilesandwrite thatdownloadsthesnapshotandhotlayerfiles,sowhenthepri- themtoobjectstorage,whichPostgreSQLthenconsumesasregular maryfailsittakesoverrapidlyandservesGetPagerequestsfrom tables. already-cachedlayers. Foranalytics,queryengines,likeLakehouse//RT,readimmutable PostgreSQLpagefilesdirectlyfromobjectstorage:queriesbind 3.5.3 StorageController. Thestoragecontroller(SC)managesall toacommittedsnapshotandrunoveraconsistentviewwhileby- SKs and PSs. It assigns each new timeline to the most idle SKs passingPostgreSQLcompute.Thisgiveszero-copyaccesstolive andPSswithAZaffinityforperformanceandfaulttolerance,and datawithoutinterferingwithtransactionalworkloads,enabling re-optimizesplacementinthebackgroundastheworkloadevolves. horizontallyscalable,vectorizedprocessing.Suchmulti-engineac- SCmonitorsSKandPShealthviaperiodiclivenesspings.Ona cessoversharedstoragedistinguishesthird-generationdatabases; SKfailureitquicklymigratestheaffectedtimelinestoanewreplica second-generationsystemsexposedataonlythroughtheprimary torestoreredundancy;onaPSfailureitsignalsthehotstandbyto engine. By persisting data in open PostgreSQL page format on takeover. object storage, Lakebase decouples data access from any single Whenadatabasegrowslarge,SCshardsitstimelineacrossPSs engine. transparently and with zero downtime, increasing the GetPage throughput.EachshardingestsitsrelevantWALrecordsfromaSK replica. 3.5 StorageComponents Thestoragecontrollercreatesonestoragetenantperproject,con- 4 STORAGECOMPUTESEPARATION tainingmultipletimelines;eachcomputebelongstoonetenantand ThissectiondetailsthemechanismsunderlyingLakebase’sstorage- timeline.Aprojectstartswitharoottimeline,andbranchingor computeseparation:howdataispersisted,versioned,andserved point-in-timerestore(PITR)createsanewtimelineunderthesame acrossthesystem’scomponents. tenant.Atenant’stimelinesareco-locatedonthesamePageservers soabranchcanefficientlyreaditscopy-on-writeancestor’sdata, thoughtheymayreplicateacrossdifferentSafekeepers. 4.1 DatabaseLog(WAL)andLSNs WALstorageiscriticalforperformance,durability,andcorrectness. 3.5.1 SafeKeeper. ASafekeeper(SK)maintainsalistofisolated The compute primary generates the WAL byte stream, durably timelines,eachstoringWALsegments.Itkeepsthemostrecent persistedinobjectstoragethroughSafekeepers(SKs).Pageservers WAL on local disk and proactively uploads quorum-committed (PSs)receiveWALrecordsfromSKsandredothemtomaterialize 4388 Compute LSNs Delta layer Image layer LSN 1.Current LSN 4 3 2 1 2.Commit LSN 3.Replica replay LSN GetPage (key=k, lsn=l) 4.Static replica LSN l 2. Find all WAL records touching Database Log k since the image LSN until l SK LSNs 5. Flush LSN 6. Commit LSN PS LSNs 7. Backup LSN 8. Last record LSN 7 6 5 k 1. Find the latest image of k Key 9. Flush LSN 11 10 9 8 @ LSN < l 10. Remote consistent LSN Branch Log 11. Branch LSN Figure5:Pageserverstorageorganization. Figure4:WALandLSNsmaintainedbycomponents. newhistory/WALrecordsofthechildbrancharestoredindepen- dentlyfromthoseoftheparentbranch.Anytransactionthathas pageimagesatspecificLSNs,returnedtocomputeonrequest.Com- notcommittedatbranchLSNistreatedidenticallytoanin-flight pute,SKs,andPSseachtrackvariousLSNs(byteoffsetsintothe transactionduringcrashrecovery.Theyareabortedandpending WALstream)toprovidedurability,transactionalconsistency,and datamodificationsarenotvisibleatthechildbranch. fastcrashrecovery. Whenthechildbranchisfirstcreated,itsimplycontainsaref- AsFigure4shows,acomputeprimarytracksthecurrentLSN 1 erence to the parent branch’s timeline ID and the branch LSN. andcommitLSN 2.ItappendsWALtothecurrentLSN,replicates AGetPagerequestonthechildbranchrecursesintotheparent each record to all SKs, and advances the commit LSN once the branchforanyhistoryorpagedatanotdirectlyavailableonthe recordisdurableonaquorum;oncrashrecoveryitrestoresdata childbranch.Thechildbranchismodeledasanewtimelinein uptothecommitLSN. Lakebasestorage.Timeline-leveloperations,suchascompaction AcomputereplicatracksitslastreplayLSN 3,belowwhich andgarbagecollection,thereforeoperatelargelyindependentlyon dataisvisibletoit.ItstreamsWALfromaSKandappliesrecords thechildandparenttimelines. toupdateitslocalcache,advancingthelastreplayLSNaftereach. Lakebase supports detaching a child branch from its parent. AstaticreplicaisinsteadpinnedataparticularLSN 4 andreads Detaching a branch is instantaneous and a metadata operation. onlyuptoit. PStrackstheancestryandasynchronouslycopiestheancestors’ ASKmaintainsflush,commit,andbackupLSNs.Itcontinuously datatothedetachedbranch.Thedetachedbranchmayre-parent flushes received WAL to disk, advancing the flush LSN 5; the underoneofitsancestors.Lakebasecurrentlydoesnotsupport primarynotifiesallSKsofitscommitLSN 6,andaSKstreams mergingtwobranches.Reconcilingdivergentphysicaldataisnot onlydatabelowittoPageservers.Fordurability,aSKuploadsall well-definedandoftenrequiresapplicationtoresolveconflicts. WALsegmentsuptothecommitLSNtoobjectstorage,trackedby thebackupLSN 7,andremoveson-disksegmentsbelowit. 4.3 PageServerStorageFormat APSingestsWALfromaSKintoanoptimizedstorageformat AllpersistentdataisstoredinstandardPostgreSQLpageformaton (subsection4.3)balancingingestionspeedandefficientGetPage cloudobjectstorage,readablebyenginesthatconsumePostgreSQL requests.ItadvancesthelastrecordLSN 8 onin-memoryingestion, pageswithouttheLakebasecomputelayer.ThePSingestsWAL thenbatchesandflushesrecordstodisk,advancingtheflushLSN 9 recordsfromSKsandmaterializesthemintoanLSM-tree-inspired (fromwhichitrehydratesoncrash).Italsouploadsflushedfiles structure,whichsustainshighWALingestionratewhilesupporting toremotestorage,advancingtheremoteconsistentLSN 10;ifno efficientpage-levelaccessforGetPagerequests. validlocalflushLSNexists(e.g.,diskfailureorfirst-timeserving), ThePSstorageformatiswrite-optimized.AnincomingWAL itrecoversfromthere. recordisappendedtoanin-memorybufferthat,oncelargeenough oroldenough,isflushedtothePS’slocaldiskanduploadedto 4.2 Branching remotestorageasadeltalayer—afileofrawWALrecordscovering Lakebase’sbranchingforksadatabasein𝑂(1)withoutanyexpen- arangeofkeysandLSNs,showninFigure5.Delta-layeringestion sivephysicaldatacopy.Whenthedatabasehistoryisforked,a involvesnoWALredoortransformation,lettingthePSkeepup newbranchiscreated,andtheoriginalhistorybecomesthepar- withwrite-heavyworkloads. entbranch.Parentandchildbranchessharehistory(andindeed Figure 5 illustrates how Lakebase’s storage format organizes thesamephysicalstorage)uptothebranchLSN 11 anddiverge layerfilesbetweentheLSNandkeydimensions,plushowthePS afterwards.ThebranchLSNmustbechoseninsuchawaythatit resolvesapageimagetosatisfyaGetPage@LSNrequestthroughthis ispossibletoreconstructeverysinglepageontheparentbranchat process.ForefficientreadsatanyLSNwithinthePITRwindow,the thisLSN,atthetimeofthebranchcreation.Forsimplicity,were- PSorganizeslayerfilesalongboththeLSNandkeydimensionsand strictbranchLSNselectiontobeanLSNwithintheparentbranch’s runsbackgroundLSM-tree-stylecompaction,whichreplaysdelta- PITRwindow.AsshowninFigure4,afterthechildbranchiscreated, layerWALrecordsontoexistingpageimagestoproducenewimage 4389 layers(arangeofkeysatoneLSN).AGetPagerequest,specifyinga pagekeyandLSN,looksupthistwo-dimensionaltreetofindabase LSN ? image(fromanimagelayer)andanydeltaWALrecordstoreplay, LwLSN ? Compute ? cache (Postgres) performstheredos,andreturnsthepage.Compactionistunedto ? ? balancewriteamplificationfromimagerewritesagainsttheread LFC latencyofreplayinglongWALchains.Whenthenumberofdelta Object Storage layersabovethelatestavailableimagelayertomaterializeakey Page Server Page number atthelatestLSNexceedsathreshold,PStriggersanimagelayer compactiontomaterializedataatthelatestLSNintonewimage layers. Figure6:Readpath–GetPage@LSN. PSusesthecloudobjectstorageasthesourceoftruthforper- sistedlayerfiles.ItcachesthemonephemerallocalSSDsforfast access.PSmaintainsanindexfileinremotestoragethatlistsall This is inherently an overestimate because we are obligated to layerfilesinatimeline.Whenthelocaldiskrunslow,PSevicts retainPITRhistoryandwebilltheuserforPITR.InLakebasethe theLRUlocallayerfiles.Afuturereadofanevictedlayerfilewill downloaditfromremotestorage. spaceamplificationis𝑂 (cid:16) 1+𝑅+ 𝑤 𝑁 ·𝑃 (cid:17) ,whichisonematerialization Theformatsupportsbranching:ifthePScannotsatisfyaread ofthelivestate(1),theun-reclaimedGCslack(𝑅),andtheretained fromthetimeline’sownlayerfiles,itrecursivelysearchesthepar- in-windowhistory𝑤·𝑃,whichisusuallythedominantterm.Across enttimeline’slayers,whosemetadataisinthetimelineindexfile. ourproductionfleet,weobserve≈7xspaceamplification.Weexpect Deepbranchhierarchiesthereforehurtreadperformance,since tofurtherimprovetheefficiencyofthestorageformat,butthe areadspansmoretimelines.Afteranagentfinalizesonthedata- valuesweobserveinproductionalreadyprovesufficient. base,aproductiondatabasebenefitsfromdetachingthebranchand promotingittotheroot. 4.4 Reads Backgroundgarbagecollectionperiodicallyremovesdeltaand OLTPapplicationsdemandfastreads.Figure6showsthereadpath imagelayerswhosehistoricaldataisoutsidethePITRwindowand ofLakebase.WhereOSSPostgreSQLreadsapagefromalocalfile, unneededforfuturereplays. Lakebasecachestheworkingsetinacompute-sidelocalfilecache (LFC)forcomparableperformance. 4.3.1 Amplification. WecharacterizethecostofthePageserver storageformatalongthestandardLSMdimensions.Let𝑁 bethe Acachehitreturnsthepageimmediately 1;amississuesa livedatasetsize(inpages)atthelatestLSN,𝑤 theWAL(write) GetPage@LSNtoaPageserver 3.Therequestmustcarrythecorrect ingestrate,and𝑃 thepoint-in-time-recovery(PITR)window,be- LSNforconsistentreads.IssuingGetPageatthecurrentLSNis slow,asthePageservermuststalluntilithasingesteduptothat yondwhichhistorybecomesreclaimable.Twoknobsdominate thebehavior.Theimagethreshold 𝐼 isthemaximumnumberof LSN,sincethepagemayhavechangedbetweenitslastrecordLSN andthecurrentLSN.Toavoidthis,arequestcarriestwoLSNs: deltalayersallowedtostackoverakeyrangebeforeafreshimage therequestLSN specifiesthepageversiontofetch,andthenot- (afullsnapshotofthatrange)iswritten;itboundstheper-read reconstructiondepth.TheGC-compactiontriggeringratio𝑅fires modified-sinceLSN promisesthepagewasunchangedbetweenit andtherequestLSN,sothePageserverneedstoonlyingestupto thegarbage-collectingcompactiononcenewlyaccumulatedhistory reaches𝑅timesthesizeofthepreviously-compactedbase,collaps- thenot-modified-sinceLSN. Acomputekeepsafixed-sizelast-written-LSNcache(LwLSN) ingallhistorybelowtheGChorizonintoanewbase(amaterialized mappingeachpagetoitsnot-modified-sinceLSN 2,updatedtoa snapshotatthehorizon). Writeamplificationisconstant,𝑂(1):eachbyteiswrittenonce page’sLSNwhenadirtypageisevicted.GetPageusestheLwLSN ondeltaingestion,plusan𝑂(1/𝐼)termforimagecreation(afresh entryonahit,orthegloballast-writtenLSNonamiss. imageisamortizedoverthe𝐼deltasthattriggeredit)andan𝑂(1/𝑅) OnanLFCmiss,thePShandlestheGetPage@LSNasinsubsec- termforGC-compaction(eachcollapsewritesonebaseofsize≈𝑁 tion4.3,possiblyfetchinglayerfilesfromremotestorage(4 and butisamortizedoverthe≈𝑅·𝑁 ofhistoryaccumulatedsincethe 5).ThecomputewritesthereturnedpageimagetoitsLFCand updatestheLwLSNcache.Prefetchreadsfollowthesamepath. lastone).OnemajordifferencewithatraditionalLSMtreeisthat ourstorageformatusesaconstantnumberoflevels.Wedonot 4.5 Writes claimourstorageformattobethestate-of-the-art,butrathertuned itforpredictability. Figure7showstheLakebasewritepath.TheLakebasecompute Reads:thePSsupportsonlytheGetPage@LSNAPIandhasno primaryreplicatesthePostgreSQLWALusingaRaft-styleprotocol, range-scan primitive. GetPage@LSN cost𝑂(𝐼) layer visits, since actingastheleaderthatappendsWALtotheSafekeepersviaa theimagethresholdboundsthedeltachainthatmustbereplayed WALproposerimplementedasaPostgreSQLextension.Atstartup toreconstructapage.Notethatthecompute-sidecachetypically theproposerelectsitselfleaderbyproposinganewterm;oncea attains>98.5%hitrateinourevaluations,hidingmostofthelatency SKquorumacknowledgesthehigherterm,itbeginsappending of GetPage@LSNoperations. WAL 1. WedefinespaceamplificationinLakebaseas(totalPageserver TheproposertrackseachSK’sflushLSNandsetsthecommit storagesize)/(logicalsizeoftheuser’sdatabaseatthelatestLSN). LSNtothequorumflushLSN.ASKappendseachWALrecordtoa 4390 | | | | | | AZ-1 | AZ-2 | AZ-3 | | --- | --- | --- | --- | --- | ---- | ---- | ---- | Safe | | | | Page | | Compute | Compute | Compute | | --- | --- | ------ | ------- | --- | -------- | -------- | -------- | | | | Keeper | ? | | | | | | | ? | | Servers | | Primary | Replica | Replica | WAL | | | Safe | | | Reads Writes | | | | -------- | --- | ----- | --- | --- | ------------ | --- | --- | | Proposer | ? | | | | | | | Keeper | | | | | | SK-1 | SK-2 | SK-3 | | -------- | ------------------ | ------ | -------------- | --- | ---- | --------- | --------- | | Compute | ? | | | | | | | | | Postgres | Safe | ? | | | | | | | | Keeper | | | | PS-2 hot | PS-1 hot | | | | | Object Storage | | PS-1 | | | | | | | | | | standby | standby | | | Figure7:Writepath. | | | | PS-2 | | | Object Storage localsegmentfile,periodicallyflushingtodisktoadvanceitsflush Figure8:Highavailability. | LSN,andreturnsitsflushandknowncommitLSNs | | | 2. | | | | | | ---------------------------------------- | -------- | ---------- | ----------------- | --- | --- | --- | --- | | The proposer | advances | the commit | LSN once a quorum | has | | | | flushedtodisk,solaggingSKreplicascanreduceredundancy;the | | | | | 4.7 ComputeReadReplicas | | | | | --- | --- | --- | --- | ----------------------- | --- | --- | --- | proposerdetectsalaggingSKreplicaandbackfillsitsmissingWAL Lakebasescalesreadperformancehorizontallywithreadreplicas. fromthemostadvancedreplica. Areplicaisinitializedfromaslimbasebackupandconnectstothe SKseagerlyuploadWALsegmentstoobjectstoragefordurabil- ity 4.The3SKsgossiptheircommitLSNs 3 anddeterministically sameSafekeepersandPageserverastheprimary.Lakebasesupports electoneuploadleader,load-balancingacrosstimelines;onceup- twokindsofreplicas:aregularreplicathatfollowstheprimary, andastaticreplicapinnedataparticularLSNfortime-traveland loaded,localsegmentsbelowthebackupLSNmayberemoved. adhocqueries. WhenwritesoutpacePSingestion,theproposerappliesback- pressure:thePSreportsthreeLSNs—lastingested,flushedtolocal | | | | | 4.7.1 ReadReplica. | AreadreplicastreamsWALfromaSKand | | | | --- | --- | --- | --- | ------------------ | -------------------------------- | --- | --- | disk,anduploadedtotheobjectstorage—viaSKs,andtheproposer continuouslyappliesrecordstokeepitscachecurrent,skipping throttleswritesifanylagsthecommitLSNbeyondathreshold. recordsforpagesabsentfromitscache.Thisissafe,becauseitcan Thesethresholdstradewritethroughputagainstreadlatencyand alwaysfetchapagefromaPageserver. recoverytime. | | | | | Primary | and replica availability | are | decoupled. A replica re- | | ------------------------------ | --- | --- | ---------------- | ------- | ------------------------ | --- | ------------------------ | | ThePageserveringestsWALfromSKs | | | 5.ASKdecodeseach | | | | | mainsavailableandkeepsingestingthroughprimaryfailures,and record’simpactedpageidsandroutesitonlytotherelevantPage- switchestothenextavailableSKifitlosesitscurrentone. servers;metadata(e.g.,relationsize)istrackedsolelybythespecial ALakebasereadreplicacanbecreatedatanyLSNandopensfor Shard-0,soallmetadataupdatesgothere.APageserverprefers queriesimmediately,seeingthelatestdata.ThisisfasterthanOSS ingestingfromtheSKreplicawiththehighestcommitLSNinits PostgreSQL,whichmustredofromthelastcheckpointandobserve ownAZ. arunning-transactionsWALrecordbeforeacceptingconnections; Thesystemprovidesstrongdurabilityguaranteesinthepresence LakebaseinsteadinitializesfromthePS’slastrecordLSNandbuilds ofAZ+1outages.First,PSmaintainsadditionalcopiesofthemost therunning-transactionslistfromthePostgreSQLcommitlog. recentdataasitcloselytailstheWALstreamwithminimallag. Second,inpractice,recoveringafailedSKrequiresreplicatingonly 4.7.2 StaticReplica. AstaticreplicaispinnedatanLSNwithin afew16MBWALsegmentsthathavenotyetbeenbackedupto thePITRwindow.Itusesthesameleasemechanismtokeepthe remotestorage. Pageserverfromgarbage-collectingversionsitneeds,butunlike areadreplicaitdoesnotstreamWALfromSKs,simplycaching | 4.6 Availability | | | | pagesforlowerlatency. | | | | | ---------------- | --- | --- | --- | --------------------- | --- | --- | --- | Lakebasecomputeandstoragecomponentsarehighlyavailable, | | | | | 5 COMPUTEAUTOSCALING | | | | | --- | --- | --- | --- | -------------------- | --- | --- | --- | seeFigure8.AcomputeanditsreplicasspandifferentAZs,anda failedprimaryorreplicaisrepairedwithanewnodeinunder500 Lakebasecomputesareserverless:theyscaleupunderload,down msthankstowarmpoolsandstoragedecoupling.Customersmay asitdecreases,andtozerowhenidle,removingmanualcapacity configurecomputeHAgroupswithhotstandbysreadytotakeover planning and making compute cost proportional to usage. Pop- onfailure.Computewritesarereplicatedacross3SKsin3AZs, ularcontainerorchestratorssuchasKubernetesareill-suitedto toleratingonenodeorAZfailure. provisioningLakebasecomputes:priorwork[41]showstheweak APSprefersstreamingWALfromtheSKreplicainitsAZ.Each host–containerisolationisamajorsourceofsecurityvulnerabili- PSshardkeepsahotstandbyinadifferentAZthatproactively ties,andprovisioningnewresourcesincloud-managedKubernetes downloadsthemostrecentlyusedlayerfilesfromtheprimary’s cantaketenstohundredsofsecondsforsomeVMs[7]. snapshots,soonaprimaryfailureittakesoverimmediatelyand Toovercomethis,Lakebase’scomputeisbuiltonNeonVM,an servesGetPagerequestsfromalready-cachedhotdata.Failovers APIforrunningvirtualmachinesinKuberneteswithin-placever- areautomatic,requiringnooperatorintervention. tical scaling and live migration; each compute runs as its own 4391 QEMU/KVMVM.Inside,Lakebaseaddsacustomresizablecache the scaling value is a weighted average across all cutoff points tocomplementPostgreSQL’sstatically-sizedsharedbuffers. withgrowthratesprojectedtoonehour;earlierpointsgetlower Above NeonVM, we keep a pool of warm computes so that weightsforlargerworkloads,reducingvolatilitywheneviction provisioningisoffthehotpathwhencreatingadatabaseorscaling costsoutweighcomputesavings. onefromzero,lettingLakebasewakeadatabaseinamedianof 5.2.3 MemoryScalingPolicy. Thedesiredmemorysizeaccommo- under500ms. datestwoneeds:Thecommoncase,thatthecomputecacheshould Lakebasehandlesmillionsofscalingoperationsdaily,sosome usethevastmajorityofmemory;andtheuncommoncase,that strategicchoiceslimitthemaintenanceburden.Backingtheprimary allocation-heavyoperationsmaytriggerscalingup,butweneedto computecachebydiskisoneexample:usingtheoperatingsystem’s reserveequivalentlylargeramountsofmemoryforthecache. pagecacheratherthannormalallocations—evenwhenthecachefits Forthecommoncase,thememoryscalingpolicysetsthedesired inmemory—easespressureonthekernelallocatorduringmemory sizesuchthattheamountofallocatedmemory,plustheamount scaling, which normal allocations would otherwise make more ofpagecachememorywithinthedesiredcachesize,islessthan fragile. 90%ofthetotalmemoryprovidedtothevirtualmachine.Forthe allocation-heavycase,wealsoensurethatallocatedmemoryalone 5.1 ScalingMechanics islessthan75%ofthetotalmemory. NeonVMsupportsin-placeverticalscalingofCPU,memory,and diskwithoutVMrestart.CPUscalingenablesanddisablesindivid- 5.2.4 FastPathunderMemoryPressure. Inadditiontoperiodic ualCPUswithintheguestOSviaaguestagent.Memoryscaling metricscollection,wealsomaintainafastpathfor“immediate” usesvirtio-mem,balancingtheratioofmovableandkernelmemory; scale-upundermemorypressure.Aguestagentpollsmemoryusage welimitthescalingrangetoavoidfragmentation-induceddown- every100msandinitiatesanoutboundrequesttotheautoscaler- scalingfailures.Diskscalingcombinescooperativereclamation— agentforadditionalmemory,regardlessofthemostrecentmetrics. filesystemsissuediscardoperationsthattranslatetoholepunches 5.3 ScaletoZeroandQuickProvisioning on host backing files—with oversubscription for swap and tem- porarystorage.Thedisk-backedcomputecacheissynchronously Scalingtozero—theautomaticsuspensionofidlecomputeresources— resizedduringscalingoperations. addressesbothcostandoperationalconcerns.Itremovesthecost floorassociatedwithalways-onprovisioning,whichisparticularly 5.2 ScalingPolicies relevantfortheephemeralworkloadsdescribedinSection2,and freesusersfrommanuallymanagingthelifecycleoftemporary Lakebase’sautoscalingpolicyisenactedperhostbytheautoscaler- resources.Quicklyprovisioningorscalingfromzerokeepsthis agent,whichcollectsmetrics,seeksschedulerapproval,andsets transparenttotheuser.Lakebaseachieveslessthan500msmedian thedesiredNeonVMsize.Itfetchesmetricsfromeachcompute cold start time, using a pool of warm virtual machines to keep every5s,keepingonlythemostrecent.Thescalingalgorithmis provisioningoffthehotpath. effectivelystateless;thestateneededtominimizevolatilitylives inthecompute,exposedasmeasuresofloadoveralongertime 5.3.1 TerminatingaCompute. Scalingtozeroishandledbyape- window. riodicjobthatchecksthetimesincethelastquerywasissuedto Scalingislinearanduniform,inincrementsofascalingunit eachcompute.Ifthatdurationislongerthantheuser-configured of1GiBofRAMandtheproportionatefractionofaCPU.After timeout(bydefault,5minutes),weshutdownthecompute.No eachcollection,thedesiredunitsforCPU,memory,andcacheare stateispreservedacrosscomputerestartsexceptforwhatisper- estimatedindependently,andtheVMsizeissettotheirmaximum. sistedtostorage.Fullvirtualmachineterminationandcleanupare thenhandledasynchronously. 5.2.1 CPU Scaling Policy. The CPU target blends the 1- and 5- minuteloadaveragesfromtheguestkernel:the1-minuteaverage 5.3.2 WakingaCompute. Userscanconnecttoadatabasethat isusedwhenitdifferssubstantiallyfromthe5-minuteone(forre- haspreviouslyscaleddowntozero,anditwillbeautomatically activity),andthe5-minuteaverageotherwise(toreducevolatility). startedforthem.OninboundPostgreSQLconnections,theLakebase proxyholdstheconnectionandasksforacomputetobeassigned 5.2.2 CacheScalingPolicy. OLTPperformancetypicallydepends fromthepool.Duringtheassignment,thecomputedownloadsthe onwhethertheworkingsetfitsinmemory,andwithseparated basebackupfromthePageserverandstartscompute,afterwhich storageandcomputethismattersevenmore—yetusersstruggle proxymaystartforwardingconnectionstothecompute.Thevirtual tosizetheirworkingset,letalonetheircomputetofitit.Lake- machine is then asynchronously resized to the user-configured baseestimatestheworkingsetautomatically:ourcustomcompute minimumsize. cachemaintainsamodifiedHyperLogLogthattracksthenumber ofuniquepagesaccessedovertime. 5.3.3 WarmPooling. Speedingupvirtualmachineprovisioning EachbitintheHyperLogLog’sbucketsisreplacedbythemost timeistechnicallychallenging.Instead,wekeeptheprovisioningoff recenttimestampofahashwithanon-zerovalueforthatbit,giving thehotpathbypre-provisioningvirtualmachinesintoawarmpool, acheapapproximationoftheuniquepagesaccessedsinceanypast sothattheuser-visiblecoldstarttimeonlyincludescommunication point.Theautoscaler-agentthenestimatestheworkingsetwith withstorageandsetupofPostgreSQLinsidethecompute. aplateau-detectionalgorithmovertheuniquepagesaccessedin Virtualmachinesinthispoolareuniformlysized,andin-place the past 1–60 minutes. To avoid instability from binary cutoffs, verticalscalingallowsthemtoberesizedonassignment,rather 4392 thanmaintainingindependentpoolsfordifferentuser-configured mode achieves horizontal scalability, avoids the write through- scaling ranges. Inside the compute, binaries are pre-warmed to putlimitationsthattypicallybottleneckOLTPdatabases,andpro- avoidstartuplatencyfromlazymemoryallocationordiskIO. videsisolationforliveworkloads,whichareoftenlatencysensitive. Lakebaseproductionobservesseasonalchangesinstartcompute Snapshotloadsareapowerfultoolthatcanbeusedinmanysitua- requestsandsuddensurges.Thepoolissizedtofitthepredicted tions:initialloadingofadataset,periodicsyncsfortime-partitioned needs using a machine learning model that takes into account datasets,andbatchMLfeaturecomputation(whichcanbemerged seasonalityandperiodicspikesofuseractivity. withreal-timedatatoprovidefeatureswithlongwindows).Inthe future,direct-to-storagecanbeappliedtooptimizeotherbulkop- erations,suchasdistributedindexbuildingandphysicalschema 6 INTEGRATIONWITHLAKEHOUSE alterations. LakebasepersistsalldatainopenPostgreSQLpageformatoncloud TheDirect-to-Storageloadingpathprovidesatomicityatrela- objectstorageandexposesaconsistent,LSN-addressablepageview tiongranularity.Sparkfirstmaterializesthecompletesetoftable throughthePageserver.Thisallowsexternalenginestointeract pagesanduploadsthemtoobjectstorage,afterwhichtheLakebase withLakebasestoragedirectlywithoutroutingthroughPostgreSQL computeperformsametadata-onlyrelationswapinatransaction. compute.ThissectiondescribeshowLakebaseleveragesthisprop- Isolationispreservedbygeneratingthenewpageswithfrozen ertytointegratewiththeLakehouseecosystemalongthreeaxes: visibilitymetadata,allowingthemtobecomeimmediatelyvisible unifiedgovernancethroughUnityCatalog,efficientdataingestion toanytransactionwhosesnapshot observes theswap.Durabil- fromLakehousetoLakebase,andanalyticalaccesstoLakebasedata ityfollowsfrompersistingallpagestoS3beforecommit,while fromdistributedqueryengines. therelation-swapWALrecordisreplicatedthroughSafekeepers usingthestandardWALreplicationprotocol.Topreserveconsis- tency,concurrentDMLoperationstargetingatableundergoinga 6.1 UnifiedGovernanceandIdentity Direct-to-Storagesnapshotloadarerejected. LakebasecentralizessecuritybyintegratingwithUnityCatalog (UC)for unified authenticationand authorization. Eachcaller’s DatabrickseffectiveidentityispropagatedtoLakebaseviaOAuth and mapped to a PostgreSQL role on first use, so downstream servicessuchasSparkpipelinesorModelServingconnectunder 6.3 AnalyticsonLakebaseData theirownidentitywithoutmanagingseparatedatabasecredentials. WemodifiedUnityCatalogtodelegateaccesscontrolanden- Usersfrequentlyrequireanalyticalaccesstooperationaldata,rang- forcementtoLakebasetounifydirectPostgreSQLconnectionand ing from ad hoc queries in real time to complex data pipelines. accessthroughcatalog.Administratorscanissuestandardgrants Lakebasefacilitatesthisthroughtwocomplementaryintegration (e.g.,GRANT SELECT)throughUnityCatalog,whicharetranslated pathsthatareinherentlycost-efficientandminimizetheoverhead tonativePostgreSQLqueriesandappliedsynchronously.Unity ontheoperationaldatabase. Catalog’s catalog metadata is also served live from PostgreSQL Fordatapipelines,weintroducenativesynctoLakehouseusinga systemtables,sotheviewinUCalwaysreflectsthecurrentstateof logicaldecodingextension(wal2delta).Thisextensionhooksinto thedatabase,eliminatingACLdriftbetweenthegovernancelayer thePostgreSQLlogicalreplicationstream,decodingWALrecords andtheoperationaldatabase. andappendingthemdirectlytoaDeltatableinSCDType2for- mat.DownstreamSparkjobscanconsumethehistorystreamfor complextransformationsorcompactitintosnapshotsasneeded. 6.2 ServingLakehouseData Forreal-timeanalysis,weintroduceaDirectAccessmodeforana- Databricks customers have extremely valuable gold datasets in lyticsenginessuchasSpark[49]andLakehouse//RT[31],Databricks’ Lakehouse,producedbycomplexanalyticspipelinesthatjoinand real-timeanalyticsengine,enablingtheircomputetoreadPost- aggregatemanydisparatedatasources.Thesecurateddatasetsare greSQLpagefilesdirectlyfromthesharedstoragelayer—object expensivetocomputeandrefresh.Customerswantalow-latency storageorPageserver.Thismodepreservestheprimarybenefitof andhigh-throughputservinglayertobridgethegapbetweenana- traditionalfederation—instant,zero-copyaccesstolivedata—while lyticalpipelinesandproductionworkloads. bypassingthePostgreSQLcompute.Byshiftingexecutiontoan WemakethispossiblethroughSyncedTables,asimpleabstrac- analyticsengine,weavoidOLTPresourcecontentionandenable tionthatenablesefficientsyncingofdatafromLakehousetoLake- horizontalscalability,advanceddistributedqueryoperations,and base.Toreconcilethecompetingdemandsofhigh-throughputin- vectorizedexecution.Forexample,Lakehouse//RTretrievescon- gestionandnear-real-timefreshness,wearchitectedtwodistinct sistentPostgreSQLpagesattargetLSN,usingSIMDparsingand writepaths.ThestandardpathcreatesaSparkstreamingDataFrame asimplifiedMVCCchecker.TheresultingparsedArrowbatches thatreadstheDeltachangefeedandupdatesthedestinationtable arecachedin-memory,keyedbyrelationandpagerange.When inPostgreSQL. datachanges,thePageserverprovidesamodified-blocksbitmap—a Formassivesnapshotloads,weintroduceaDirect-to-Storage roaringbitmapofpageschangedbetweentwoLSNs—soonlystale ingestionmode.DistributedSparkexecutorsconstructPostgreSQL- pagesarerefreshed.InSection7.4,wedemonstrateDirectAccessis compliantpagefilesandwritethemdirectlytotheobjectstorage, efficientforthemajorityofanalyticalworkloadswithoutrequiring sendingonlymetadatarecordsthroughLakebasecompute.This aseparatepersistedcolumnarcopy. 4393 Time (hour) emit putrats etupmoc 59p Lakebase without warm pool 50000 10000 5000 1000 500 100 200 300 400 500 600 700 Elapsed Time (minutes) Figure9:P95Computestartuptime(ms),y-axisisinlog- scale. 7 EVALUATION WeevaluateLakebaseacrossthecoreworkloaddimensionstar- getedbythesystemdesign.Wefirstmeasuretheperformanceof branchingandelasticautoscaling,whicharecriticalforagentic workloads.WethenevaluatethecoreOLTPperformanceandthe benefitsofLakehouseintegration. 7.1 BranchingPerformance BranchingonLakebaseisalmostinstantaneous.Itisa𝑂(1)meta- dataoperationthatwritesasingleremotefilerecordingthenew timelineidentifiers,seedetailsinSection4.2.Branchrestoresimply attachesthecomputeprimarytoaprevioustimeline. Computestartupperformanceiscriticalforagenticworkloads. Lakebaseconsistentlyachievessub-secondstartuptimes.Weshow the95thpercentilecomputestartupinmillisecondsobservedin productioninFigure9.Thestartuptimeisconsistentlylowerthan 500ms.ThisisbecausetheLakebasemanagermaintainsawarm pool of compute VMs that are readily available to spin up new computes.Also,computestartupdoesnotperformcrashrecovery. PostgreSQLstartsupwiththeredoLSNsettothelastrecordLSN ingestedonthePageserver.ItdoesnotwaitforPStocatchupto thelatestofSK. Thecomputestartuptimebreaksdownintofoursteps.Starting acomputefirstrequestsabasebackupfromthePageserver.The basebackupisatarballthatcontainsallthemetadatarequiredto startcompute.Thistypicallyonlytakes100ms.Next,itsyncsall SafekeeperstoensureSKreplicasareup-to-date.Thisalsoclaims thecurrentcomputeasthesoleprimarytopreventsplit-brainsce- narios. Syncing SKs onlytakes 5ms since failuresare rare and writesarereplicatedtoallSKreplicasinnormalcases.Then,com- putestartsthecomputeinstancethattakes150ms.Thelaststepis toconfigurecomputewhichtakeslessthan5ms. Incontrast,withoutawarmpool,startinganewcomputetakes uptoseveralminutes,andthetaillatencycanreachhours.Wehave observedthatthecloudprovidermaysometimestakealongtime toprovisionanewVMduetovariousreasons. SPQ tnuoc UPC CPU Target QPS Actual QPS 12500 8 10000 6 7500 4 5000 2 2500 0 0 0 100 200 300 Figure10:Computeautoscaling. 7.2 AutoscalingPerformance Todemonstratetheautoscalingdimensions,weextractedawork- loadfromastocktradingapplicationinproduction.Theworkload exhibitsadiurnalpatternwheretheworkloadpeaksduringthe dayandstayslowwhenthemarketcloses.Weuseanopen-world simulationthatissuesthetargetQPStothedatabase.Thecompute isconfiguredwithaminimumCPUof1andamaximumCPUof7. Initially,thedatabaseloadislowandthecomputeuses1CPU. Whentheapplicationdrivesahigherloadtothesystem,theau- toscalingagentonthecomputedetectsanincreaseonCPUusage andassigns3moreCPUs.Scalingoperationsdonotinterferewith thecustomerworkload,asobservedintheactualQPSinFigure10. At44minutes,whenthemarketopensup,theapplicationsendsa surgeofqueriestothedatabasefrom32to10Kqueriespersecond. TheestimatedworkingsetsizealsoexceedsthecurrentLFCsize. TheautoscalingagentobservesahighCPUusageandtheLFC hitrateislessthan30%.Itreactspromptlyanddirectlyincreases theavailableCPUcounttothemaxCPUcountspecifiedbythe compute.ThecomputeLFCalsoscalesupwiththeCPUsize. Duringtheday,theworkloadfluctuates,andtheagentcontinu- ouslyadjuststheavailableCPUbasedontheload.Theavailable CPUcountstabilizesaround6CPUs.ItincreasestheavailableCPU countto7(5)astheworkloadtemporarilyincreases(decreases) itsload.Throughouttheentireexperiment,theactualQPSalmost matchesthetargetQPS.Thisdemonstratesthattheautoscaling agentscalescomputesizeupanddownpromptlytosustainthe databaseload.Whentheapplicationisidleforaprolongedperiod oftime(5minutesbydefault),thecomputeisshutdown. Wealsoperformthesameexperimentwitha7-CPUfixed-size compute.Thequeryresponsetimeoftheautoscalingcomputeis onlyslightlyhigher,asthefixed-sizecomputebenefitsfromalarger LFCupfrontandincursfewercachemisses.Oncetheworkloadsta- bilizes,thelatencybecomescomparable.Theautoscalingcompute usesfewerCPU-hoursoverall:itrunsatreducedcapacityduring low-loadperiodsandshutsdownentirelywhenidle,whereasthe fixed-sizecomputeconsumesitsfullallocationcontinuously. 7.3 OLTPPerformance ToevaluateLakebaseinOLTPworkloads,wecompareitagainst referencesystemsusingtheHammerDBTPROC-Cbenchmark.The 4394 Table1:PeakHammerDBTPROC-CNOPM(x1000). Table2:Heap-writetimespeedupoverCOPY. Tier(vCPU) Gen-1 Gen-2 Lakebase Size 5GB 10GB 50GB 100GB 500GB 1TB 1 — 9.0(1.0×) 23.3(2.6×) DTS 2.6× 3.4× 6.2× 7.9× 31.3× 73.3× 4 92.6(1.0×) 61.7(0.7×) 86.8(1.0×) 16 118.3(1.0×) 265.7(2.3×) 331.3(2.8×) 24 96.8(1.0×) 407.5(4.2×) 515.6(5.3×) ∗Gen-1hasno24vCPUtier;thenext-available32vCPUconfigurationisused. firstcomparisoniswithacanonicalsecond-generation,compute- storage-separateddatabase(Gen-2).Tomakethecomparisoneq- uitableondurability,wealsocomparewithafirst-generationthat runsPostgreSQLonamulti-AZreplicateddisk(Gen-1),whichadds synchronouscross-AZreplicationoncommit.Wefocusoncached scenariosinwhichtheentireTPROC-CworkingsetfitsinDRAM. Figure11:TPC-HofLakebasevsLakehouse//RTw/Direct Weprovisionfourhardwaretiers:1,4,16,and24vCPUs.Weuse AccessonLakebasestorage. 16warehousespervCPU.Eachvirtualuseraccessesallwarehouses. Wesweepthevirtualusercountoverpowersoftwofrom1to512. WereportthethroughputasthenumberofNewOrdertransactions computenode.Asaresult,Lakebasegeneratessubstantiallylower perminute(NOPM)subjecttoap95NewOrderlatencyboundof WALvolume. 20ms.Table1reportspeakNOPMforeachtier,subjecttoap95 NewOrderlatencyboundof20ms.Thethroughputisnormalizedto 7.4 PerformancefromLakehouseIntegration Gen-1.ThefirsttableentryisomittedbecausetheGen-1provider doesnotoffera1vCPUconfiguration.Similarly,theproviderdoes TheconventionalCOPYpathserializesingestionthroughasingle notsupporta24vCPUtierforGen-1,soweusethenextavailable PostgreSQL writer. Direct-to-Storage (DTS) eliminates this bot- 32vCPUconfigurationinstead,withthesame384warehousesas tleneck.SparkexecutorswritePostgreSQL-compliantheappages Gen-2andLakebaseat24vCPUforcomparability. directlytoobjectstorageinparallel.Table2showsthespeedupof Wereportper-vCPUthroughputbecausecomputecostdomi- DTStowritea1-KBrowtablewithmixedtextandintegercolumns natesoverallservicecostintypicaldeployments,makingitaproxy intocompute.Withhorizontalscaling,DTSheap-writetimeyields forcostefficiency.Forexample,anAWSEC2R8gd.4xlargecom- speedupsupto73.3×at1TB. puteinstancecosts∼$1.18/hrondemand,whereasretaining10GB WeuseTPC-HtoevaluateDirectAccessandcompareitwith onAWSS3Standardcosts∼$0.0003/hr—over3ordersofmagni- Lakebase.Thescalefactoris10.WeareusingLakehouse//RTwith tudelower—andper-request(PUT/GET)andcompaction-tiering DirectAccesstothesameLakebasestoragewiththesamehardware feesremainsmallrelativetocomputeevenunderheavyingestion. resourcesasLakebase. Wecompareagainstrepresentativefirst-andsecond-generation Figure11reportstheperformanceofDirectAccessontheTPC-H archetypes(Gen-1andGen-2)ratherthaneachindividualcommer- benchmark.Overall,DirectAccessreducestotalexecutiontimeby cialoffering. 10×andimprovesthegeomeanquerylatencyby3×relativetoPost- Lakebase achieves throughput comparable to or higher than greSQL.Theseimprovementsstemfromseveralfactors.First,the Gen-2acrossalltiers.At1vCPU,Lakebasedelivers2.6×higher SIMD-acceleratedparserandvectorizedexecutionengineeliminate throughputthanGen-2.Atthisscale,Gen-2’sstoragefan-outcon- muchoftheoverheadassociatedwithPostgreSQL’svolcano-style sumesasubstantialfractionoftheavailablecore,whereasLakebase tuple-at-a-timeprocessing.Second,columnarexecutionimproves streamsWALasasinglequorum-replicatedwrite,leavingmore theefficiencyofanalyticaloperators,particularlyjoinsandaggrega- CPUcapacityavailablefortransactionprocessing.At24vCPU, tions.Finally,DirectAccessemploysananalyticalqueryoptimizer Lakebasesustains26%higherthroughputthanGen-2whilemain- thatfrequentlygeneratesmoreefficientexecutionplans. tainingp95latencybelow20ms.Attheintermediate4and16vCPU Atthequerylevel,weobservesubstantialspeedupsforaggregation- tiers,LakebasestaysaheadofGen-2by22–43%. andjoin-intensiveworkloads.Q1achievesan11×speedup,primar- ComparedtoGen-1,Lakebaseachievesupto5.3×higherthrough- ilyduetomoreefficientparallelaggregation.PostgreSQLincurs putat24vCPU.Atthesmallest4vCPUtierthetwoareonpar,as additional overhead because parallel execution is implemented neithersaturatesthestoragepathatthisscale;thegapwidenswith usingmultipleprocesses,whereasDirectAccessusesthreads.In corecount.Gen-1doesnotscaletothethroughputlevelsreached general,querieswithalargernumberofjoinsandaggregations byLakebasebecauseadditionalcorescontendforthesamestorage benefitmorefromvectorizedcolumnarexecution.Forexample, I/Opath,ratherthanbenefitingfromtheparallelismprovidedby Q18isnearly90×fasterunderDirectAccess. SafekeepersandPageservers.Furthermore,Gen-1reliesonfull- Q17 illustrates the importance of query optimization. Direct page-imageWALrecordstoensuredurability,whereasLakebase Accessachievesa19×speedupbyconvertingthesubqueryintoa offloadspagematerializationtoS3-backedPageserversoutsidethe join-basedplan.Incontrast,PostgreSQLgeneratesasuboptimal 4395 planthatrepeatedlyevaluatesthesubplan,resultinginsignificantly separatescomputefromdistributedstorage.Auroradynamically higherexecutioncosts. adjustscapacityinresponsetoworkloadchangesandenablesfast NotallqueriesbenefitfromDirectAccess.Q8andQ19areslower scale-up/scale-downandpay-for-what-you-usebilling.Elsewhere, becausethecurrentimplementationsupportsonlysequentialscans. therearedescriptionsofreactiveandproactivetechniques[36,39, Bothqueriesbenefitsubstantiallyfromindexnested-loopjoins, 42].Someusestatisticalmodels[16],whileothersusemachine which are available in PostgreSQL but not yet implemented in learningmodels[36]topredicttheresourceusage.Lakebasescales DirectAccess. computeswithfractionsofaCPUandmemorywithnodowntime. Underaconcurrent400QPSOLTPworkload,DirectAccessscans TheautoscalingagentmonitorscomputeCPUusageandworking slowdownby1.76×duetocacheinvalidation.However,Direct setsize.Itscalesupcomputetosustainperformanceduringpeak Access never affects write latency on the primary since it runs trafficandscalestozerowhencomputeisidle. outsidethecompute. Clusterresourcemanagement:Clusterresourcemanagement hasbeenextensivelystudied[12,45,47].Recentworkaddresses 8 RELATEDWORK oversubscription[10],workloadforecasting[19],andhierarchical allocation[30].LakebaseoverprovisionsVMsinwarmpoolsand Separationofstoragefromprocessing:First-generationdata- usesanMLmodeltopredictclusterdemandbasedonhistorical basesystemssuchasMySQL[38],PostgreSQL[4],andOracle[3] patterns,enablingfastcomputestartup. tightlycouplecomputeandstoragewithinasinglemachine.Second- generationsystems—includingAurora[46],Socrates[8],AlloyDB[1], 9 CONCLUSION SolarDB [51], Taurus [18], and Tell [32]—separate storage from computeinternally[23],improvingelasticityandavailability.Po- ThispaperpresentedLakebase,athird-generationtransactional larDBserverless[50]scalesupseamlesslyviatransactionmigra- database architecture that separates compute from storage and tionandprovideslow-latencystronglyconsistentreadsonprimary persistsalldatainopenPostgreSQLpageformatoncloudobject andsecondarynodes[48].SnowflakeUnistore[5]addsOLTPinto storage.Byexternalizingstorageinopenformats,Lakebaseen- Snowflakewarehousesviaaproprietaryrowstore.However,their ablesmulti-engineaccessandsituatesOLTPdirectlyalongsidethe storage formats remain proprietary and data is accessible only Lakehouse,unifyingoperationalandanalyticalworkflows.Thear- throughtheprimarydatabaseengine.MicrosoftFabric[2]stores chitectureleveragescloudobjectstoragefordurability,astoragehi- datainOneLakeasDeltatableswhiletheOLTPengineformat erarchyforperformanceandavailability,andconsensus-replicated remainsproprietary. Safekeepersforwritecorrectness.Autoscaling,scale-to-zero,auto- Lakebaserepresentsathird-generationarchitecture:itexternal- matedfailover,andbuilt-inbranchingreduceoperationalcomplex- izesallstoragetocloudobjectstorageinopenPostgreSQLpage itycomparedtotraditionaldatabasedeployments.Theseproperties format,enablingmulti-engineaccessandremovingstructuralven- areparticularlyrelevantforagenticworkloadsthatrequireinstant dorlock-in.WALredoisoffloadedtodistributedPageservers,and clones,sub-secondstartup,andephemeralcompute.Together,these astoragehierarchyprovidesperformanceandavailability.Lake- capabilitiesmakeLakebaseanagent-readytransactionaldatabase. basefurthersupportssub-secondcomputestartupandzero-copy ProductiondeploymentsshowLakebasesustainingdeepbranching branchingforagenticworkloads. patternsandrapidexperimentationatscale.Atthetimeofwriting, LSM-treedatastores:LSM-treedatastoresoptimizeforwrite- Lakebaseisthefastest-adoptedproductinDatabrickshistory,cre- heavyworkloads[15,20,21,25,27,34,43].Chenetal.[35]survey atingandmanagingmorethan10milliondatabasesdaily.Lakebase alternative designs. Key implementations include LevelDB [24] reflectswhatatransactionaldatabaselookslikewhendesignedfor andRocksDB[20],whichbufferwritesinmemoryandflushto today’scloudinfrastructure,wherestorageisdurableandinexpen- immutableon-diskSSTables.Alternativecompactionstrategies[17, sive,computeiselastic,anddataopennessisarequirement. 27,40]tradeoffread,write,andspaceamplification.WiscKey[33] separateskeysfromvaluestoreducecompactioncost. ACKNOWLEDGMENTS Lakebase’sPageserverusesatwo-dimensionalLSM-treestruc- Wethankthemanyengineers,managers,andproductteamsacross tureindexedbybothpagekeyandLSN.ItbuffersWALrecords DatabricksandNeonwhodesigned,built,andoperateLakebase,as inmemory,flushesthemasimmutablelayerfiles,anduploadsall wellastheopen-sourceNeondatabasecommunitywhosecontribu- filestoobjectstorageforrecovery.Backgroundcompactionreduces theWALredochainforGetPagerequests,andgarbagecollection tionsthisworkbuildsupon.Wearealsogratefultoouranonymous reviewersandshepherdfortheirthoughtfulfeedback,whichsub- reclaimsdatabeyondthePITRwindow. stantiallyimprovedthispaper. MicroVMandautoscaling:Thepopularityofserverlessapplica- tionsinthecloudhasinspiritednovelMicroVMsystemssuchas Firecraker[6],whichaimedatimprovingisolation,provisioning REFERENCES performance,anddensityforserverlesscontainerizedapplications. [1] GoogleInc.2026. AlloyDB:100%PostgreSQL-compatibleDatabasethatRuns NeonVMisonesuchMicroVMsystemwithsimilargoals,withthe Anywhere.GoogleInc. https://cloud.google.com/products/alloydb [2] MicrosoftInc.2026. MicrosoftFabric. MicrosoftInc. https://www.microsoft. addedemphasisonsupportingresourceautoscaling. com/enus/microsoft-fabric Moderndatasystemsscaletheirresourcesondemandbasedon [3] Oracle.2026.Oracle.Oracle. [4] ThePostgreSQLGlobalDevelopmentGroup.2026.PostgreSQL:TheWorld’sMost theloadchanges[16,22,28,29,44].AmazonAuroraServerless[11] AdvancedOpenSourceRelationalDatabase.ThePostgreSQLGlobalDevelopment implementsanon-demand,verticallyelasticcomputelayerthat Group. 4396 [5] SnowflakeInc.2026.SnowflakeUnistore.SnowflakeInc. https://www.snowflake. 2017,8thBiennialConferenceonInnovativeDataSystemsResearch,Chaminade, com/en/product/features/unistore/ CA,USA,January8-11,2017,OnlineProceedings(Chaminade,California,USA). [6] AlexandruAgache,MarcBrooker,AndreeaIordache,MarcLiguori,RolfNeuge- www.cidrdb.org,Chaminade,California,USA.http://cidrdb.org/cidr2017/papers/ bauer,PhilPiwonka,andJörgPopa.2020.Firecracker:LightweightVirtualization p82-dong-cidr17.pdf forServerlessApplications.In17thUSENIXSymposiumonNetworkedSystems [21] RobertEscriva.2020. HyperLevelDB. HyperDex. https://github.com/rescrv/ DesignandImplementation(NSDI).419–434. HyperLevelDB [7] AmazonWebServices.2021.LaunchWindowsfasteronEC2.https://aws.amazon. [22] GuilhermeGalante,LuisCarlosErpenDeBona,AntonioRobertoMury,Bruno com/blogs/modernizing-with-aws/launch-windows-faster-on-ec2/. Accessed Schulze,andRodrigodaRosaRighi.2016.AnAnalysisofPublicCloudsElasticity November17,2025. intheExecutionofScientificApplications:aSurvey.JournalofGridComputing [8] PanagiotisAntonopoulos,AlexBudovski,CristianDiaconu,AlejandroHernan- 14,2(2016),193–216. https://doi.org/10.1007/s10723-016-9361-3 dezSaenz,JackHu,HanumaKodavalla,DonaldKossmann,SandeepLingam, [23] ShahramGhandeharizadeh,PhilipA.Bernstein,DhrubaBorthakur,Haoyu Umar Farooq Minhas, Naveen Prakash, Vijendra Purohit, Hugh Qu, Chai- Huang,JaiMenon,andSumitPuri.2022.DisaggregatedDatabaseManagement tanyaSreenivasRavella,KrystynaReisteter,SheetalShrotri,DixinTang,and Systems.InPerformanceEvaluationandBenchmarking:14thTPCTechnologyCon- VikramWakade.2019.Socrates:TheNewSQLServerintheCloud.InProceed- ference,TPCTC2022,Sydney,NSW,Australia,September5,2022,RevisedSelected ingsofthe2019InternationalConferenceonManagementofData(Amsterdam, Papers(Sydney,NSW,Australia).Springer-Verlag,Berlin,Heidelberg,33–48. Netherlands)(SIGMOD’19).AssociationforComputingMachinery,NewYork, https://doi.org/10.1007/978-3-031-29576-8_3 NY,USA,1743–1756. https://doi.org/10.1145/3299869.3314047 [24] SanjayGhemawatandJeffDean.2020.LevelDB.Google. https://github.com/ [9] MichaelArmbrust,AliGhodsi,ReynoldXin,andMateiZaharia.2021. Lake- google/leveldb house:ANewGenerationofOpenPlatformsthatUnifyDataWarehousingand [25] GuyGolan-Gueta,EdwardBortnikov,EshcarHillel,andIditKeidar.2015.Scaling AdvancedAnalytics.InProceedingsofthe11thAnnualConferenceonInnovative ConcurrentLog-StructuredDataStores.InProceedingsoftheTenthEuropean DataSystemsResearch(CIDR2021).Online. https://www.cidrdb.org/cidr2021/ ConferenceonComputerSystems(Bordeaux,France)(EuroSys’15).Association papers/cidr2021_paper17.pdf forComputingMachinery,NewYork,NY,USA,Article32,14pages. https: [10] PankajArora,SurajitChaudhuri,SudiptoDas,JunfengDong,CyrilGeorge,Ajay //doi.org/10.1145/2741948.2741973 Kalhan,ArndChristianKönig,WillisLang,ChangsongLi,FengLi,JiaqiLiu, [26] GDHeld,MRStonebraker,andEugeneWong.1975.INGRES:arelationaldata LukasM.Maas,AkshayMata,IshaiMenache,JustinMoeller,VivekNarasayya, basesystem.InProceedingsoftheMay19-22,1975,nationalcomputerconference MatthaiosOlma,MorganOslake,ElnazRezai,YiShan,ManojSyamala,ShizeXu, andexposition.409–416. andVasileiosZois.2023.FlexibleResourceAllocationforRelationalDatabase- [27] HaoyuHuangandShahramGhandeharizadeh.2021.Nova-LSM:ADistributed, as-a-Service.Proc.VLDBEndow.16,13(Sept.2023),4202–4215. https://doi.org/ Component-basedLSM-treeKey-valueStore.InProceedingsofthe2021In- 10.14778/3625054.3625058 ternationalConferenceonManagementofData(Virtualevent,China)(SIG- [11] BradleyBarnhart,MarcBrooker,DaniilChinenkov,TonyHooper,JihounIm, MOD’21).AssociationforComputingMachinery,NewYork,NY,USA. https: PrakashChandraJha,TimKraska,AshokKurakula,AlexeyKuznetsov,Grant //doi.org/10.1145/3448016.3457297 McAlister,ArjunMuthukrishnan,AravinthanNarayanan,DouglasTerry,Bhuvan [28] AbdulR.Hummaida,NormanW.Paton,andRizosSakellariou.2016.Adaptation Urgaonkar,andJiamingYan.2024.ResourceManagementinAuroraServerless. incloudresourceconfiguration:asurvey.JournalofCloudComputing:Advances, Proc.VLDBEndow.17,12(Aug.2024),4038–4050. https://doi.org/10.14778/ SystemsandApplications5,1(2016),7.https://doi.org/10.1186/s13677-016-0057-9 3685800.3685825 [29] RongKang,YanbinChen,YeLiu,FuxinJiang,QingshuoLi,MiaoMa,JianLiu, [12] BrendanBurns,BrianGrant,DavidOppenheimer,EricBrewer,andJohnWilkes. GuangliangZhao,TieyingZhang,JianjunChen,andLeiZhang.2025.ABase: 2016.Borg,Omega,andKubernetes.Commun.ACM59,5(April2016),50–57. theMulti-TenantNoSQLServerlessDatabaseforDiverseandDynamicWork- https://doi.org/10.1145/2890784 loadsinLarge-scaleCloudEnvironments.InCompanionofthe2025Interna- [13] DonaldDChamberlin,MortonMAstrahan,MichaelWBlasgen,JamesNGray, tionalConferenceonManagementofData(Berlin,Germany)(SIGMOD/PODS WFrankKing,BruceGLindsay,RaymondLorie,JamesWMehl,ThomasGPrice, ’25).AssociationforComputingMachinery,NewYork,NY,USA,471–484. FrancoPutzolu,etal.1981. AhistoryandevaluationofSystemR. Commun. https://doi.org/10.1145/3722212.3724426 ACM24,10(1981),632–646. [30] JiYouLi,JiachiZhang,WenchaoZhou,YuhangLiu,ShuaiZhang,Zhuoming [14] AudreyCheng,ShuLiu,MelissaPan,ZhifeiLi,BowenWang,AlexKrentsel,Tian Xue,DingXu,HuaFan,FangyuanZhou,andFeifeiLi.2023.Eigen:End-to-End Xia,MertCemri,JongseokPark,ShuoYang,JeffChen,LakshyaAgrawal,Aditya ResourceOptimizationforLarge-ScaleDatabasesontheCloud. Proc.VLDB Desai,JiarongXing,KoushikSen,MateiZaharia,andIonStoica.2025.Barbarians Endow.16,12(Aug.2023),3795–3807. https://doi.org/10.14778/3611540.3611565 attheGate:HowAIisUpendingSystemsResearch. arXiv:2510.06189[cs.AI] [31] NongLi,ShoumikPalkar,ShantHovsepian,MostafaMokhtar,andReynoldXin. https://arxiv.org/abs/2510.06189 2026.IntroducingLakehouse//RT:Real-TimePerformanceontheUnifiedLakehouse. [15] YifanDai,YienXu,AishwaryaGanesan,RamnatthanAlagappan,BrianKroth, [32] SimonLoesing,MarkusPilman,ThomasEtter,andDonaldKossmann.2015.On AndreaArpaci-Dusseau,andRemziArpaci-Dusseau.2020. FromWiscKeyto theDesignandScalabilityofDistributedShared-DataDatabases.InProceedings Bourbon:ALearnedIndexforLog-StructuredMergeTrees.In14thUSENIX ofthe2015ACMSIGMODInternationalConferenceonManagementofData(Mel- SymposiumonOperatingSystemsDesignandImplementation(OSDI20).USENIX bourne,Victoria,Australia)(SIGMOD’15).AssociationforComputingMachinery, Association,155–171. https://www.usenix.org/conference/osdi20/presentation/ NewYork,NY,USA,663–676. https://doi.org/10.1145/2723372.2751519 dai [33] LanyueLu,ThanumalayanSankaranarayanaPillai,AndreaC.Arpaci-Dusseau, [16] SudiptoDas,FengLi,VivekR.Narasayya,andArndChristianKönig.2016. andRemziH.Arpaci-Dusseau.2016. WiscKey:SeparatingKeysfromVal- AutomatedDemand-drivenResourceScalinginRelationalDatabase-as-a-Service. uesinSSD-consciousStorage.In14thUSENIXConferenceonFileandStor- InProceedingsofthe2016InternationalConferenceonManagementofData(San ageTechnologies(FAST16).USENIXAssociation,SantaClara,CA,133–148. Francisco,California,USA)(SIGMOD’16).AssociationforComputingMachinery, https://www.usenix.org/conference/fast16/technical-sessions/presentation/lu NewYork,NY,USA,1923–1934. https://doi.org/10.1145/2882903.2903733 [34] ChenLuoandMichaelJ.Carey.2020.BreakingdownMemoryWalls:Adaptive [17] NivDayanandStratosIdreos.2018.Dostoevsky:BetterSpace-TimeTrade-Offs MemoryManagementinLSM-BasedStorageSystems.Proc.VLDBEndow.14,3 forLSM-TreeBasedKey-ValueStoresviaAdaptiveRemovalofSuperfluous (Nov.2020),241–254. Merging.InProceedingsofthe2018InternationalConferenceonManagementof [35] ChenLuoandMichaelJ.Carey.2020.LSM-basedStorageTechniques:ASurvey. Data(Houston,TX,USA)(SIGMOD’18).AssociationforComputingMachinery, TheVLDBJournal29,1(2020),393–418. https://doi.org/10.1007/s00778-019- NewYork,NY,USA,505–520. https://doi.org/10.1145/3183713.3196927 00555-y [18] AlexDepoutovitch,ChongChen,JinChen,PaulLarson,ShuLin,JackNg,Wenlin [36] ChenghaoLyu,QiFan,FeiSong,ArnabSinha,YanleiDiao,WeiChen,LiMa,Yihui Cui,QiangLiu,WeiHuang,YongXiao,andYongjunHe.2020.TaurusDatabase: Feng,YaliangLi,KaiZeng,andJingrenZhou.2022.Fine-grainedmodelingand HowtoBeFast,Available,andFrugalintheCloud.InProceedingsofthe2020 optimizationforintelligentresourcemanagementinbigdataprocessing.Proc. ACMSIGMODInternationalConferenceonManagementofData(Portland,OR, VLDBEndow.15,11(July2022),3098–3111. https://doi.org/10.14778/3551793. USA)(SIGMOD’20).AssociationforComputingMachinery,NewYork,NY,USA, 3551855 1463–1478. https://doi.org/10.1145/3318464.3386129 [37] DiegoOngaroandJohnOusterhout.2014.Insearchofanunderstandableconsen- [19] Yanlei Diao, Dominik Horn, Andreas Kipf, Oleksandr Shchur, Ines Benito, susalgorithm.InProceedingsofthe2014USENIXConferenceonUSENIXAnnual WenjianDong,DavidePagano,PascalPfeil,VikramNathan,Balakrishnan TechnicalConference(Philadelphia,PA)(USENIXATC’14).USENIXAssociation, Narayanaswamy,andTimKraska.2024. ForecastingAlgorithmsforIntelli- USA,305–320. gentResourceScaling:AnExperimentalAnalysis.InProceedingsofthe2024 [38] Oracle.2026.MySQL. ACMSymposiumonCloudComputing(Redmond,WA,USA)(SoCC’24).As- [39] OlgaPoppe,QunGuo,WillisLang,PankajArora,MorganOslake,ShizeXu, sociationforComputingMachinery,NewYork,NY,USA,126–143. https: andAjayKalhan.2022.Moneyball:proactiveauto-scalinginMicrosoftAzure //doi.org/10.1145/3698038.3698564 SQLdatabaseserverless.Proc.VLDBEndow.15,6(Feb.2022),1279–1287. https: [20] SiyingDong,MarkCallaghan,LeonidasGalanis,DhrubaBorthakur,TonySavor, //doi.org/10.14778/3514061.3514073 andMichaelStrum.2017.OptimizingSpaceAmplificationinRocksDB.InCIDR 4397 [40] PandianRaju,RohanKadekodi,VijayChidambaram,andIttaiAbraham.2017. (SantaClara,California)(SOCC’13).AssociationforComputingMachinery,New PebblesDB:BuildingKey-ValueStoresUsingFragmentedLog-StructuredMerge York,NY,USA,Article5,16pages. https://doi.org/10.1145/2523616.2523633 Trees.InProceedingsofthe26thSymposiumonOperatingSystemsPrinciples [46] AlexandreVerbitski,AnuragGupta,DebanjanSaha,MuraliBrahmadesam, (Shanghai,China)(SOSP’17).AssociationforComputingMachinery,NewYork, KamalGupta,RamanMittal,SaileshKrishnamurthy,SandorMaurice,Ten- NY,USA,497–514. https://doi.org/10.1145/3132747.3132765 giz Kharatishvili, and Xiaofeng Bao. 2017. Amazon Aurora: Design Con- [41] MichaelReeves,DaveJingTian,AntonioBianchi,andZ.B˜erkayCelik.2021. siderationsforHighThroughputCloud-NativeRelationalDatabases.InPro- TowardsImprovingContainerSecuritybyPreventingRuntimeEscapes.In2021 ceedingsofthe2017ACMInternationalConferenceonManagementofData IEEESecureDevelopmentConference(SecDev).IEEE,38–46. https://doi.org/10. (Chicago,Illinois,USA)(SIGMOD’17).ACM,NewYork,NY,USA,1041–1052. 1109/SecDev51306.2021.00022 https://doi.org/10.1145/3035918.3056101 [42] KrzysztofRzadca,PawelFindeisen,JacekSwiderski,PrzemyslawZych,Przemys- [47] AbhishekVerma,LuisPedrosa,MadhukarKorupolu,DavidOppenheimer,Eric lawBroniek,JarekKusmierek,PawelNowak,BeataStrack,PiotrWitusowski, Tune,andJohnWilkes.2015.Large-scaleclustermanagementatGooglewith StevenHand,andJohnWilkes.2020.Autopilot:workloadautoscalingatGoogle. Borg.InProceedingsoftheTenthEuropeanConferenceonComputerSystems InProceedingsoftheFifteenthEuropeanConferenceonComputerSystems(Herak- (Bordeaux,France)(EuroSys’15).AssociationforComputingMachinery,New lion,Greece)(EuroSys’20).AssociationforComputingMachinery,NewYork, York,NY,USA,Article18,17pages. https://doi.org/10.1145/2741948.2741964 NY,USA,Article16,16pages. https://doi.org/10.1145/3342195.3387524 [48] XinjunYang,YingqiangZhang,HaoChen,ChuanSun,FeifeiLi,andWenchao [43] RussellSearsandRaghuRamakrishnan.2012.BLSM:AGeneralPurposeLog Zhou.2023.PolarDB-SCC:ACloud-NativeDatabaseEnsuringLowLatencyfor StructuredMergeTree.InProceedingsofthe2012ACMSIGMODInternational StronglyConsistentReads.ProceedingsoftheVLDBEndowment16,12(2023), ConferenceonManagementofData(Scottsdale,Arizona,USA)(SIGMOD’12). 3754–3767. https://doi.org/10.14778/3611540.3611562 AssociationforComputingMachinery,NewYork,NY,USA,217–228. https: [49] MateiZaharia,ReynoldS.Xin,PatrickWendell,TathagataDas,MichaelArmbrust, //doi.org/10.1145/2213836.2213862 AnkurDave,XiangruiMeng,JoshRosen,ShivaramVenkataraman,MichaelJ. [44] AhmedA.Soror,UmarFarooqMinhas,AshrafAboulnaga,KennethSalem, Franklin,AliGhodsi,JosephGonzalez,ScottShenker,andIonStoica.2016. PeterKokosielis,andSunilKamath.2008. Automaticvirtualmachinecon- ApacheSpark:aunifiedengineforbigdataprocessing. Commun.ACM59, figurationfordatabaseworkloads.InProceedingsofthe2008ACMSIGMOD 11(2016),56–65. https://doi.org/10.1145/2934664 InternationalConferenceonManagementofData(Vancouver,Canada)(SIG- [50] Yingqiang Zhang, Xinjun Yang, Hao Chen, Feifei Li, Jiawei Xu, Jie Zhou, MOD’08).AssociationforComputingMachinery,NewYork,NY,USA,953–966. XudongWu,andQiangZhang.2024.TowardsaShared-Storage-BasedServer- https://doi.org/10.1145/1376616.1376711 lessDatabaseAchievingSeamlessScale-UpandReadScale-Out.In2024IEEE [45] VinodKumarVavilapalli,ArunC.Murthy,ChrisDouglas,SharadAgarwal,Ma- 40thInternationalConferenceonDataEngineering(ICDE).5119–5131. https: hadevKonar,RobertEvans,ThomasGraves,JasonLowe,HiteshShah,Siddharth //doi.org/10.1109/ICDE60146.2024.00384 Seth,BikasSaha,CarloCurino,OwenO’Malley,SanjayRadia,BenjaminReed, [51] TaoZhu,ZhuoyueZhao,FeifeiLi,WeiningQian,AoyingZhou,DongXie,Ryan andEricBaldeschwieler.2013. ApacheHadoopYARN:yetanotherresource Stutsman,HainingLi,andHuiqiHu.2019.SolarDB:TowardaShared-Everything negotiator.InProceedingsofthe4thAnnualSymposiumonCloudComputing DatabaseonDistributedLog-StructuredStorage.ACMTrans.Storage15,2,Article 11(June2019),26pages. https://doi.org/10.1145/3318158 4398