Dolt is the world’s first version-controlled relational database. Dolt lets you branch, fork, clone, merge, and diff your relational data, in all the same ways Git lets you work with your files.

In this blog post, we’re taking a look at another generative web app builder – Lovable. In previous posts I tested out Vercel v0 and then tried out Replit to see how they compare.

TL;DR

Getting right to the point… how did Lovable fare against Vercel v0 and Replit? I really wanted to like Lovable, but of all the three generative AI app builders I’ve tried so far, it left me the most frustrated. From my experience, I’d give Replit first place, Vercel second place, and Lovable third place.

Similar to Vercel, Lovable’s work was clumsy and unreliable. I quickly hit problems with it simply connecting to an external database. Neither Replit nor Vercel struggled to get connected to my Dolt database, but for Lovable, connecting to an external SQL database was somehow a challenge. It took four or five cycles of prompting and then testing the latest changes before Lovable was able to get a working database connection. Even more frustrating, it seemed to repeat the same mistakes later in the development process and one time seemed to randomly choose a different database to work with.

Overall though, my biggest complaint with Lovable is the same complaint I had with Vercel v0: neither of these app builders do any sanity checks on the code they create. They throw out a lot of code quickly, but that code often doesn’t work, and then you’re on the hook to find the brokeness. This creates an incredibly frustrating experience where the app builder keeps producing broken code, and you have iteration cycles over and over trying to get it to haphazardly stumble into working code. This is where Replit really stands out ahead of Vercel and Lovable. Replit provides an App Testing feature that performs basic acceptance testing and even lets you replay video of the UI testing it completed. This makes such a huge difference in a generative AI app builder. Replit would find basic issues and fix them before it turned things over to me to try. This made the experience sooo much more enjoyable and less frustrating. I wouldn’t recommend anyone use an app builder without this feature. Agents need tests.

So in the end, because of the lack of any automated acceptance testing, because of clumsy errors, and because of how frustrating and difficult it was to even get Lovable to use an external database connection correctly, Lovable is my least favorite app builder so far.

Building an Inventory Tracking Web App

Just like in my previous two blogs with Vercel and Replit, I’m again building a simple inventory tracking website to test out the Lovable experience. The web app I’m building allows you to do basic CRUD operations on inventory items, and also uses Dolt’s version control features to let you do things like see the history of all inventory changes, revert changes, or drill in and see the history of an individual inventory item. Here’s a screenshot of the final UI Lovable created for me.

Launch a Dolt SQL Server

The first thing we need to do is get a Dolt SQL server up and running for our web app to use. I’m using Hosted Dolt to run my Dolt SQL server. Hosted Dolt gives you a fully managed experience for running a Dolt server, including automatic backups, support for horizontal scaling through read replicas, automatic version upgrades, and more.

After logging into the Hosted Dolt website, I clicked on the Deployments link, and then on the Create Deployment button. A “deployment” is simply an instance of Dolt running on Hosted Dolt.

I named my deployment for this app “lovable-demo” and accepted the defaults on the other pages of the Create Deployment UI. After a few minutes, Hosted Dolt had spun up a Dolt server, ready to be used in my Lovable test.

If you’re following along, keep the deployment page open so that you can grab the database information later and tell Lovable how to connect.

If you scroll down on the deployment page, you’ll see instructions for connecting to the Hosted Dolt instance through the mysql tool. Use that command to open a SQL shell to our new Dolt server and run the following command to create the database, demo_db, on the server that we’ll be using for our application:

CREATE DATABASE demo_db;

Getting Started in Lovable

Now that we’ve got a Dolt database server running, let’s jump over to Lovable and get started building our app!

Here’s how I got started with Lovable, using the same prompt I used with Replit and Vercel v0.

A few minutes later, Lovable comes back with a high level plan for what it’s going to build. I approve the plan and then a few minutes later it summarizes what it’s done.

Connecting a Database

Now that we’ve got a base app created, we need to get it hooked up to our Dolt database. This was trivial with Vercel and Replit, but unfortunately marked the start of my struggles with Lovable.

As with the other app builders, I handed over my database connection information and asked the app builder to get connected.

After approving use of Lovable Cloud, Lovable got to work and declared victory!

At this point, I was feeling confident about Lovable and ready to start adding features to my app. I told Lovable to create a schema and some sample data and to always make sure to call dolt_commit() after making any changes, so that they get commited to the Dolt database, instead of just sitting in the working set. Lovable seemed to understand this, and instead of creating a script I could run to initialize the schema, like Replit and Vercel did, it gave me a hook in the UI. It felt a little odd that it added this feature to the web app itself, but I wasn’t too concerned yet.

Here’s the UI it created, with a big button to initialize the database by creating the schema and inserting some sample data.

My confidence was immediately dashed when I tried to use the button though.

Back to the prompt to let Lovable know it had screwed up and produced non-working code. Lovable told me that the problem was a lack of TLS/SSL connection, which felt really odd, since I already told Lovable upfront that TLS/SSL connection was needed, and it even told me that it had done so. 🤷🏻

It stumbled around helplessly, now asking me for the CA cert. This wasn’t something Replit or Vercel needed, but I gave it a shot and sent over the CA cert public key. Lovable again declared victory and again when I tried to initialize the schema got the same error as before. Instead of building app features, it feels like I’m just wasting my time complaining to a clumsy agent.

At this point, something seemed very wrong. Connecting to a database should be one of the most simple things any app builder does. Why is this so hard for Lovable when Replit and Vercel didn’t struggle with this?

