Lovable + Databricks: turn your data into apps your whole org can build on

Summary

Lovable is a software creation platform that lets business users build full-stack web apps in plain English, and its Databricks connector enables these apps to query live SQL warehouses and Unity Catalog data through workspace-level OAuth with existing access controls enforced.
This video shows how Lovable removes the bottleneck of waiting on data engineering teams—replacing weeks-long sprint cycles with minutes-long app generation—while maintaining audit logging and Unity Catalog governance for every query.
Operations leads, analysts, and customer-facing teams can use the Lovable and Databricks integration to build role-gated production apps without writing code, extending the value of governed Databricks data to the 99% of users who are not engineers.

Lovable + Databricks: turn your data into apps your whole org can build on

What if anyone on your team could turn a data insight into a working app, live on your Databricks data?
Lovable is a software creation platform that lets anyone build full-stack web apps by chatting with AI. With the Lovable connector for Databricks, operations leads, analysts, and customer-facing teams can build apps that query your live SQL warehouses and Unity Catalog data. These apps connect through workspace-level OAuth and are governed by your existing access controls.
In this video, we'll show how Lovable works, from describing an idea to deploying a role-gated app on live Databricks data, and how a Lovable customer is running this in production today. Whether you're in operations, analytics, or a customer-facing team, Lovable extends what your data team can deliver, without compromising governance.
Talk By: Suhem Parack, Founding Partnerships Engineer, Lovable ;

Chapters

FAQs

What is Lovable and how does it connect to Databricks?

Lovable is a software creation platform that generates full-stack web applications from plain-English descriptions. Its Databricks connector allows apps to query live SQL warehouses and Unity Catalog data through workspace-level OAuth, with all existing Databricks access controls automatically enforced for every user.

How does Lovable maintain governance when non-technical users build apps?

All apps built with the Lovable Databricks connector authenticate through workspace OAuth and inherit Unity Catalog access controls, ensuring users only see data they are permitted to access. Audit logging captures all queries, giving data teams full visibility into how their data is being used.

Who is the Lovable and Databricks integration designed for?

The integration targets the 99% of enterprise users who cannot write software but need to act on data insights—operations leads, analysts, and customer-facing teams. Instead of filing tickets with data engineering, these users can describe an app in plain English and have it built and deployed in minutes.

What does the demo in this video show?

The demo generates a customer upsell opportunity app built on live Databricks data, illustrating how a business user can go from describing a desired outcome to a deployed, role-gated production application without writing a single line of code. The integration is shown querying Unity Catalog data in real time.

Full transcript

