Streamlining AI Application Development With Databricks Apps

Summary

Unified Full-Stack Deployment: Build and scale full-stack AI applications handling thousands of queries per second directly on Databricks—no external platforms needed.
Native Services Integration: Leverage Databricks Apps alongside Model Serving, Jobs, and Gateways for built-in hosting, LLM integration, secure access, and CI/CD pipelines.
Rapid Development: Databricks Apps streamline your architecture, eliminate infrastructure boilerplate, and accelerate development from prototype to production at scale.

Streamlining AI Application Development With Databricks Apps

Talk by Domonkos Pal, Director of Digital Product Development, Hiflylabs Zrt
Think Databricks is just for data and models? Think again. In this video, you’ll see how to build and scale a full-stack AI app capable of handling thousands of queries per second entirely on Databricks. No extra cloud platforms, no patchwork infrastructure. Just one unified platform with native hosting, LLM integration, secure access, and built-in CI/CD. Learn how Databricks Apps, along with services like Model Serving, Jobs, and Gateways, streamline your architecture, eliminate boilerplate, and accelerate development, from prototype to production.
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 is Databricks Apps and how does it differ from other platforms?

Databricks Apps is a unified platform for building and hosting full-stack AI applications. Unlike multi-platform approaches, it provides native hosting, LLM integration, security, and CI/CD all within Databricks—eliminating the need for patchwork infrastructure.

Can you really handle production-grade traffic with Databricks Apps?

Yes. This video demonstrates how to build AI apps capable of handling thousands of queries per second on Databricks. The unified architecture provides the performance and scalability needed for production AI applications.

What does 'no extra cloud platforms' mean?

It means your data, models, serving infrastructure, and application code all run on Databricks. You don't need separate services for hosting, database management, or CI/CD—it's all integrated, reducing complexity and operational overhead.

How does this approach accelerate development?

By eliminating infrastructure boilerplate and providing native integration between apps, models, and data, teams can focus on application logic rather than DevOps. This enables faster iteration from prototype to production.

Full transcript

`0:00` Project initiation

Yeah. All right. Let's get started here. Uh before we jump in, I have to make sure that you don't believe a word I say. But um I I I never thought that I would say this, especially in stage, but sometimes I love pressure. Seriously, it leads you to directions that you wouldn't go otherwise. Like building like building a scalable AI AI application with a platform that had just released its first preview version. What could possibly go wrong, right?
So, let me share our year-long experience with Databricks apps, all the good and all the lessons learned. I'm I'm going to share a journey through a specific application, uh but only metaphorically using an AI-assisted uh soccer recruitment tool as an example. I'm from Europe and we love soccer there. But the real reason I'm doing this that is that the data we work with is uh so um secure and confidential that I'd prefer to stay on stage rather than escorted on off in handcuffs or something.
So, um but let's get serious here. When I got into the project, our client, uh let's call him uh for now, uh approached us with the with the following request. I need you to build an AI application that is a full-stack application. So, it's it's not a grid, it is not a Streamlit or whatsoever. Because we need to provide a custom UI uh to the soccer uh scouts in order to be completely aligned with their workflow with their daily routine.
It should have features like AI AI chat streaming chat and AI reports. It should have a dashboard where they can follow the recruitment process. And what was interesting, it had to be production ready. So, we had to have like authentication and all the other stuff required. And we had like about 30 days. So, we were like, "Oh, wow. How should we do this?" And like you mean many teams, we approached the whole problem with the classic move.

`2:37` Initial architecture

We went for the for a well-known cloud cloud provider and said, "Let's just use AWS. It's tried and tested, well-known, and it's like in one of the industry standards for more than a decade." Um right? So, um Oh, by the way, um I may be a tiny little bit too much into dry drawing these kind of architecture diagrams and it's meant to be a lightning talk, so uh please feel free to take pictures because because I have to be quick and I will change the size slides quickly.
So, um and back to the topic. So, so we had like a couple of obstacles. First of all, we had to use uh multiple ecosystem introducing AWS because our data and also the uh AI part was already ready in Databricks. So, um it meant you enter you know enterprise IT, it meant uh a lot of approvals and also due due to the nature of uh the sensitive data, it was wasn't that trivial to how do we solve the authorization also and also the security part of this data synchronization.
So, um and if you notice that small arrow in the bottom right corner, that was also important because either the uh software engineers had to somehow um um understand both platforms uh or the data AI AI engineers had to uh provide those interfaces for the for the software engineers. So, just then a new mail popped up in my inbox. It was like a year ago. And it it uh was about something interesting and promised something interesting.

