Databricks Apps: Turning Data and AI Into Practical, User-Friendly Applications

Summary

• Apps platform GA: Databricks Apps is now generally available, enabling data teams to build production-ready AI applications without leaving the platform.
• Unified interface: Developers can create RAG chat apps, interactive visualizations, and custom workflows that integrate all Databricks services in one place.
• Democratized development: Apps bring data intelligence to non-technical users by simplifying complex Databricks features into approachable interfaces.

Databricks Apps: Turning Data and AI Into Practical, User-Friendly Applications

Talk by Justin DeBrabant, Director, Product Management, Databricks ; Nic Heier, Solutions Architect, Databricks
In this video, we present an overview of the GA release of Databricks Apps, the new app hosting platform that integrates all the Databricks services necessary to build production-ready data and AI applications. With Apps, data and developer teams can build new interfaces into the data intelligence platform, further democratizing the transformative power of data and AI across the organization. We'll cover common use cases, including RAG chat apps, interactive visualizations and custom workflow builders, as well as look at several best practices and design patterns when building apps. Finally, we'll look ahead with the vision, strategy and roadmap for the year ahead.
Here’s more to explore:
Economist Impact: Unlocking enterprise AI: https://www.databricks.com/resources/webinar/unlocking-enterprise-ai
The State of Data + AI: https://www.databricks.com/resources/ebook/state-of-data-ai
See all the product announcements from Data + AI Summit: https://www.databricks.com/events/dataaisummit-2025-announcements

Chapters

• 0:00 Intro
• 1:37 Agenda
• 2:55 Notebooks vs Dashboards
• 3:42 What is Apps
• 5:18 Why Apps
• 5:59 Governance
• 6:55 OpenI
• 7:50 What are customers doing
• 10:21 Public Preview
• 11:20 Demo
• 15:06 Why Databricks
• 17:19 Pre Databricks Apps
• 25:33 Dont Boil the Ocean
• 27:12 Deploy First
• 31:10 Roadmap

FAQs

What types of applications can I build with Databricks Apps?

Common use cases include RAG chat applications, interactive visualizations, custom workflow builders, and self-service analytics dashboards. Apps integrate Databricks SQL, AI models, and data directly into user-friendly interfaces.

Do I need to move data or use separate tools to build apps?

No. Databricks Apps keeps everything on the Databricks Data and AI platform. Developers use the same data, governance, and compute without exporting to external platforms or managing separate infrastructure.

Who can benefit from Databricks Apps?

Data engineers, data scientists, and analysts can use Apps to surface insights to business users, executives, and stakeholders. Apps reduce the need for complex BI training and make data intelligence accessible to the broader organization.

What best practices should I follow when building apps?

This video covers design patterns for performance, governance, and user experience. Key practices include leveraging Databricks compute and governance, starting with prototypes before scaling, and designing for specific user workflows.

Full transcript

0:00 Intro

All right, let's uh let's get going. So, quick intros. Um. I'm the director of product here at data bricks overseeing apps. Um my background actually is in databases. Uh initially did a PhD in databases. Uh used Spark, committed to Spark as an academic project. uh spent some years misguided years in finance and hedge funds. Um and then the last 10 years I was actually chief product officer at a customer data platform company um and we were building datadriven applications.
So to me coming here and kind of overseeing apps is is kind of full circle and we'll talk about some of that and the journey data bicks is on um into these data and AI applications today. So and I'm joined by. , you want to intro? So I've been at General or I've been uh at uh data bricks uh for um this is my third week. So I come from the automotive industry. Uh I spent the last couple of years um launching them into the cloud.
Um and the centerpiece of that was data bricks. Um, so I'm going to bring some practitioner slides of some of the things that I experienced um, uh, launching apps and how data bricks apps has kind of helped solve some of the problems. Yeah, when I reached out to about doing a talk, he was still a GM and I I was like, you know, you're you're one of our great customers. Come talk about it. He's like, well, I have some news.
So, very excited to have him on board, though. All right. Uh, forward-looking statement. You guys get this a lot. So quick agenda. So we're going to go through this is technically like a kind of 101 beginner level course. So um we're going to talk about why apps for data bricks. Um give kind of a 101 demo. Super simple how to build our first app. Um then I'm going to kick it. We're going to do uh best practices. I'll talk a little bit about what's next and then we do want to leave some time for some Q&A.