[00:07] Well, thank you everybody for making the time to to attend this session. My name is Suheim Parak. I'm a partner engineer on uh the Lovable team. Um I've been here for uh a month and a half. So I'm pretty new to the Lable team. Before
[00:20] this, I was the um head of forward deployed engineering at um XAI. So I'm super excited to be here to talk to you about how you can build apps at scale with uh lovable and data bricks. Um
[00:32] before we get started uh I just want to mention uh the like the challenge um that we're trying to solve here. So traditionally we had data available for everybody to use in data bricks but that
[00:44] was um or the idea was that this data is obviously governed in in u a data warehouse solution and unity catalog and so on. But the challenge was that not everybody can build applications on top of it. Notice I'm mentioning
[00:56] applications and not just SQL or a dashboard because lovable actually allows people to build production grade applications in plain English, right? So the way that it works is that you go
[01:08] into Lovable, you tell it, hey, I want to build an application or a web app for um XYZ solution and it builds the entire stack for you. This is super important for us because our mission is to allow
[01:20] and enable the 99% of people who don't necessarily know how to write software but we want to empower them to be able to build applications uh themselves just by speaking in plain English. Um so for
[01:32] the uh presentation today I'll just walk through the current work that we have going on with data bricks particularly our data bricks connector that allows people to be able to safely get data from their uh unity catalog and then
[01:44] build applications on top of that and then at the end I'll give a quick demo of what that looks like um in um in action. So we have two parts of um this um this
[01:56] partnership. First is the data bricks side of it where data bricks allows or like has the data available for um uh for data warehousing solutions in um unity catalog and then this data can be
[02:08] accessed by um lovable to be able to ship actual applications on top of it. Right? So the idea is that um instead of having your teammates waiting on let's
[02:20] say a ticket with your data engineering team to be able to write them like some complex queries or waiting on somebody from your GTM ops team to go and like build this application. Sometimes this can take a few weeks or like few sprint cycles and so on. And so instead of
[02:33] instead of your um data engineering peers becoming a bottleneck, they become more of your peers or your partners in this journey of enabling um people to be able to build apps uh directly on top of
[02:45] data bricks, right? So the way that it would work is that you have your team, you'd go and ask in plain English. So let's say you have data about uh customer support tickets, right? And you want to be like, okay, give me an app
[02:57] that gives me like an intercom style uh command center where I can go in and look at what are the existing issues that I have open, what are the um SLAs's, how many of those resolved and so on. All those things. Traditionally, this would require a lot of time because
[03:10] first you would have to write the complete SQL yourself, get the data out of the uh database, then you would build some kind of like application layer, you would build like a React application and so on. I mean you can imagine all of this requires time and not everybody on
[03:22] your team may be able to uh write that code themselves and definitely not in a few minutes right and so the way that it would work is you would ask lovable to do it and then lovable uh calls data bricks and obviously in data bricks your
[03:34] workspace admin is going to specify who uh for for a uh given principle who has the permission or what kind of tables um in the catalog that they can access and it's set up at that uh uh principal
[03:47] level. Once it's set up, then Lovable only gets the um the response to that back, right? So, it gives a live answer back um in terms of what was um allowed for this service principle. And we'll
[03:59] see this in action in just in just a second, right? Um so, the way that it it works is that your workspace admin uh gets what's called a connector. So on lovable you have different connectors that allow your um uh that allow lovable
[04:13] to be able to access these different downstream services and get the data from them in an agentic flow. So the lovable agent knows and like I resolves which connector needs to be resolved. So if somebody says I want to get my data
[04:25] from my um unity catalog, lovable already knows that it's talking about the unity catalog that's part of um data bricks, right? And so it resolves that. But the the solution that we have right now supports machine to machine off. So
[04:38] it doesn't have user to machine off just yet. So a workspace admin and lovable can go and specify that hey for this specific table or this specific catalog I want XYZ u tables only uh should be
[04:51] accessible with a client ID and client secret. They'll enable that uh or they'll give that grant. Once that's done uh the admin will then just plug those four things in here. So if you see uh the display name is something that
[05:03] you can give for your connection. Workspace URL would be your actual workspace. um client ID and secret would be the things that are generated for this uh service principle from um data bricks. Once that's done, that's
[05:15] basically it. A general good practice though that we recommend for people using this connector is that they should try and like give or before building an app in lovable, they should try and have some form of semantic layering. So if
[05:27] you're saying that okay, I have the previous example that we discussed of like support cases, it's generally a good practice to have some form of semantic layer even if that's built just in lovable. So before you start building an app, you can just say, okay, just summarize what data is available in uh
[05:41] this table for me. Um and then it'll sometimes go and even like correct that data for you or it'll try and like tell you, okay, what's like the different data points available for you to solve the use case that you're trying to solve. So in our case, the use case was
[05:53] customer support tickets, but obviously it can be um whatever um is uh use case that you're trying to solve for. So essentially then what you do is that instead of like the the traditional way where you would go in uh get your data
[06:07] uh into like a CSV and then stay in like a a bottleneck or like a holding pattern where somebody's going to uh build a SQL query for you or somebody's going to build the dashboard solutions for you. So generally speaking, dashboards is
[06:21] where like people stop. But Lovable goes one step further where we allow people not only to just like okay get SQL data or just see a dashboard, but you can actually build working applications that can have user authentication that can
[06:34] that you can then um allow people to for example even monetize and be able to um get real value beyond just like a dashboard solution of like analysis, right? So a few a few use cases and
[06:46] examples that are available that people generally uh use this connector for is self-s serve reporting. This is actually our number one u use case that we see for uh data bricks that people want to build their own report but they don't
[06:58] necessarily want to wait for like creating a a ticket with like an engineering team and then keep uh waiting for their turn. They just want to do it themselves. Obviously uh the safe way of doing that is through the data bricks connector because whoever
[07:11] the admin that set up your um service principle made the decision to enable um uh they made the decision to what kind of data is going to be available right so it's basically like a
[07:24] shared responsibility model then the other example is um or other uh types of things that people can build are like live um analytics dashboards and uh to track things like their retention adoption and so on as well, right? And
[07:37] so really you can go from like one uh app to a fleet of applications that are built on top of loveville and the main source of truth will be your unity catalog. So for now given that we have
[07:49] machine-to-achine u authentication then the um the shared responsibilities on the person the the admin that is setting up that uh service principle right and then in terms of the the governance
[08:02] we have um obviously data bricks being the or the unity catalog being the the source then you just make that one connection whatever data is on um unity catalog is what the con connector will
[08:14] see there's no um data that's copied out. So you the lovable copy or queries the data but it's not copying it. It's not making a copy of it and then using that is building the insights that are needed to uh support the application
[08:27] that this person uh would have requested, right? And then we have audit logging and so on as well to be able to like track what types of um use um queries were made and so on. And then this was the part around um going beyond
[08:41] just dashboards and like building actual applications. In lovable we see that people create uh million plus uh projects every week and obviously we have like 50 million plus projects that have been created which uh is like a a
[08:54] good indicator for people that want to build uh production applications um on love right so uh before taking the questions I just wanted to quickly go over the the demo use case that I mentioned to you so in this case um I
[09:08] put together a uh a data schema for certain tables um the the company or the the the uh the dummy name that I use is No Techch Demo. Essentially, this is an API company, right? So, what this
[09:21] company would do is they'll they'll have API offerings for people to be able to like use their APIs uh for different use cases. So, in this case, we have a few different tables. If you see, we have a a log of API calls. So, like all of the
[09:33] different API calls that are u made to their um APIs. We have certain billing events. So if they have a self-s serve API versus like a paid subscription, how many people actually like sign up and so on so forth. They have customer data. So
[09:45] like where their customers, this is obviously this is all mock data just for this demo. There's also things around the usage pattern. So like you can actually see okay what types of um usage is available error logging and so on
[09:57] feature adoption. Uh but if you see if let's say I am somebody that works on the GTM team or on the revenue team you know being firstly this can be a little intimidating because like I don't necessarily know what an API call is uh
[10:11] what a header is and what's a transaction ID all of these things that are saved but what I do want is meaningful insights derived from this data set uh from like a business point of view right so in this case let's say
[10:23] a person uh from the revenue team the the only thing that if they care about is how many of my users that are paid users for example are about to churn or how many are like upgrade opportunities
[10:35] for me. So, somebody's on a lower tier, maybe like a self-s served tier, but they could actually be potential um enterprise customers. For them to be able to the traditional approach or or traditional way of doing this is getting somebody from like a a data engineering
[10:48] team or uh asking them or your data scientist to be able to like write queries for you and then they'll share like an Excel report or something like that. Or if they go one step beyond then you'll have to again make another ticket and like maybe have them build a an
[11:01] application or like a dashboard on top of this. So the the the good thing about lovable is that it it does all of this for you, right? So if I go in, what I'd have to do is in my uh on lovable.dev, I
[11:13] just have to go into connectors. You see there are different connectors listed here. So I just have to uh get the datab bricks one. And this is again to be clear this is available for admins because you want to make sure that the admin decides that what type of data
[11:26] access is available per um for this connector. you you may not want to give them access to like every single data point and only specific objects. So that's what you would select um on your side and then in the connector they
[11:39] would go in and they would put in the client ID client secret and then connect. Once that connection is made you essentially just chat with lovable in um in plain English. So this obviously I already made this demo for
[11:51] or made this for the demo. But essentially this is would be the view for the person who from the revenue team who would want to be able to get answers on how many people are about to churn, how many error rates, how many support
[12:04] tickets open for the last x so many days that have not been resolved and so on. Any business uh answers that you need uh without having to write a bunch of like complex SQL without having to like copy CSV files putting them into Excel and so
[12:17] on. Lovable would take care of that. Essentially, it would ask you to or you'd ask it to give you that information. The connector goes in the back checks what permission and what scoping was available for this connector. So, at the service principle
[12:30] level, if there were some tables that didn't have permission, it would just come back and tell you that okay, you know, we don't have access to this. And if it does, then it'll go the next mile, which is it'll take that data, convert it into an into a like a working
[12:43] prototype or a dashboard, right? So the um this is like the the the uh the app that it generated for me where like if you'd look at this data which is like pretty um intense for us to look at. It
[12:55] converts that into a much more like cleaner picture of like how many customers do we have, how many what's the revenue at risk right now. Um and then these are the things that we specifically asked it to solve for us where we wanted it to tell us what are
[13:08] the top uh churn risk customers and then equally important what are my top upgrade ready customers and then uh the person and the revenue team can then work with their uh GTM cares to reach
[13:21] out to these people and uh figure out upsell opportunities for them. So really the the uh the bottleneck um is removed for people to be able to uh build applications instead of them having to
[13:35] like wait and write SQL queries and then build these models themselves. If they are like a little advised they'll go and like write like a Python script that'll uh use numpy and pandas and so on. that um all of that has been like mass and
[13:48] all of that has been um addressed by lovable where now you can go from your data in your um Unity catalog and then have applications that your teams can
[14:00] use. And the idea is again to enable everybody not just like the engineers on your team. So anybody that has actual business contacts uh can actually benefit more from um from this lovable
[14:13] and data bricks connector. So yeah, that was it for uh for the demo. Thank you so much for uh making the time to to attend this session with us.

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.