Skip to main content

Lakebase: Fully Managed Postgres for the Lakehouse

Summary

  • Operational database innovation: This video introduces Lakebase, a Postgres-compatible OLTP database designed for intelligent applications that eliminates custom ETL pipelines with built-in lakehouse table synchronization.
  • Convergence of analytics and operations: Learn how Lakebase bridges the gap between analytical systems and operational databases, enabling insights from analytics to be integrated directly into operational systems with sub-10ms latency.
  • Simplified infrastructure: Discover how Lakebase enables faster development for both data engineers and application developers while providing production-level concurrency and Postgres compatibility.

Lakebase: Fully Managed Postgres for the Lakehouse

Watch: Lakebase: Fully Managed Postgres for the Lakehouse
Lakebase is a new Postgres-compatible OLTP database designed to support intelligent applications. Lakebase eliminates custom ETL pipelines with built-in lakehouse table synchronization, supports sub-10ms latency for high-throughput workloads, and offers full Postgres compatibility, so you can build applications more quickly.
In this video, you’ll learn how Lakebase enables faster development, production-level concurrency, and simpler operations for data engineers and application developers building modern, data-driven applications. We'll walk through key capabilities, example use cases, and how Lakebase simplifies infrastructure while unlocking new possibilities for AI and analytics.
Here's more to explore:
Databricks named a leader in the 2024 Gartner® Magic Quadrant™for Cloud DBMS: https://www.databricks.com/resources/analyst-paper/databricks-named-leader-by-gartner
An open, unified approach to your data, BI and AI workloads: https://www.databricks.com/product/databricks-sql
See all the product announcements from Data + AI Summit: https://www.databricks.com/events/dataaisummit-2025-announcements

Chapters

FAQs

What problem does Lakebase solve according to this video?

This video addresses the long-standing separation of analytical and operational database systems. Lakebase eliminates the need for custom ETL pipelines by providing built-in synchronization between the lakehouse and an operational database.

How does Lakebase enable sub-10ms latency for applications?

This video explains that Lakebase is an OLTP database designed specifically for high-throughput operational workloads, supporting sub-10ms latencies that enable real-time intelligent applications on top of lakehouse data.

What are the most common agentic use cases?

AI agents benefit greatly from access to real-time operational data, enabling them to answer customer support questions with current inventory, process transactions, and provide up-to-date financial information. Agents excel at automating routine operational tasks by accessing both transaction data for immediate actions and historical analytics for context. The combination of low-latency access and historical context makes agents far more effective for business operations than agents lacking real-time data.

What database architecture handles transactions and analytics on the same data effectively?

Neon's storage-compute separation enables a unified architecture that handles both high-throughput OLTP and analytical queries on the same business data without architectural compromises. The separation allows transaction processing to optimize for low-latency, high-concurrency workloads while analytics can run on isolated compute resources at scale. This approach solves the classic database scaling challenge where monolithic architectures cannot optimize simultaneously for transactional and analytical workloads.

What are the latency characteristics of real-time analytics on operational data?

Real-time analytics on Lakebase-synchronized data achieves sub-second query latency for typical analytical workloads while maintaining microsecond transaction consistency. The direct synchronization between Lakebase and Delta Lake ensures analytical data reflects committed transactions within seconds rather than minutes or hours typical of batch ETL. This freshness enables operational intelligence on data like inventory levels, fraud patterns, and customer interactions that require rapid response.

Full transcript

0:00 Introduction to Lakebase

Hi everybody. Uh my name's uh. Um uh here uh to talk to you about uh Lake Base. Um so first of all, apologies for everybody who signed up for a different session, showed up to the room and found there was magically a completely different name session when they got here. So that was maybe surprise surprise intentional. Um, as you probably saw hopefully in the keynote today, we made some pretty big uh, announcements around the operational database OOLTP uh, market that we're very excited about and we didn't really want to leak that in the program beforehand.
So, we had to give it a slightly different more obfiscated name. So, thank you for signing up for that session. We're not doing that session. Um, we'll be doing a session on lake base. So, if anyone is incredibly disappointed then please, you know, I'll understand but you know like we we'll be talking about something else today. So, yeah. So, Lake Base um so hopefully who saw the keynote um hopefully many of you saw uh what we are looking to do here.
So, I'll go through a little bit more background as to uh how we've been thinking about and why we're doing this uh um uh new product category. I'll go through some more of the specific details about uh what we'll actually uh be delivering. Uh so, first of all, what so what drove the uh the inspiration behind this project? Well, you know, for many of us who've been working in the area of analytics and operational data systems, you know, for years, these have been very siloed.