I asked Lovable to show me all the details it was using to connect to my database. All the connection properties looked correct, and I noticed it was now reporting a new error in the logs that it hadn’t mentioned before: “table not found: inventory”. So it looks like the database initialization was failing because it hit an error trying to query the inventory table before it had created it?

Yet again, I had to redirect Lovable and again try to explain that I need it to create the table schema. It was really suprising that this was so difficult for Lovable. Both Replit and Vercel did this step automatically for me, but Lovable seemed to be totally baffled.

Hrmm… I asked Lovable to help me initialize the schema, but it’s now trying to add that to a new button in the web UI. Not at all what I wanted.

Finally! Lovable made working code that created a table and inserted some sample data. This was a pretty rough start with Lovable. For something so basic as hooking up a database connection, I was not impressed with how much Lovable struggled, especially compared to other app builders.

Publishing

Publishing with Lovable was fast and easy. I didn’t hit any issues and found the experience between Replit, Vercel, and Lovable to all be pretty similar. Not too much more to say here. All three app builders did a good job providing an easy and fast deployment experience.

Lovable Loves Making Broken Apps

Unfortunately, as I used my new app, I noticed lots of problems and gaps with it. Here’s one example:

Lovable was able to fix this easily, but it seemed like a pretty glaring omission to edit an item and not have the item’s current properties be populated correctly. Replit and Vercel both got this right.

A bigger problem was the error I got after that when I tried to submit an edit to an item.

This again came off as super clumsy. Lovable should know how the code it’s creating is going to work, and tripping over basic CORS permissions for the function endpoints came across as pretty inept when it knew how those server-side functions would be called. These are all problems I would expect to be easily caught with any amount of acceptance testing.

Adding Version Control Features

After stumbling through the basic CRUD web app and finally getting Lovable to connect my app to my database, things started going more smoothly when I asked Lovable to add some features to my app that use Dolt’s version-control APIs.

Commit History

The first feature I wanted to add is a log of all the changes in our inventory data. This is the same type of information you’d get from running git log in a Git project. In a Dolt database, we just need to run SELECT * FROM dolt_log; to read the commit log from the dolt_log system table.

Lovable did a great job with this and produced a working commit history page.

Next, I wanted to test out the menu item for resetting the database to an older commit.

Unfortunately things fell apart here. Again… any amount of UI acceptance testing would have caught this obvious error in the application. (This is where Replit really outshines both Lovable and Vercel.) Once I told Lovable about this error, it was able to quickly find and fix the issue.

Now that support for resetting to an older commit is working correctly, I also wanted to add support for reverting a specific commit. Just like in Git, resetting to a commit moves the database to be exactly as it was at that commit, so any changes from more recent commits are gone. In contrast, with revert, a new commit is created that has the opposite changes from a specific commit, in order to cancel out that commit – the commit still stays in the commit history, but the changes it made have been undone.

Here’s a look at the context menu that lets you reset and revert.

Lovable generated a similar popup for the revert action. Lovable did a good job coming up with appropriate text for this pop up.

This one worked on the first try! 🎉

Item History

The commit history view gives us a nice view of all changes across our database, but I’d also like to see all the changes for a specific inventory item. There are a couple ways we can do this with Dolt, but I asked Lovable specifically to use the dolt_history_<tablename> system table to see all rows in the table at each commit in the database. Let’s add that to our app next.

Lovable got this one right on the first try, too. Here’s the UI it created.

Displaying Diffs

Let’s add one last version-control feature to our app. The commit history view gives us a nice log of all the changes to the database, but it doesn’t show us exactly what row data changed. One of Dolt’s superpowers is computing fast diffs between any two points in the database’s commit graph. There are several APIs in Dolt for working with diffs. Here we’ve asked Lovable to use the dolt_diff() table function to compute the diff from before and after each commit.

Lovable declared victory, but when I tried the UI, it wouldn’t show any data. A pretty rookie mistake for Lovable to not even check that any data was being returned. Yet again, I had to tell Lovable it gave me code that didn’t work. Even more frustrating was the fact that the error it found seemed to be the same error it hit earlier when trying to get the app connected to our database. It’s pretty frustrating to see Lovable making the same mistakes just an hour or so later in the development process.

Unfortunately, Lovable wasn’t able to get this right on the second try either. The UI still wasn’t showing any data after I tried the code it said it had fixed. I had to again tell Lovable that it hadn’t actually fixed my app. This time, it did get it fixed, but the explanation of the problem left me even less confident about using Lovable. Despite the fact that we’d been using the same database and user for all the other parts of this app, it seemed to tell me that it had chosen to use a completely different database and user name for querying diffs. I’m still not sure why it would randomly choose to use a different database while adding features to my app.

Despite the suprisingly odd errors, Lovable did get this working (on the third try). Here’s the UI you see when you click on a commit to view exactly what row data changed in that commit.

Not a bad UI. I appreciated that Lovable styled the old value in a red, strikethrough font, and put the new value in green, making it very easy to quickly visually see the change.

Final Thoughts

I wanted to love Lovable, but I ended up feeling pretty let down. After using Replit and experiencing its App Testing feature, I just don’t think I can bring myself to use any app builder that naively spits out broken code without doing any testing. The experience overall was frustrating and clumsy.

There are a lot more generative AI tools out there to explore. Is there one you’d like to see us test out? Dolt’s ability to branch and merge allows AI agents to do some things that you just can’t safely do with other databases. Combine that with Dolt’s new built-in test engine and you can supercharge agents to do some neat work on your behalf.

If you want to talk more about generative AI tooling, or if you’re just curious about using a version-controlled relational database, come by our Discord and say hello!