1:37 Agenda

Um and uh we'll get to that at the end. So let's get into it. Um the theme of DES is data intelligence for all. Um I hope you come away with one takeaway from this is apps is data intelligence for all. It's about democratizing um data and AI to teams that wouldn't historically interact with data bricks, right? Data bricks is, you know, it's I would say it's complex. It's designed for power users. Um you know, there's a lot of power in the tools and products that we build.
Um, and increasingly what we're seeing is apps as a way to kind of simplify those interfaces. Um, put these complete workflows in front of people that aren't going to use data bricks on a day-to-day basis and still empower them with uh these data and AIdriven tools. What is a data and AI application? I think we all get this uh it's an app where a lot of the value is uh through data and AI. And you know, I would argue that you know, pretty much every application uh is becoming a data and AI application if it's not.

2:55 Notebooks vs Dashboards

Everything's being transformed right now. Um and you know, we get this question a lot, so I throw it up there. What's the difference between notebooks and dashboards and there's a lot of simil similarities actually, right? Um they're all just kind of different interfaces for, you know, either configuring workflows or visualizing data. Um what we see with apps though is is apps as a way to bring together a much broader set of data bricks products and services.
Um much more configurable, much more powerful. These are designed for very specific use cases and very specific personas. Apps can be whatever you want it to be, right? Um but still kind of in that same theme of democratizing data intelligence through higher order interfaces. So what is apps? Um, apps allows you to easily build secure and governed data intelligence applications directly in data bricks. Um, so if we kind of figure out why that's hard um you know everybody maybe not everybody here but um you probably have some experience u building an app in some way shape or form especially you know if you tried any of these vibe coding tools out there.

3:42 What is Apps

So let's say you vibe coded some simple front-end app um and now you need to integrate it right. So now you need to integrate the off and SSO. You need to define the governance and access around that. Um you need to manage the infrastructure and the containers that you're going to deploy this on. You need to integrate into your VPC because we're all enterprises and this is an open internet apps. Um you need to deploy a database to manage app state, integrate with observability tools, configure.
The point is is that just kind of the initial development of that app is not the hard part. The hard part is actually productionalizing this in your environment um in a secure and governed way. And so data bricks ops really set out to try to solve that problem. Um at the end of the day we are a secure and governed uh uh hosting framework deployed directly within data bricks. So it's managed in our serverless environment.
Um we have built-in SSO based on your data bricks credentials already. We have built-in o across all the data brick services. Um so we make it super easy for you to go from iterating on you know this this front end this app. um and then deploy that in the um in the secure and govern bubble that is data bricks. So uh why data bricks apps? Um let's double click into each one of these again powered by data intelligence um built on everything in data bricks uh out of the box off and SSO and now um we're going to have oneclick integration with our new uh database offering.

5:18 Why Apps

Um I'm sure you all saw the uh neon acquisition. We'll talk about that more tomorrow and how that fits into kind of our broader strategy and plans, but this was always kind of the missing piece of apps. Um, you know, it's it's great to have analytics, it's great to have AI, but you need kind of some operational backend and a lot of apps need that operational data. The orders, the logistics data, etc. Um, are really important.
Um, secure and govern. So, we're managing the containers. Um, we're managing the infra. Like I said before, it's deployed across our serverless environment. Um 30 regions, all three clouds. Um we do resource level governance through uh Unity catalog. So we actually allow you to do is um the app has its own service principle and you can define permissions at the app level. We also allow you to um use the user of the app's permissions, right?