1:20 The need for convergence

Um, and there's just a much and you know, working with between them has been quite complicated. But, you know, there's a big drive in the industry at the moment to sort of need to bring these use cases closer together. the time from insights from analytics needs to come down from sort of hours and days and weeks to be you know integrated with operational systems so it's you know really quickly available and the you know the recent you know emergence of some of the AI technologies as well have really sort of driven the need to bring these two systems closer together and you know I've talked to I guess so I've been at data bricks about a year and a half now um I pro talked to a couple hundred customers over that time across pretty much all industries a whole range range of different use cases.
You know, this is, you know, this is this trend is consistent across all industries, across all use cases, whether it's for doing personalized recommendations um uh or um workload uh tracking of say clinical trial signoff. We're just consistently seeing the need for having an operational database be close to the uh analytical data. Maybe I'll just go through a couple of like super super canonical examples that we see.
This is probably the most common one. Um you know for uh for customers who have data that there has been curated in the analytical platform through the medallion architecture to get to a gold layer quite often that data now needs to be served to an operational system. You know the days of that just being available for analysts who are working in the um data bricks platform. uh plenty of use cases around that still but very very many of our customers are taking that data and they're moving it into an operational system so that they can serve that data might be customer recommendations product segmentation directly uh in an operational system and so what are some of the characteristics of that right it needs to it needs to be served that data is in an application that's you know often like it might be a point of sale application it might be a web application but it needs super low latency sub 10 millisecond latency Right?
It needs to operate at super high QPS, thousands, tens of thousands of QPS. And we find that many of our customers originally would say, hey, I haven't I've had an analytical data platform for the last few years, but I now really need to think about building that and extending that to be an operational data platform. So the so and for this it's taking data from the lakehouse bringing it into an operational database and then serving it out either directly to an application or often as features uh through uh feature and model serving.
Second uh uh type of uh classic example here is application state. So that analytical data that exists often someone will want to build an application around it that might do something like uh manage signoffs for a workflow. So a good example here, you know, clinical trials, a lot of data is coming from a clinical trial application, but there's a human workflow element that needs to sign off uh reviewing that, handing it on to the next person in the chain.
That's classic database uh capabilities. Um and you know, if you then you know want to build that application today with data bricks or I guess yesterday with data bricks, what did you have to do? You had to go find and provision your own database. You had to set up and manage it. you had to deal with a lot of sort of complex wiring just to get this very basic um uh uh solution up and going. So these are two very common use cases.
So now you got an application you want to store some applications data around that and then sometimes you want to then take that data and then also sync it back to the lakehouse for uh for analytics and you know across those three use cases those patterns we often see people obviously combining them in all all kinds of ways as well but those are these are some of the most uh common things that we see. All right so what challenges do customers have?
So classic challenges I hear from all lots of customers. It's really hard to provision. How do I get this database set up and integrated with my lakehouse once I get it going? Okay, data starts to flow more data starts to flow. Custom pipelines that I built become brittle. Now I need to do five, 10, 20 of these. How do I manage all of that scaling and complexity? And very quickly rather than just providing data to applications, you moving into basically the world of tending and caring for these systems.

5:15 Common customer challenges

And then finally, you know, automation. Uh how can you do this quickly? How can you think of this like much more like you think about development where you can um uh uh manipulate systems easily and think about staging and prod environments, right? And really reduce that uh sort of DevOps workflow. So these are super common uh challenges we see. So today we announced uh lakebase which is a you know fully managed Postgress database built for intelligent applications. three big parts to that.

6:07 Lakebase architecture