`4:32` Adopting Databricks Apps

A a platform called Lakehouse Apps, which provides serverless hosting, built-in authentication, security, data governance. Of course, it's deeply integrated into Databricks. Um and um so so it's close to the Unity catalog. It's you close to uh the AI gateways. And um I don't Do you know what Lakehouse Apps is? It's it's like Databricks Apps. It was its previous previous internal name, so I don't want to confuse anyone.
And I was like, "Oh, wow, this is exactly what we need, but uh it's not in GA, right? It's it's just the first preview. It's just in PDF slides. And um can we have, for example, a time machine to go move forward a year and have it uh already for us?" And um yeah, it I have to admit it um it seemed like uh it's it seemed like bit of a gamble, but we we we we bet on this thing from day one from the previous status. Um and I'm not saying that AWS wouldn't have worked, but it was clear that with this architecture we uh we can cut development time by we did the math and it it looked like we we can spare like uh at least 2 weeks.
And um and also the tell you the tell you the truth that we developers, if we see something new, something shiny, we want to try it out. It's like birthday presents for us. And uh that was also motivation. But uh but we uh we knew that uh this kind of stuff comes with the new tool drama. So, we prepared for the uh unstable deployments, we prepared for random crashes, and without any proper traces and so on. And um um yet to our amazement uh Databricks apps not only saved us from the these late night headaches, but uh due to the things it provided all the all the boiler plate stuff which we uh didn't have to implement, we were even able to add some extra features on top of the scope we were you already expected.
Um but was everything nice and smooth? Of course not. Uh first of all, we struggled with uh the database. Back then, OLTP wasn't available in within Databricks. So, we used a Delta table for behind an application like a transactional database uh database. And if you if you are in IT is just it's like the first thing you learn that this is the pattern you should definitely avoid. So, we had a lot of troubles with it, connectivity issues, latency issues, anything you can imagine.

`7:22` Lessons and architecture

I remember our first demo I it it it got delayed, so I had to and I had to run home and sit in the car. The computer was next to me and I I just watched the logs. If anything goes wrong, I can restart the application, so it wasn't that safe. It's you should definitely avoid that pattern. And also the other thing was scaling, which is interesting because building building scaling is still not available. Um but um uh we learned how to um do um prepare our architecture properly so that Databricks is powerful in terms of uh uh heavy compute stuff and clusters in the architecture below the application layer.
And if you do it properly and you have a thin application, it's easy to scale with the services they provide underneath. Um For instance, uh someone pushed an ML uh ML model into into the backend code and you can expect what happened. And I have no doubts that uh my lambda is making us so good revenue uh by uh these uh bad scaling patterns. So, scaling is good if you do it properly. This is the data architecture we used when OLTP or how I should have renamed today to uh lake base, but um we just sync the business data from Delta tables through a service called sync tables.

`9:23` Data sync and CI/CD

It's very powerful, low latency, high concurrency. So, we were able to serve the whole data to through uh this OLTP, uh which can handle like thousands of request cycles and query cycles and thousands of open connections at the same time. So, it really benefits our scaling strategy. And of course, if we want to uh save data in the Delta tables or vector search index, I mean, the embeddings for the vector search, uh then we can use background services or pipelines for that.
One of the most remarkable highlight for me throughout the whole process was the CICD that Databricks provided for applications. If you ever worked with AWS or um Google GCP or or Azure, compared to them, it's really easy to set up a new application from scratch. You really just set up your uh set up your code. Uh if you want, you can set up an IAC definition, so that you have the infrastructure uploaded, deployed it, and voila, you have an up-and-running application.

`10:18` Scaling challenges