5:59 Governance

So the user of the app can say I can access this data and then the app can access that on my behalf. So we call that on behalf of user authorization. So you can kind of pick and choose between these off models um depending on the use case and depending on the app that you're building. And then obviously the out of the box off and access logs for auditability, right? Really really important um in any enterprise environment.
Um and finally we're open. I it was a theme of all of data bricks um you know open storage open catalog um open framework we did not go and acquire one framework um and uh and say that this is this is our app hosting framework instead what we did is um we supported kind of this open ecosystem of initially Python based app frameworks um so gradio- shiny um streamlid backends with fast API and flask um and now we're announcing support for node and react So it's not just Python based apps anymore.

6:55 OpenI

Now you can build these JavaScript JavaScript based apps. Um and we're going to continue to add more frameworks and more libraries on top of this. And then in addition to the actual libraries and frameworks, we have um a bunch of managed open source packages that we deploy um and manage automatically with your app. So again, seamlessly integrated, secure and governed and bring your own framework. So what are customers doing?

7:50 What are customers doing

Um well, will talk about this a lot more. Um but it really is a range of things. Um it's anywhere from what you would expect in terms of interactive data apps, um rag chat bots. There's a lot of embedded visualizations in these apps. But the way you can think of often how these visualizations are done is maybe you need to run some pre-processing, right? So you um the data science team builds some configuration around a pipeline and so you allow an analyst team to go in there and say I want to ingest this data.
I want to run this model. I want to visualize the results in an embedded AIBI dashboard and then I want to write back to some DBSQL table. Uh that whole flow is actually a really common flow. Um and it includes pieces of visualization, includes running jobs, but you're doing it in kind of an endto-end interface that allows it to be self-service. Um, I assume most of this audience is, you know, data science and data engineering teams.
Um, how many of you feel that you spend a ton of your time just kind of doing manual ops, right? Like if you look at your your backlog, yeah, lots of hands. If you look at your backlog, I guarantee there's these one-off requests, write some custom SQL, run some job, parameterize this model, whatever it is, it's ops, right? Ops is not how you should be spending your time. you should be spending your time building and innovating.
And so increasingly, you know, if if the things you're supporting aren't self-service, then you become the ops team, right? And so a lot of the value prop for apps is to kind of uplevel the interfaces and the workflows and allow the teams around you to be self-service, right? Apps aren't just for line of business teams. They absolutely can be. You can, and we use this internally, our our sales and go to market and marketing teams use data bricks apps internally for a ton of different use cases. now including for uh stuff going on with this conference.
Um but it's also just the teams that are adjacent to data science and data engineering that you're trying to empower to be more self-service. So um a lot of our customers are seeing a lot of success just kind of manually um or getting away and automating those kind of manual processes and ops that they were doing um in supporting the line of business teams. Tons of Genai and LLM chat bots, right? Like uh you know no shortage there.
Um, lots of different things here. So, again, uh, the last thing I'll say is we just went G. That's uh, an announcement this week. Um, we only launched public preview in November. Um, uh, I think will say tomorrow, this this wasn't on his bingo card of the level of success that Apps was going to see. Um, we've had over 20,000 apps created across 2500 customers. Um, and apps is the fastest growing public preview product at data bricks ever.

10:21 Public Preview

Um, I would have said fastest ever, but there's another part of the keynote where, you know, one of the products got to a billion dollars and they claimed to be the fastest ever and that's a whole different thing. So, uh, all I'll say is in six months we got to 20,000 apps and 200 customers and that's a tremendous amount of growth and we're super excited for everybody here that has been part of that journey. We really thank you.
We're super excited. Um we still think like this is very early but the initial you know validation and pull from the market has been tremendous. All right so let me uh let me get into quick demo real quick. All right. All right. So what we're going to do um this is our staging environment. Um I'm going to go in here. We're in the compute tab. We can see apps. I'm going to create an app. So this is something that everybody here in the audience uh can go home and do or do it right now.

