Skip to main content

Build Enterprise Apps on Databricks with Plain English

Summary

  • Lovable enables non-technical business users to build production-ready applications directly on governed Databricks data using natural language, removing the dependency on engineering teams to create ETL pipelines or custom backend infrastructure before business value can be delivered.
  • The Lovable Databricks Connector authenticates via a service principal and client secret, allows admins to scope which Unity Catalog tables are accessible, and uses table descriptions as a semantic layer so Lovable understands the data it is building against.
  • Applications built with Lovable go beyond dashboards and reports — end customers can use them directly with the underlying data governed by Unity Catalog at the service-principal level, and row-level security is on the roadmap for future Databricks-native deployment.

Build Enterprise Apps on Databricks with Plain English

Watch: Build Enterprise Apps on Databricks with Plain English
Databricks provides the foundation for enterprise data and AI, but building applications on top of that data can still be slow and engineering-heavy. In this video, Lovable demonstrates how teams can build production-ready apps on Databricks using natural language and the new Lovable Databricks Connector.
See how teams can create dashboards, operational tools, and AI-powered applications directly on governed Databricks data without ETL pipelines or custom backend infrastructure. We’ll cover the architecture, security model, and a live demo showing how teams can go from idea to working app in minutes with Databricks Apps and Lakebase.
Talk By: Suhem Parack, Founding Partnerships Engineer, Lovable ;

Chapters

FAQs

What is Lovable and how does it work with Databricks?

Lovable is a natural-language application builder that enables people who cannot write code to create production-ready applications directly on top of governed data in the Databricks Data and AI platform. The Lovable Databricks Connector connects to a Databricks workspace using a workspace URL, service principal, and client secret, then scopes accessible Unity Catalog tables through admin governance. This video demonstrates how a team member can describe what they want in plain English and have a working, data-connected application ready in minutes.

What kinds of applications can non-technical teams build with Lovable on Databricks?

Lovable goes beyond traditional dashboards and reporting tools — it can build full operational applications that end customers interact with directly, such as customer retention tools, support portals, and self-serve reporting interfaces where the underlying data lives in the Databricks lakehouse. According to this video, the goal is to let go-to-market teams, revenue teams, and other non-technical stakeholders derive business insights from lakehouse data without waiting on engineering to build ETL pipelines or backend APIs. The application is connected to live Unity Catalog data with governance enforced at the service-principal level.

How does Lovable handle data governance and security in Databricks?

Lovable uses a service-principal-based access model so that all data queries run under a governed identity with Unity Catalog enforcing which tables and columns are accessible. Administrators control which Unity Catalog tables Lovable can see, scoping access to only the data relevant to the application being built. Row-level security is described in this video as a future capability on the roadmap for deeper Databricks-native deployment.

Why are table descriptions important when using Lovable with Databricks?

Table descriptions in Unity Catalog act as a semantic layer that helps Lovable understand the meaning and context of the data it is building against, enabling more accurate SQL generation and more relevant application features. Without clear descriptions, the natural-language interface may generate queries that miss important business logic or misinterpret column semantics. This video recommends investing time in writing good Unity Catalog table and column descriptions as a key step to getting the best results from the Lovable Databricks Connector.

Full transcript