Uh Postgress engine, separation of compute and storage, integration with the lakehouse. Uh I'll kind of go through each of these in a little bit more detail. Um so Postgress, first of all, why Postgress? Who actually raise raise your hands who is familiar with Postgress and is already used okay using it in their organization. Okay, that's pretty much pretty much everybody, right? And this this chart really shows it, right? over the last uh decade or so, you know, Postgress has really really emerged as sort of the if not the deacto a standard in very very many organizations, right?
First of all, it's just a really great OLTP engine. Low latency, high performance, has all of the full um semantics you'd expect around an OOLTP engine. uh you know full acid transactions indexes views uh common table expressions triggers all of the all of the normal goodies you'd expect around an OOLTP database but a couple of things that also really set it apart is the rich ecosystem of extensions around it right there's a great community building extensions uh around for geospatial forc for example uh or embeddings uh with uh pg vector um and as well as the extensions there's a really great ecosystem of tools drivers etc.
So it's it's already a database that is hopefully very familiar to you and also the application teams who are in your organization because very often this sort of interesting interface between the analytical team and the application team or the DBA team like how do they talk to each other and often data just disappears over some pipe and that's kind of it right and uh now you know with a postgress database engine that's going to be a very sort of familiar lingua franker for um uh for people so separation compute and storage So um you know and did I think a great job talking about this in the uh keynote um and you know what this really enables is some you know some very very cool things.

7:54 Compute and storage features

So uh traditional database engine storage and compute are very tightly uh coupled together. There has been some innovation on this to do some separation of compute and storage with that some of the cloud vendors have shipped. They've sort of taken it to like one step of separation of compute and storage inside. it's still kind of quite uh kind of locked up in the the sort of the vertical stack. We've taken it a layer further and really separated out uh you know storage ultimately landing in uh object storage, right?
So, uh, data is landing into, uh, object storage, but we've built some very sophisticated layers in between the safekeeper and the page servers, if you want to kind of go read up on that a little bit of the, uh, the technologies that lets us write data very quickly, serve it very fast, but do that in a in in a way that can serve data to uh, like it sort of so data is stored and managed regionally, which means now that compute when compute spins up, we spin compute up in, you know, different zones. and it can spin up and come down pretty quick.
Um um which which makes for very powerful uh decoupled compute and storage. So so you can you with lakebase you can uh scale storage dynamically. You can scale compute up you can scale it down. The first what we're launching in public preview today is what we would call a sort of a provisioned capacity model. So when you provision compute you'll provision a particular size of compute. You can manually scale it up. can manually scale it down and you can turn it off if you want and then bring it back up again later.
So you do get uh uh uh that uh those capabilities to sort of manage the costs. Um this is all running um inside of data bricks infrastructure. So the compute and the storage is inside of data bricks. It's not in your accounts. It's not in your compute accounts. It's not in your storage accounts. It's in data bicks uh infrastructure. So we're sort of managing that stack uh end to end. We've added some also some great capabilities because we have this disagregated compute and storage to handle um high availability and fast recovery.
Uh so um as I mentioned storage is regional uh compute spins up in a particular zone very easily though you can enable high availability which will spin up a uh another compute instance in another zone making that available if if there's a zone failure for example or um some error in the compute stack we can very quickly fail over uh uh to the uh to the secondary. We also optionally let you read from those secondaries.
So very common pattern is drive drive all right traffic to one uh uh endpoint where you connect to and send all your right traffic and you can offload all of your read traffic into scaled out uh secondaries. So super common pattern to really help sort of manage performance and scaling. Um we've also enabled something called point in time recovery and this is again one of those amazing capabilities that we have from uh Neon's technology.
So Lake Base is all built on Neon technology. Uh today we announced the acquisition, you know, just like a month or so ago. We've been working together for uh you know, long long before that. Um and the really cool thing here is, you know, if you want to branch a database, say you wanted to have a test, you got to you got to you've got a production environment and you want to take you want to have a test environment to do that is incredibly painful in traditional databases, right?
It's often you actually have to physically copy schema. you have to physically copy data, set up a dedicated environment, work with it there, care for it, trend it, manage it, you know, shut it down. The really nice thing here is we have leverage something called uh copy on write uh cloning. So we can instantly take that development um that production system. We can instantly clone it at the storage layer and spin up uh a dedicated separate compute instance where you can size it at a smaller size.
So you might have a really big, you know, compute instance running for production. You can spin up a small test environment using that the full copy of the data. It's completely isolated. You can work with it from for test purposes and then shut it down uh when you're finished without impacting your production environment at all. But you can create these things in uh in seconds. Um which is very very cool and uh really helps uh productivity.
Um so all of this is running in uh data bricks uh infrastructure. Um so we've integrated with uh data bricks identity and uh uh authentication. Uh we've integrated with network security features like private link and IP alackles. Um and then uh built in you know around normal other goodies that you want like how do I do cost attribution and modeling. So we have uh billing tags for that uh terraform uh asset bundles uh etc.
Um and then we've also integrated with hopefully you also saw in the keynote data bicks apps. So data bicks apps very many people who build applications at data bricks apps want a small a database that they can use with that and so we've integrated with them as a dedicated uh resource provider uh also uh integrated with the lakehouse. So so this has been uh something we've spent uh you know quite some time uh working through.