11:20 Demo

Um so as we create this new app uh we actually have different templates that we support. Um these are essentially kind of boilerplate code that we have. We're actually going to be releasing kind of more um more endtoend templates um in the next couple weeks that support uh more complex use cases. But you can see here we have Dash, Flask, Gradio, Shiny, Streamlit, and we'll add um a Node and React template as well. Um so you can select which framework you want and what type of uh what type of um app you want to build.
And then this is where you would configure the resources. So because we've already preconfigured the resources um for the chat app to need a model serving endpoint, you would be able to go in here and select um the appropriate model serving endpoint that you've set up. And now the idea is that this is some foundation model. So you have some model serving um endpoint around a foundation model. Um let's click next. Um, and then you can see here you can give the app a name, a description, demo, deploy the code for this app.
Um, once the and it it takes a minute or two for the compute to spin up. We're going to get that down. Um, we want this to be much more instantaneous, but you can see now here the metadata for this app. um you can see where it was deployed from the resources that you've configured. Um and then once this was available um you would see the URL um and be able to click into that app. I already have one pre-eployed. It's the exact same app.
Um and you can see here this is the URL for that app. Um and so now if we were to go into this, we could open this app and we can see this simple chatbot app that we've created um backed by a foundation model. Right? So the point is it's super simple. I'm sure you've seen lots of apps like this. The point is not that this app is the sexiest app that's ever been made. The point that it was really easy to deploy this in a secure and governed way immediately connected to this model serving endpoint, right?
Um there's other examples in there. Again, I would encourage you to go and create your own apps. And like I said, um over the next couple weeks, we're going to be releasing more and more of these kind of app templates that are much more fully baked apps. Um, and we'll release them as open source so you all can take them and tweak them and build them into your own environment. Um, and you can see here that we could even go in and uh edit these permissions.
We can uh go and add additional resources to this app. So I could say uh I want a SQL warehouse and I can configure it to attach to that SQL warehouse. Um, so it's flexible, right? So it's super easy to configure this app. um attach it to resources, add permissions. So maybe this was a logistics app, so I want to add my logistics team. Um and you would be able to add that team there. So again, the permissions of what the what resources the app can use, who can use that app, all seamless to create here, all deployed within data bricks.
That's the point is it takes a minute or two to deploy this app. Um and you can get on to building more. All right, I'm doing on time. We're good. Okay, at this point, wanna Yeah. So, um, from a practitioner's perspective, um, so why data bricks for me, right? So, you know, it's not always easy to do the easy things easily, right? Um, data bricks just certainly, uh, data bricks apps helps that, right? So whether it's you know syncing your code or connecting to data or sharing your app um you know that stuff as long as you have a little information um on how data bricks apps approaches it you know those trivial tasks become easy and then you get to best practices now I'm I'm not uh you know I'm not some full stack wizard right uh but I understand business problems I can code a little bit to solve them so um but we know what best practices look like um you know from a core perspective uh data bricks apps isn't going to force you to do best practices, right?

15:06 Why Databricks

But if you want to um you know use git and have a branching strategy and uh leverage environment variables and keep secrets secret um and have a proper dev test prods um you know we'll make it low friction in order for you to do best practice stuff. Um, and then as you go down, you start talking about some more complex tasks. I put debugging in this because debug debugging is always complex, right? Um, so but if you're doing some of the best practices and leveraging logging, um, and you understand a little bit about the code that cursor wrote for you that you deployed, uh, you can look at the environment variables and the packages that are installed and start your debugging journey.
As we saw, there's lots of um ML components. You want to integrate an ML endpoint into your app. Um you want to string together a couple of APIs or gather some information and kick off some agents or deploy an MCP server. Um you know, that stuff you're going to have to bring some skill, right? But it makes it accessible um if you're if you're doing it in data bricks apps. Um, so I'm just going to walk through a little bit about, you know, the pre- data bricks apps scenario.
So we're deploying apps and Azure app services, but you know, the first thing was uh exciting new project. Um, you got some features to deliver for release and you know, let me know if this sounds familiar, but the first thing you want to do, we're builders. So, we just go start building and you build locally. Um, and you start adding some features. Maybe things get carried away. You add a couple of things that weren't supposed to be in the release.