Um and if you integrate it into uh GitHub actions, you can have an a a um production-ready CICD pipeline as well. Yeah. Um so Well, remember,? Little did we know that his ambitions were far greater than that. So, he wanted us to build the next step, a uh complete AI portal where everything is self-served. The uh soccer scouts don't need to reach out to any other platform AI platform. They can have their work done in just one uh uh specific ecosystem.
With uploading their the uh information they want uh through documents and by um having all the uh prompts they need and everything. And um we were like again uh Databricks apps was ideal for for this uh this MVP stuff, but uh let's be honest again, at this scale it's time to migrate. So, we designed a a a beautiful architecture again and it it had like a lot of boxes and arrows and it looked nice. But, what it what it told our story again to Databricks.

`11:58` Unified migration

And um they were just like, "Why don't we why don't we try the same but completely uh within Databricks?" And um so we we designed an architecture that scales completely in Databricks. And it it seemed so promising though I I behind the curtains I I I spent a couple of nights to to do the migration in the background not telling anyone that uh I'm a little bit afraid. But, that said, it highlighted one other important advantage to me that Databricks SDK is so powerful that we can have either the free the freedom either to stay on the platform or to move.

`13:22` Scaling technical analysis

Um but, in order to make the best decision here, we carefully listed the advantages and the disadvantages of uh staying in Databricks apps or or moving towards. And the most important um benefit that is that automatic scaling and um uh decoding and resource sharing and also the coordination between the software engineers and the AI engineers are the best if we are in the same platform. There is a lot of benefit from that.
And um from the drawbacks, what I can mention that up until now Databricks apps uh um is mostly stand out if you if you use it for an enterprise type of application. But I haven't answered one important question yet, whether or how can we scale with Databricks with a Databricks only app architecture if Databricks apps not um doesn't provide any scaling options yet. It's about to come. But still we had several options.
And um what you can see in the red box, I prepared the task that involved our most compute heavy stuff, the most business critical part, which included like uh several AI queries, read and writes to the OL TP to uh Delta tables, vector search index. Um and so I'm the type type of person who believes it when I see it. So so I I tested out all the options we had. First of all for we had the the single app instance, which was able to for this particular job or task was able to handle like uh 70 to 8 uh 100 QPS for Yeah, for this one.
And since Databricks introduced course application um authentication, we were able to manually scale these uh scale this task by putting and stacking together and multiplying the performance like this. But, I have to admit it's not at automatic. It's not what we usually do. So, we went over it and we realized that there's a service called serving endpoints. And although it's built for MLflow, we can actually use it for applications and as well.
And it um and it scales uh it scales like a lambda function with very low latency. And Uh so, actually that's the that's the exact uh service we used uh for scaling. And um I also have to mention the jobs because they have a huge latency like 10 to 15 seconds. Though it uh you can install any packages, run it on any cluster, and it can do the heavy-duty stuff for you like document conversion, image manipulation, and whatsoever.
Yeah. Um Okay. But, there was the business perspective in the end that uh it made me think that whether uh made the right call building instead of buying. Um Like, we knew most of these features are available somewhere, but there are there were like three important aspects I want to highlight. First of all, we don't have to make compromises uh by building our own stuff. So, we don't have to simplify the data. We don't have to transform it just for the sake of the product we we want to use.

`16:38` Final business reflections

The other one is the is the UX. So, it that meant the product is exactly built for soccer scouts and um and not the other way around. So, they don't need to they their time is very valuable. So, they uh don't have to um uh adapt the uh workflow of a new software. And the third thing that your agents, your models, your prompts, actually this is your IP. So, you should keep it safe within your environment. Um Yeah. Um If you're a developer, I prepared some a um Yesterday I coded video 03 Pro some code samples there.
I'm not sure it's working. Uh for the for the first 10 visitors, there's a free API key there. Just joking joking. Uh and um Yeah. Uh Thank you very much. I was Domonkos Spal, head of the application development at HiFly Labs. We have a booth there. It's it's uh 822. So, I I guess I spent the afternoon there. I I would be more than happy to talk about all the or or I'm really interested about the stuff you're building.
If you can come over and yeah. Um Thank you very much. If you We really appreciate if you can complete our service. So, 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.