12:55 Lakehouse integration

So this is a full Postgress database right and obviously we want to make sure it works super super well uh with uh the lakehouse and one of the first things if you remember those use cases uh that I was uh talking through uh earlier um the most common use cases data is sitting uh in delta and wants to be served to uh an application. So just as a reminder right data when it's in dela is in you know it's in in the lakehouse it's either in dela or iceberg formats most commonly that's a column and a storage format the data is laid out to make it really optimized for aggregations and scans and large you know large queries often covering uh terabytes and even pabytes of data.
The data in an OLTP system is optimized for a different purpose. It's optimized for very low latency highqps read write. So it has a very different format. It's a row based format. So in the first sort of we're going to go on a long journey here as we bring this build this product line out. You know in our first version we've made it super easy to basically sync or copy data from the lakehouse and into uh uh Postgress.
So that's part of the public preview. We also have a private preview to go the other way. So to go from Postgress to uh the lakehouse and what this does is it makes it really easy to go into Unity catalog just with a very few clicks pick a table for example a delta table. From that you can create what we call a sync table and then pick a few options. demoed this super nicely uh in the keynote. You can pick a few options.
Um click go and you have a couple of choices on the type of synchronization you want to do. You might want to do a one-off just batch copy one and done. It'll physically copy everything over. You might want to set it triggered so that data triggers changes on a certain schedule or when you want to uh initiate the um uh the update or continuous and continuous is particularly interesting because you can be now writing data continuously in on the delta side and then we through a pipeline are picking that data up and we'll be moving it over into Postgress. you can write into delta.
We pick up that data and then we sync it across uh continuously over into um uh into postgress and then once it's there you can then use that for you know very fast um uh uh highqps low latency serving either directly to an application uh or we've also integrated with feature and model serving which is a super cool feature as well where you might have the offline features for training in delta. So that table that I talked about at the start could be a classically for example a say a feature table.
It has all of your training data in but when you're actually wanting to use that in production you want to use the same feature spec but you want to do much faster lookups for it as part of your uh solution. So we we tie in um uh nicely with uh with that um the uh so some other integrations I think so unity catalog so you know we wanted to make sure that we had a really great Postgress database but we also wanted to make sure it has really nice integrations uh into Unity catalog.
So you can you can operate and use Postgress database just exactly as a Postgress database right we wanted to make sure we had that full uh ecosystem benefit of the Postgress ecosystem so we didn't really want to compromise uh on that but we also wanted to make sure that if from an analytics world you wanted to operate with it in a consistent way using unity catalog permissioning model etc you can take a database that's uh in postgress you can register into unity catalog and then for anyone who's operating uh in the sort of the unity catalog world.
We'll use lakehouse federation to manage um permissioning and connections and querying uh to the database uh so that it respects the uh UC uh uh permissions model under the covers. This is using uh lakehouse federation. I will just maybe I'll like so this is kind of where we're starting with this. I think over time we'll be able to build some really nice things that actually brings the uh the operational data and the analytical data even closer together.
Today you're still dealing with effectively two tables across two systems. We'll slowly as we started to talk about in the keynote build tighter integration uh between those ideally having both of the query engines able to operate over both formats through a common t definition of a table respecting a consistent unity catalog authorization model. Right? So there's lots of interesting things I think that we can do here that the architecture um uh innovation that we have will uh will enable.
We're starting out with a fairly you know straightforward bring data from into Postgress and serve super fast. Uh we've also as also showed in the demo u is extended the query editor that is in um uh the data bricks user experience today so that you can um connect to that Postgress database. So the way you know the way the database shows up is if you go there's a new compute type. So first of all turn on the public preview.

17:39 User experience and pricing