17:19 Pre Databricks Apps

You run into a couple of problems, you know, and the next thing you know, the release is upon you and you've got to do the demo and then you go like, great, I got to deploy this thing. Um, but you got to go get the infrastructure set up and you got to get a service principle. And then to do the deployment, I got to get a GitHub action. And then um you know I do the deployment and my Azure VM can't hit public pi pi right it's like oh crap so I can't get my libraries installed so I got to do that on the agent I got to copy it over and then I get that working and then I can't connect you know to the data because there's a private endpoint and then I got to get an SG rule and then I got to get somebody who has access to do that and then I get that fixed and then my app this what's it the has lived this right yeah and then my app still doesn't work.
So then I go to debug it and I don't have access to the logs and guess what my demo happens on my dev box, right? And I go, oh, maybe next iteration, you know, I'll uh I'll get a proper pipeline to deploy it so, you know, the customer can actually use the features that I work so hard on. Um, so in comes data bricks apps, right? I knew this was sort of coming along and from the data bricks apps team you know had reached out and he said let's get a half hour you know I want to show you what we're working on and so I started the meeting with just like you know it's a complex environment I don't expect it to work and he said we're not ending the meeting until you deploy an app and literally it ended in 10 minutes we had an app deployed and five minutes was you know me using homebrew to get my data brick CLI updated to use the commands you know, and then it was like, oh, like this is completely different, you know.
So, you know, my advice from data bricks apps is do what just did. You start with a deployment. Go pick a data app and deploy that thing and get it up and running and start with that so you don't run into this like how do I get it in front of the users to meet my release deadline. Um, and then as soon as you do that, follow the instructions. They're customized, you know, to your app. set up your local dev environment, get it running locally, change the title title of your hello world, go deploy that thing, watch the title change, and then, you know, start going fast with your iterations, right?
Um, and leverage the security that's in there. Rewind back to the Azure, you know, example. Um, I had, you know, put SSO on top of that app. And then I got with the token. I got to decode it and then I figure out what roles they have, but I still have to code what that user can and can't do, what that service principle can do on behalf of that user. I've got to code all of that, right? So, I end up with a gigantic switch statement of some sort.
So, you know, hundreds of lines of code to control access in my app. All that goes away. You know, it comes baked in. You leverage UC to control. user has access to what they have access to and you can just worry about features um and not security. Um yeah, and I was going to say it's and it's not just about the complexity, right? It's about getting that right, getting the security and the governance rules right. If you're kind of coding that from scratch every time and stringing together all these different services, it's really hard to do, right?
Um, so the point here is we're allowing you to innovate quickly, deploy this code to production quickly, but with the governance and security kind of guard rails in place, right? And if you do that, you basically have this safe sandbox. I mean, apps by default get deployed in a workspace environment that can be controlled by network egress controls. So, it can't access anything external. You can certainly allow it through egress controls to do that.
But the point is is like you set up your environment and then you're deploying the apps to that environment and that environment is safe and governed and piggybacks on top of everything the data bricks platform has to offer. And so that that security and that governance allows kind of a pace of innovation. So you don't have to worry about getting that wrong every time you deploy. Yeah. And as soon as you you know as soon as you're developing locally, you get something that works like deploy that thing.
Flush it through. Don't let your local environment drift and get too far away. You know, push those through, let them deploy. Um, you know, think about your apps as ephemeral. I mean, uh, you know, some of the app services on the Azure one, we would clean them out and redeploy them and there'd be leftover environment variables and things like these things you can spin up and use and spin down, right? Uh, so um, if you uh if you code it right, uh, you're not hard coding things in there. uh you should be able to say you know I want this branch deployed in that test environment and this branch deployed in this dev environment uh different apps in the same workspace or in different workspaces you know it's all it's all code and hopefully you end up with you know uh user demos and not demos from your um your machine at the end so that's the iteration story this is just starting to think about you know the first thing that you build and you know my advice is just start with the simplest thing that adds value and just go build that and deploy it, right?
So, you think about um you know, a new vehicle launch that's got a new battery um that's got some uh a lot of attention about quality, right? And you've got a vehicle engineer uh who gets assigned this sort of task um you know, of a vehicle that maybe has some issues. um you know they're they're in a world where they're in a PowerBI report and they pull uh you know a table out of there into Excel and then they update some comments and a status on it and then they hand that to a data engineer and he does you know something with it to get it back in the system to populate a dashboard.
It's like no it's just a simple use case. We just need a vehicle engineer that wants to edit a record you know add some comments make a status put a time stamp on it um and then update a delta table. It's like, well, just add a add a simple form. And you know, this vehicle engineer wasn't somebody that was going to be in the data bricks ecosystem, but you know, this interface unlocks all these manual steps and gets Excel out of it.
Um, so, you know, you kind of get that use case up and running and it's helpful. Um, and then you go, well, I've got some supply chain information about batteries, um, and what, um, demand is like and maybe what battery goes on to what vehicle. I've got a file to upload. Um, so Delta share would be great, but strained IT resources on the customer or on the supplier side. Um, great. Let's just add a page, add a button, upload the file to a volume.
Um, maybe set some parameters and allow that person to kick off the job, right? And that processes and guess what? You know, it's processing in the same environment where you've got billions of telemetry uh, sensor data endpoints coming in about the vehicles. So now you can marry those two things together. Um, and then hey, how about, you know, you've got some customer verbatims about what they experienced with the vehicle, like I don't call batch inference or an MLM point to help you out with some classification there.
And then now you've got a curated data set that's got diagnostic trouble codes from the vehicle. You've got supply chain information. You've got notes um like curate that into something you can put a genie room on top of. And then you've got natural language querying of it. And then you know all all projects end in a dashboard, right? So embed a dashboard on top of it that connects all of these things together. Um it allows you um to display it, right?
So um you know this is how you can start with a simple problem and just add and stack features on to really get momentum and um you know create something that started out super simple, solved a problem um but ended up adding a lot of value in the end. and it goes to the kind of don't boil the ocean approach to this, right? I I've been in a bunch of QBRs um for apps and one of my favorite parts since joining um back in December is just kind of going listening to these different use cases.