[00:07] Thank you everybody for making the time to to come attend the session. My name is Suheem Parak. I am a founding partnerships engineer at Lovable. I've only joined Lovable pretty recently, a month and a half ago. Before this, I
[00:19] was the head of forward deployed engineering at XAI or SpaceX now. So, I'm excited to be here to talk to you about building apps at scale with Databricks and Lovable. So, Lovable, the
[00:33] platform with we're trying to solve a basic problem where we want to enable the 99% of the people that don't know how to write software to be able to build apps at scale and in a secure fashion.
[00:46] And in the context of Databricks, a lot of the data is or the data plumbing work is generally done by data engineers and data scientists and so on. And then you have your data pipelines.
[00:58] But really to derive insights and get business value out of that data requires sometimes a lot of time and effort. Sometimes that means that you have to wait on your engineering team to be able to build out the ETL pipelines for you.
[01:11] Sometimes that means that you have to wait for your engineering team to actually build the backend or the APIs for any web application that consumes this data that resides in in your data lake, right? And so,
[01:23] Lovable is trying to solve this piece right here. That where you have your data that's like governed by Databricks in your lakehouse and a Unity Catalog. And the building part is taken
[01:36] care of by Lovable. And so, what we'll do is we'll quickly walk through how that flow looks like today. Then after that, I'll show you a demo of how anybody on your team can utilize your
[01:50] Databricks data and then build apps on it in a secure manner. And then we leave a few minutes in the end for for questions. So right now, the approach or the idea is that anybody on your team that doesn't know how to code should be
[02:03] able to build and use the data that you have in Databricks and build meaningful outcomes from it. So it's not just Notice that I'm not saying that you can build dashboards or reports because Lovable goes way beyond just like a
[02:16] traditional dashboarding solution or a reporting solution. You can actually build applications that your end customers can then use where the underlying data is the data that lives in your lakehouse in in the Unity
[02:30] Catalog. So the the idea is that we don't want to or the people that want to drive business insights and value like your GTM team, your revenue teams, they don't necessarily have to worry that much
[02:42] about writing the SQL themselves, waiting on engineering teams to build the ETL pipelines for for from an engineer, but rather they can just solely focus on what's the problem that they're trying to solve.
[02:54] And so once you essentially sign in to Lovable, you create a Lovable account generally for for teams, you have what's called an enterprise account where your admin provisions different access tiers for you. And then somebody
[03:06] on your team can go ahead and be like, "Okay, ask a general question." So for example, somebody on the revenue team can be like, "I want to identify all of my customers that are about to churn." Or I want to identify all of the
[03:19] customers that are at risk. Or maybe you have support system data about like your support tickets and so on, and you want to build an Intercom style communications platform where you can communicate with your customers,
[03:31] identify what open tickets are, how many, what's the resolution time, and so on. All of that stuff traditionally required you to wait for your engineering team to build the back end for it, the APIs for it, and then deploying it, managing the
[03:44] deployments, versioning it, and so on. All of that part is then handled now by Lovable. So Uh, you make a query, and get the data back, and then the data uh is part of um or uh uh deployed on the
[03:57] Lovable Cloud for now. So, the way that we enable this is using what's called connectors. So, on Lovable, you have different connectors for different APIs and different MCPs. So, in the case of um
[04:09] Databricks, there's a Databricks official connector where you essentially go in and specify a few different things. The first is that you specify, "Okay, what's the what's your workspace URL?" Um you specify the client ID and client
[04:21] secret for your service principal. So, as of today, we only support uh machine-to-machine auth. We don't have user-to-machine auth just yet because we're still working on it. But for now, anybody that's a workspace admin for
[04:34] Databricks can go in and decide they can specifically decide what what type of access level should your team have. So, they can uh scope it to the types of tables in your Unity Catalog that can be accessed by this connector. And once
[04:47] they specify that, you they'll generate the client and client secret, and we'll walk through an example of this that they'll plug in for you. So, really this task of enabling the connector happens at an admin level. So, somebody from your um uh data from your Yeah, the data
[05:01] the Databricks or your uh um the Lovable workspace will go in and give that permissioning. Once that's done, and they'll scope that This is the only data that's available, then you can uh go ahead and start using
[05:13] the um the connector. So, essentially, um the types of use case These are just some examples. Obviously, they're the examples are end um endless, and that's the uh the idea behind Lovable is any questions or any ideas that the let's
[05:27] say a marketing team has or a sales team has, and they don't necessarily have the the um the time to wait for their engineering teams to build out the back end for it, they can specify that in plain English. So, like the first example that you see around retention,
[05:40] adoption, uh those types of metrics, generally you required some form of like ETL pipelines, you required your uh data scientist to pull up reports for you. Now you can go beyond just the reports. You can just have applications as well
[05:53] that the rest of your GTM team, your rest of your marketing team, revenue ops team, and so on can then utilize that that data as well. The other common example is around self-serve reporting. Traditionally, people rely on Excel
[06:06] sheets or doing an export and then uploading it to cloud or something, whereas you can directly get that reporting done through dashboards that you can share with like people internally and then enable it using like email
[06:19] sharing and so on as well. So truly it's going from like you can either deploy like one app or you can have multiple apps for your entire team that's governed. So it's a shared responsibility model
[06:31] because the workspace admin that's specifying the service principal, they decide the scoping and then Lovable basically takes care of the the back end. So you can think of Lovable being your co-founder or being your back end
[06:43] engineer doing all of the heavy lifting for you. Whereas your workspace admin is the person that's controlling the the data governance side of it. So this again specifies the fact that we're not copying any data out. Right now we have machine to machine,
[06:56] but eventually we're going to support user to machine auth as well. Another thing to mention is that right now the apps get deployed to Lovable Cloud. Eventually we're going to get to a state where you can deploy those directly into
[07:10] Databricks, but we we don't have the that work complete just yet. So once that's done, you can you'll have the option to either choose to deploy to the Lovable Cloud or you can just choose to deploy like your other Databricks apps
[07:23] as well. And this is some numbers around why Lovable is so powerful because generally a lot Lovable built apps generally get a lot of usage. So not only can you just build these apps, you can actually like
[07:35] productionize them. You can share it. You can have SEO to make sure that like these rank up as like not just like wipe quarter projects, but they're actually enterprise grade production applications that are searchable, that have
[07:48] analytics, that have email management, notification support, all of those things comprehensively done without having to write any custom coding. So, before taking questions, I'll just walk you through some examples of what
[08:02] that flow would look look like, right? So, if you go to lovable.dev, which is the um the site, you'll see that there is this idea of connectors here, right? So,
[08:14] within this connectors, there are a bunch your workspace admin would would essentially go in and select the Databricks connector. They would create a connection, and these were the three URLs that we saw, right? The workspace
[08:27] URL, a client ID and client secret for your service principal, and the way that you would get it is obviously your admin will specify a service principal. Um let's just call it
[08:43] I won't go through the entire flow, but I just want to showcase how you could add it. Um and then you just like add the the service principal. Once you've added it, you can go ahead and get the secrets
[08:56] generated, so you create you specify how long you want this service principal, and then once you get your keys and secrets, this is what your workspace admin would then copy into here. And
[09:08] then now that data and obviously they would go into your Unity catalog and at a permission level, they would go in and like grant the different So, like they would select the the principal that that we just created,
[09:20] and then fine-tune and like specifically select what type of access this principal should have for what tables and schemas as well. So, for the demo, what I did is I just put together I'm from northern Virginia, so I just call
[09:32] it NoVa Tech, but this is essentially an API company that provide or data for an API company that any developer can like sign up for whether they're self-serve or enterprise and start using their APIs and they have
[09:45] like a billing pay-as-you-go type of a model. But, if you notice that there are different tables or things around like their API calls, how many API calls are being made to their APIs, billing events. So, billing events would be things like how many people are
[09:59] on self-serve, how many people are enterprise customers, how many are strategic partners, who are the contacts with the customers, their daily usage, their error rate. So, like this would be an example of like an error log. The
[10:11] reason why I put this data is just to showcase that traditionally somebody who's let's say on the GTM team or on the revenue team, they may not necessarily know how to access logs for example or how to like what an API
[10:25] header is or what a transaction ID. All those things traditionally the engineering team has that knowledge and then they'll use that and infer that provide GTM signals. So, like if you have like a a go-to-market team or a revenue team that
[10:37] wants to understand how people are using their APIs, are they running into challenges, and then how that correlates to revenue. So, like if a lot of customers have a bunch of support tickets open for a really long time, a bunch of API errors,
[10:51] that could potentially correlate to them not wanting to like sign or redo their renewals. Whereas there be you could use that look at like the usage patterns and identify that somebody is on a self-serve or a lower
[11:05] tier, but they're potential enterprise customers. If I wanted to do all of this work today, you would essentially probably need a few engineers. So, you'd need somebody to maintain your data pipeline, you need somebody to do the ETL jobs for you. And
[11:19] sometimes they have other things to do as well. So, that means that you create a support ticket and you're waiting for them maybe it gets prioritized in another quarter. These are very real challenges that sales teams and customer-facing teams face. And so for a
[11:32] persona like that, Lovable, and data the Data Bricks connector becomes super easy because they don't have to worry about the back end side of it. As long as you have the connector in place, generally we recommend that it's a good practice
[11:45] when you're using Lovable to at least have some form of semantic layering so that Lovable knows what tables are available, what what those different tables do. But you don't have to go beyond that, meaning you don't have to specifically say this field does XYZ.
[11:57] The Lovable agent figures out what needs to which field does what, and then based on your use case, it will then do all of the the data plumbing for it, the API building for it, so
[12:09] the rendering of it, the UI. If you wanted to add email support, it'll add the email support for you. If you wanted this to be a production app that you take to other people, it'll add the SEO functionality for it. We have connectors
[12:21] for a bunch of these different things. So imagine looking at one of like the raw data like this, and then I I made a few demos to just showcase the prompt. Like essentially in this case,
[12:33] I'm asking it in my prompt to build me a deal saver. So the deal saver would basically identify customers that are at the risk of churn based on their usage, their error rates, and support tickets,
[12:45] and so on. And then also more importantly expansion pipelines. So if you if you notice we had that daily usage table, I wanted to use that to identify which ones might just be using self-serve, but they really could
[12:57] benefit from like an enterprise or a higher grade plan. And going from this prompt, it would essentially build a fully functional version for me where I can then go in and see that okay, if
[13:09] I'm somebody on my revenue team, I can go in and be like on my sales team, identify that these are the certain accounts that are churn. Why are they at churn? What's their usage trend looking like? This is coming all
[13:21] from the the data, by the way, that we have here. Obviously it's it's mock data, but like it's at scale to showcase that not only did it like give you or it built an app but it did all of the
[13:33] data plumbing for you in the back end so if I'm clicking each of these it's calling an API to build this view for me and it'll take care of all of the complex things for an API like it'll make sure that your API's have
[13:46] authentication it'll make sure that there is like pagination support and so on cuz like if it's pulling hundreds or thousands of rows of data then it's going to make sure that the API request is able to sustain that. So it's truly it's not just like a sample app that you
[14:00] that or like a demo it goes beyond that where whatever best practices that you would use for engineering the back end for a production ready app whether it's making sure that you have scalability for your API's whether you
[14:13] make making sure it's like your API's have like the right authentication methods and so on all of that stuff Lovable takes care for you. Before going into the questions I also want to showcase another example so
[14:26] similar example same data if you notice we have support tickets we have featured options and so on you'd go in and you'd tell Lovable to build it a in this case I just told it to build me an Intercom style
[14:39] application for managing my support tickets and it essentially builds that for you where instead of somebody manually going in exporting this data into Excel and then going in and then
[14:52] adding a bunch of the filters themselves that bottleneck is now gone so essentially you can go and focus on the problems that need to be solved so in this case it took all of my support tickets and it identified it correlated
[15:04] that to my error rates without me having to write a bunch of custom code. So to summarize that's the the the connector that we have that enables you to be able to read your data
[15:17] right now. Again just want to mention that for now we just have the machine to machine art support We're soon going to have the user to machine uh art as well so that you can the user can
[15:29] see the data that at their own level versus the service server principal level. And then right now the deployment is on lovable cloud. We don't have the deployment data bricks just yet, but that would be
[15:42] our next approach where you have the option of choosing whether you want to deploy to lovable cloud or you choose to deploy on data bricks. And then it supports both ways so you have the
[15:55] ability to read data out of it as well as write the data back as well. So it has it's a two-way connector that way. So we can pause there. I know that's a lot of information, but if you guys have any questions feel free
[16:08] to ask those now. We have a few minutes now.

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.