It's a publicly available. So go into your workspace settings, turn on the public preview. When you then go to the compute tab, you'll be able to select uh you'll see a new type of compute called the database instance. You can create a database instance there. That will give you a full Postgress database. You can then just click a button to like new query it. It'll jump you out to a a new um u uh to the editor which now has a Postgress native version.
So you can use connect directly to the Postgress database. You can run normal uh Postgress SQL. You can browse the Postgress schema um and uh uh and interact with it right there in the uh in the console. You can also of course use all of your favorite Postgress tools if it's psql, dbw weaver, whatever to connect to the database uh that way. Uh as well uh pricing. Quick word on pricing. So h how have we structured pricing for this?
So we wanted to keep it really simple. Um it's a database. So there's two main parts, the storage and the compute. storage. Uh we have a price per GB uh per month. Um you know this is you know super high like the reason we're able to do sub 10 millisecond tens of thousands of QPS is it's very high performance storage. So we cache in disk and in memory uh a lot of the data in order to be able to serve queries as quickly as possible.

18:43 Use cases and limitations

So um storage pricing is around about it depends on region depends on skew is around like sort of the mid30 cents per GB per month. Um so very different than you know object storage pricing right which is often two to three cents right this is high performance uh block storage pricing for a database so that's storage uh and then for compute um we've made the compute as I mentioned earlier it's a provisioned capacity model in our for our first iteration um and the capacity there uh is sized uh up uh in what we call uh capacity units one capacity unit is about 16 GB uh of memory um and then they go up there.
So we have 1 2 4 and 8 in terms of capacity units at scale uh linely. We're kind of giving a sizing in terms of GB as we find that's often the most helpful thing for customers to understand performance profiles because the more you can cache the faster and more consistent your performance will be. Uh and then the final component which is you know optional if you if you want to sync data between uh the lakehouse and lake base or or the other way around uh we use DT pipelines to do that.
These are just normal DT pipelines. They show up as DT pipelines that you can monitor um and inter and interact with to a degree. We're running them and managing them. So, you know, but we do give a certain amount of observability. Um and so we charge just normal uh uh DT pricing uh for when those are being used. Um so where to use like base today? So uh I talked a little bit about some of the classic examples of the use case.

20:39 Customer feedback and partners

So just straight up building applications, right? So you can use this just to build an application directly on uh data bricks. Uh today it is a fully managed postgress database. You can use it directly. uh you can also serve uh uh as I mentioned data and features from the lakehouse through this uh offload uh um you know those queries that you know someone has started to use DBSQL in a way that it's not really intended and you're kind of scratching your head as like what am I going to do when you know the query is taking a second or two and I can't get the quite the QPS that I want now we've made it super easy to provide a um a support for an alternative for that and then of course any data that you have in your application you can bring back to the lakehouse.
So, you might have an order processing application that's been built off of uh uh the uh lake base. Uh and you want to take those orders and sync them back over to the uh lakehouse for historical analysis. Right? One of my favorite parts of the talk is to remind everybody what this is not. Um because um you know this is uh this is an OOLTP database, right? It is not a replacement for DBSQL. It is not a a HTAP system.
It's a it's a classic OOLTP uh database um that has a very different set of characteristics than a data warehouse. There are some overlaps on use cases but they're pretty distinct uh systems. Um for anyone who's been using um one of the early versions of this technology we had uh called online tables. Actually quick show of hands who's aware of or has been using online tables. All right, I could maybe d 10 12 people.
Okay, so online table this was sort of our first um first version of uh sort of experimenting with this uh area. It provided provides a key value store um and it's super super easy to use but with that there's a set of limitations. There's no capacity controls. It's read only. Um you can't do rich querying against it. So what we're recommending everybody to do now if you're using online tables is to move over uh to using lakebas and sync tables. uh leg base is a superset of that uh functionality.
So we're really recommending everybody to start to move over uh now that we're in uh public preview. Uh and also just a reminder if you're using other database systems, Oracle, SQL Server, pick think the list is very long. Um just a reminder that you know this isn't always like moving from one database platform to another is it's sometimes a non-trivial task. The languages are different, the ecosystem around them are different.
So while I think there are lots of opportunities to bring databases in, we don't have any tooling to support or help with that at the moment. So just be aware um if you want to bring an application over that you know there's an element of sort of manual migration work uh to do that. Um so we've been in uh private preview for a while now. Um we've had some great uh customers who uh we've been working with. I put a couple of examples up here of quotes from those.
Um you know Heineken I this was a great example of one of those customers who the conversation just still stays in my mind where you know we're sitting down and the team is saying I I have built this analytical platform but the needs of my business are changing like the operational and transactional systems are needing to come together because I I need to serve data now in real time to a much broader audience not only of humans but of applications.
I I'm now building an operational data platform. my team is no longer an analytical data platform. It now has to become an operational data platform. So, uh classic example there also you know uh with Tibber um you know really great to see them leveraging these capabilities again to serve insights at uh really high speed. Uh a lot of other customers have uh started to uh started to use the product. Um we've been getting great feedback over the last uh several months uh on this.