25:33 Dont Boil the Ocean

And so like I'll I'll join these QBRs or these customer meetings um maybe with some of you in the room. Um, and inevitably it's always a well here's kind of a long list of ideas and like the we've documented kind of some of the key things to do. And I actually really think that process takes more effort than just building the app, right? Um, and so my guidance is like what is saying here, just just go build something, right?
Like you you don't need the PRD and you don't like just just build something. Um, I'm not saying you need to put it in production right away and put it in front of people, but I think that process of building helps create this flywheel and kind of improve these iterations. And then I was with a customer and we had this exact conversation. Um, and they're like, "Okay, well, we're going to, you know, compile some list of ideas and maybe we can touch base in two weeks and, you know, we can see what what is the best one that we can go build."
And so I gave them this advice. We still touch base two weeks later and they were like, "We have like six apps running now." Um, and it's been amazing. Um, you know, one app we intended for a team of like five people and there's already like 25 people using it. Um, so again, it's the point, right? Don't boil the ocean. Start small. Um, improve and iterate. Apps really helps you kind of innovate at pace. Yeah. So you know my first ask or you know thought was like you know deploy first.

27:12 Deploy First

So two main points to get out of my you know my talk here. One was like how many people can deploy an app before their plane lands you know this week. So like just go deploy it first. Um, and then secondarily is to brainstorm and walk out of here with maybe 30 different use cases, um, that, you know, hopefully, you know, can make your life a little easier and add some value to your company or maybe you just get to build something that's fun, you know, and that's enough.
But um you know as far as use cases go uh we talked about the you know the vehicle engineer and dashboards that maybe need to go two ways that are presented in front of executives. You know, we've also had not just nontechnical folks, you know, I had some uh a cohort of SQL warriors and I created this notebook that did some like pretty in-depth um profiling and data and I onboarded them to it and um they loved it, they ran it, they liked the output and they went and sequed for a month and then you know all of a sudden Slack comes in with people going like I what is this notebook thing again? like do I how do I do the inputs and did I run the cells out of order and what's my compute and it was and then then happened again and it I realized that like notebooks aren't I love notebooks but they're not for everybody.
Uh, so put a simple interface on top of it that, uh, makes those decisions for them. Um, and just keeps track of what they've run. Um, and then go to your Slack and just find all of the things that are in there, um, that are automatable, things that end up, you know, as messages to you just because you have a little bit of subject matter expertise, maybe some access, um, that somebody else doesn't have and you provide like a gatekeeper functionality, but don't really add much value to, you know, go gather those things up. uh provisioning project resources, right?
Just make a simple form, gather information, maybe pull the project out of service now, get the business value automatically, um provision a schema for them, set the access, hit the GitHub repo API, uh provision that for them, and then tag all this stuff along the way. And oh, guess what? like why don't we reach into the system tables while we're at it and show that user how many DBUs they spent in the last month on which projects and just integrate all of that stuff in there.
So, you know, by limiting the damage uh somebody can do with an interface and also um layering in some governance and accountability, you can automate a lot of this stuff. Um you know, that could be really a drag on your time. um wouldn't you rather build something to automate it than answer all of those um uh you know Slack questions as they roll in? So um yeah, any anytime there's gatekeeping but not adding a bunch of value, maybe you can put up some guard rails um and allow people to sell service data bricks apps, you know, is is the way to do that.
So yeah and I again I think the main the main point here is or kind of a meta point here is you all have invested a lot in data bricks time money effort you've invested in data bricks as a platform you've gotten your data there it's in the lakehouse you've invested in models um 80 plus% of you are using unity for governance it's amazing right you've made all these kind of infrastructure platform investments apps really helps you connect that to more value across the organization and really that's the that's The point of this at the end of the day, it's not technology for the sake of technology and data for the sake of data.
It's we need to kind of drive more data driven, more AIdriven business decisions that really have an impact. And apps can accelerate you doing that beyond just you know you all running the queries or the notebooks or the models or or whatever. So I want to leave time for um for um I'll do a lightning talk on the road map. Uh and I'm happy to answer any other questions around this. Three themes that we're going to focus on over the next couple quarters.

31:10 Roadmap

Um scalability. Right now apps are a single instance. We're looking at larger instances. Um we're actually going to release that um in a couple weeks. And then also uh horizontal scaling. So um you know being able to autoscale out and down um based on usage um out of the box observability for these apps. So as you create these production ready apps how do we create the right observability around that app not just uptime but also performance resource consumption etc.
Um and then uh a lot more around governance. Um implementing some of these best practices. Um this idea of enforcing that apps must be backed by Git and checked into code. Um you know better and kind of more visibility around audit logs, things like that kind of help the governance of apps as hopefully the adoption uh explodes across the organization. So those are the main three themes that we're going to be investing in over the course of the next couple quarters.
And with that, we have uh about six minutes. I think we're doing pretty good. Um so why don't we uh actually we have two mic stands right there. Um if anybody has questions, we're happy to take them.

Learn more about the Databricks Data and AI platform.