Пре пет година, Датабрицкс је сковао термин ‘дата лакехоусе’ да опише нову врсту архитектуре података која комбинује језеро података са складиштем података. Тај термин и архитектура података су сада уобичајени у индустрији података за аналитичка радна оптерећења.
Сада, Датабрицкс поново жели да креира нову категорију са својом Лакебасе услугом, која је данас генерално доступна. Док се дата лакехоусе конструкција бави ОЛАП (онлајн аналитичка обрада) базама података, Лакебасе је све о ОЛТП (онлајн обрада трансакција) и оперативним базама података. Лакебасе услуга је у развоју од јуна 2025. и заснована је на технологији коју је Датабрицкс стекао аквизицијом ПостгреСКЛ добављач базе података Неон. Додатно је побољшан у октобру 2025 набавка Моонцаке-а, који је донео могућности да помогне да се ПостгреСКЛ повеже са форматима података лакехоусе.
Лакебасе је оперативна база података без сервера која представља фундаментално преиспитивање начина на који базе података раде у доба аутономних АИ агената. Рани корисници, укључујући еасиЈет, Хафниа и Варнер Мусиц Гроуп, скраћују време испоруке апликација за 75 до 95%, али дубље архитектонске иновације позиционирају базе података као ефемерну, самоуслужну инфраструктуру коју АИ агенти могу да обезбеде и управљају без људске интервенције.
Ово није само још једна управљана Постгрес услуга. Лакебасе третира оперативне базе података као лагани рачунар за једнократну употребу који ради на језеру података, а не као монолитне системе који захтевају пажљиво планирање капацитета и надзор администратора базе података (ДБА).
"Заиста, да би тренд кодирања вибрације заживео, потребни су вам програмери да верују да заиста могу да креирају нове апликације веома брзо, али вам је такође потребан централни ИТ тим, или ДБА, да се осећате пријатно са цунамијем апликација и база података," Суоснивач Датабрицкс-а Реинолд Ксин рекао је за ВентуреБеат. "Класичне базе података једноставно се неће скалирати до тога јер не могу себи приуштити да ставе ДБА по бази података и по апликацији."
92% бржа испорука: од два месеца до пет дана
Бројеви производње показују непосредан утицај изван визије обезбеђивања агента. Хафниа је смањила време испоруке за апликације спремне за производњу са два месеца на пет дана — или 92% — користећи Лакебасе као трансакциони механизам за њихов интерни оперативни портал. Шпедитер је прешао даље од статичних БИ извештаја на пословне апликације у реалном времену за флоте, комерцијалне и финансијске токове.
ЕасиЈет је консолидовао више од 100 Гит репозиторија у само два и смањио развојне циклусе са девет месеци на четири месеца — смањење од 56% — док је изградио веб-базирано чвориште за управљање приходима на Лакебасе-у како би заменило деценију стару десктоп апликацију и једно од највећих европских застарелих СКЛ Сервер окружења.
Варнер Мусиц Гроуп преноси увид директно у производне системе користећи обједињену основу, док је Куантум Цапитал Гроуп користи за одржавање конзистентних, контролисаних података за идентификацију и процену инвестиција у нафту и гас — елиминишући дуплирање података које је претходно приморало тимове да одржавају више копија у различитим форматима.
Убрзање произилази из елиминације два главна уска грла: клонирања базе података за тестна окружења и одржавања ЕТЛ цевовода за синхронизацију оперативних и аналитичких података.
Техничка архитектура: Зашто ово није само управљан Постгресом
Традиционалне базе података спајају складиштење и рачунарство — организације обезбеђују инстанцу базе података са приложеним складиштем и скалом додавањем више инстанци или складишта. АВС Аурора је иновирала тако што је одвојила ове слојеве користећи власнички складишни простор, али је складиште остало закључано унутар АВС-овог екосистема и није било независно доступно за аналитику.
Лакебасе доводи одвајање складишта и израчунавања до свог логичног закључка стављајући складиште директно у складиште података. Рачунарски слој у суштини ради ванилла ПостгреСКЛ — одржавајући пуну компатибилност са Постгрес екосистемом — али свако уписивање иде у Лакехоусе складиште у форматима које Спарк, Датабрицкс СКЛ и други мотори за анализу могу одмах да траже без ЕТЛ-а.
"Јединствени технички увид је био да језера података раздвајају складиштење од рачунарства, што је било одлично, али морамо да уведемо могућности управљања подацима као што су управљање и управљање трансакцијама у језеро података," Ксин је објаснио. "Ми се заправо не разликујемо толико од концепта Лакехоусе, али градимо лагано, краткотрајно рачунарство за ОЛТП базе података на врху."
Датабрицкс је изградио Лакебасе технологијом коју је добио куповином Неона. Али Ксин је нагласио да је Датабрицкс значајно проширио оригиналне могућности Неона да створи нешто суштински другачије.
"Нису имали пословно искуство, и нису имали скалу у облаку," рекао је Ксин. "Довели смо нову архитектонску идеју Неон тима заједно са робусношћу Датабрицкс инфраструктуре и комбиновали их. Дакле, сада смо направили супер скалабилну платформу."
Од стотина база података до милиона направљених за агентску вештачку интелигенцију
Ксин је изнео визију директно повезану са економијом алата за АИ кодирање која објашњава зашто је Лакебасе конструкција важна изван тренутних случајева употребе. Како трошкови развоја падају, предузећа ће се пребацити са куповине стотина СааС апликација на изградњу милиона интерних апликација по мери.
"Како се цена развоја софтвера смањује, што данас видимо због алата за АИ кодирање, прећи ће се са пролиферације СааС-а у последњих 10 до 15 година на пролиферацију интерног развоја апликација," рекао је Ксин. "Уместо да праве стотине апликација, они ће током времена правити милионе апликација по мери."
Ово ствара немогућ проблем управљања флотом са традиционалним приступима. Не можете унајмити довољно ДБА-а да ручно обезбедите, надгледате и решавате проблеме са хиљадама база података. Ксиново решење: Третирајте само управљање базом података као проблем података, а не као оперативни проблем.
Лакебасе складишти сву телеметрију и метаподатке — перформансе упита, коришћење ресурса, обрасце повезивања, стопе грешака — директно у језеру, где се могу анализирати коришћењем стандардног инжењеринга података и алата за науку о подацима. Уместо да конфигуришу контролне табле у алатима за праћење специфичним за базу података, тимови података траже податке телеметрије помоћу СКЛ-а или их анализирају помоћу модела машинског учења да би идентификовали одступнике и предвидели проблеме.
"Уместо да креирате контролну таблу за сваких 50 или 100 база података, заправо можете погледати графикон да бисте разумели да ли се нешто лоше понаша," Ксин је објаснио. "Управљање базом података ће изгледати веома слично проблему аналитике. Гледате ванредне ситуације, гледате трендове, покушавате да разумете зашто се ствари дешавају. Ово је начин на који управљате у великој мери када агенти креирају и уништавају базе података програмски."
Импликације се протежу и на саме аутономне агенте. Агент вештачке интелигенције који има проблеме са перформансама могао би да упита податке телеметрије да би дијагностиковао проблеме — третирајући операције базе података као само још један аналитички задатак уместо да захтева специјализовано ДБА знање. Управљање базом података постаје нешто што агенти могу сами да ураде користећи исте могућности анализе података које већ имају.
Шта ово значи за тимове за податке предузећа
Лакебасе конструкција сигнализира фундаменталну промену у начину на који предузећа треба да размишљају о оперативним базама података — не као о драгоценој, пажљиво управљаној инфраструктури која захтева специјализоване ДБА, већ као о ефемерним, самоуслужним ресурсима који се програмски скалирају попут рачунарства у облаку.
Ово је битно да ли се аутономни агенти материјализују онолико брзо колико Датабрицкс замишља, јер основни архитектонски принцип — третирање управљања базом података као аналитичког, а не оперативног проблема — мења скупове вештина и структуре тима који су потребни предузећима.
Лидери података треба да обрате пажњу на конвергенцију оперативних и аналитичких података који се дешавају широм индустрије. Када аналитички мотори без ЕТЛ-а могу одмах испитати записе у оперативну базу података, традиционалне границе између трансакционих система и складишта података се замагљују. Ова обједињена архитектура смањује оперативне трошкове одржавања одвојених система, али такође захтева преиспитивање структура тима података изграђених око тих граница.
Када је Лакехоусе лансиран, конкуренти су одбацили концепт пре него што су га сами усвојили. Ксин очекује исту путању за Лакебасе.
"Једноставно има смисла одвојити складиште и израчунати и ставити све складиште у језеро — то омогућава толико могућности и могућности," рекао је.