24:24 Future roadmap and Q&A

Uh also super pleased to have a really great set of uh launch partners uh both system integrators uh as well as technology partners. Hopefully many of these you're already used to working with. You know, this is also one of the wonderful benefits of using and offering a Postgress database. You know, as I often say to people, they're like, "So, what's the database?" I'm like, "It is just Postgress, right? It's Postgress."
So, you can use it as Postgress. You can connect to it as Postgress. You can integrate it just like Postgress uh with very many of the technology partners, whether that's for data integration, BI, uh governance, uh etc. , etc. So very uh pleased to have a great set of uh launch partners uh with us. Um and I'll take a second here because I've talked a lot a little a bit about you know what we have today right so we have a fully managed Postgress database it's based on provisioned capacity super well integrated with the lakehouse we've taken advantage of some of the really nice uh architectural layering so that we can uh you know deliver high availability uh we can also provide um point in time recovery I didn't spend too much actually talking about that but this is the ability to very quickly uh take that production instance right and branch it into a test environment.
Can be used for test but also some also used for point in time recovery operations. So if someone accidentally deletes a table, you can point a copy of the database now back in time. So we set allow you to set a recovery window of up to 35 days. You can set uh you can just point back in time instantly create a branch. Remember we have that instant branching copy on write capability. So I can create uh an instant branch off of that data. can spin up dedicated compute on that table that was deleted.
I can very quickly oh select star from table drop it out to CSV go to my other instance bring it in uh and within minutes can have recovered uh data that I potentially have dropped and need to get get back. Now doing that in older systems you have to go back to backups or snapshots you have to do a full recovery process you have to bring it up side by side into new infrastructure then you got to go through the process that I just described.
So the actual just getting to the point when you can start to recover can take sometimes hours. If that was a big database, you're talking hours to recover the data back. If this is a big database, branching is still instant regardless of the size of the database. So super super powerful. So really excited about the set of capabilities we have today. There's a whole extra set of things that we're uh working on now. Um you know, one of the pillars that we talked about in the keynote was the sort of the built for modern devx.
Two super important parts for that. um uh that uh we'll start to expose in the product sort of the branching capabilities we have at the moment. We've made it pretty we wanted to focus on like a couple of key scenarios to make it super simple. So you can take one of these database instances and then you can create a child instance off of that. That's effectively branching under the covers sizing the compute capacity separately.
Um what we want to do is uh is go beyond that. Right? So we want to enable full branching capability so you can create you know many branches very quickly. um you know branches of branches etc. Right? Sort of the full branching hierarchy. Think of it as like a a tree with a root and then you know many branches coming down uh from that. Uh and then we also want to the capacity model we have at the moment is a provisioned capacity model.
So when you spin up compute takes a minute or two for the compute to spin up. We want to get to the point where we have uh instant provisioning and autoscaling of compute. Um so and then once you have that combination of fast provisioning of compute and uh instant branching that now means that that developer loop that developer experience that we talked about is now just sort of unlocks an entire new set of uh use cases uh particularly around developer journeys and also as you heard a lot about in the keynote AI agents that want to take advantage of that super fast iterative loop that is not dealing with a large monolithical database with giant data copies and um uh uh uh and capacity that you can't use in that you can only use in a in a very particular way.
So, we're very excited about that. You know, this is part of the uh you know, as we mentioned, as I mentioned earlier, we acquired Neon uh just recently, and this will be part of our work with them now as we look to bring uh more of that uh experience together. Actually, show of hands. Has has any of you used Neon just outside of data bricks? Okay. Uh one okay this is another kill like just go try uh neon. com right it's super cool product um you can use it to sort of vibe code an entire application through uh replet lovable other tools really easy to build databases right so this is really builds applications that are running on database there's going to be like this is going to happen a lot a lot more we're really excited about providing a platform and in an infrastructure uh to support that so get started Today we're in public preview.
Very excited about that. Um and uh we have uh 10 minutes and 20 20 seconds for Q&A. Well, thank thank you everybody for attending the session that changed its title at the last minute. Please try it out and give us feedback. Thank you.

Learn more about the Databricks Data and AI platform.

The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.