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.

Lately, we've been on an AI kick. We've experimented with generative AI tools, like Claude Code and Cursor, and we've talked about how agentic workflows need the ability to sandbox database changes with branches. There are a lot of exciting developments happening at a rapid pace in AI tooling and we love trying them out and seeing which tools are more than hype. In today's blog, we're checking out Vercel v0.app to see how well it does building an inventory tracking web app that uses a Dolt database and Dolt's version control features.

Vercel is a cloud platform for front-end developers and web applications. It specializes in hosting modern web projects with a focus on speed, scalability, and developer experience. Vercel is the company behind Next.js, a popular React framework, but their platform is designed to work with many other frameworks, too (e.g. React, Vue, Angular, Svelte, plain HTML/CSS/JS). v0.app is Vercel's tool for building web apps using a conversational interface. You can literally start with nothing, type an idea for a web app into a prompt, and v0.app will start building out that idea right in front of your eyes.

I spent a couple days exploring v0.app and the experience was pretty interesting. There was a lot I liked about it, and ultimately I was able to fairly easily build a web UI that looks better than what I would've written by myself. However, there were many moments where I was left extremely frustrated with v0.app. I'd tell it to do something, but it created broken code. I'd point that out and it would tell me it found the problem and fixed it, but the app would still be just as broken. This happened several times, and almost always took a lot of back and forth to actually get it to fix the problem. That said, there were a few times when I'd ask v0.app to add something, and it did it correctly on the very first try. Those times were pretty magical, but overall, the experience felt a bit clumsy due to the number of times it produced broken code and couldn't figure out how to fix it. v0.app needs more refinement to improve its accuracy, but the overall experience, including the ease of deployment, is slick. It's got a lot of potential and could be a great fit for many small web apps, particular if you don't have deep skills in web app development.

Building an Inventory Tracking Web App

The other day, one of our customers was talking about how they used Dolt to build an internal inventory system, and how one of the biggest benefits they get from Dolt is the ability to easily get an audit trail and see exactly how their data has changed, who changed it, when it changed, etc. I thought something similar would be a good test for v0.app – a simple inventory tracking web app that lets you add new inventory, update inventory, and uses Dolt's version-control features to show you exactly how your data has changed. Here's a view of the final application I ended up with, to give you an idea of where we're headed.

Launching a Dolt Server through Hosted Dolt

Before we jump into the Vercel v0.app experience, let's spin up a Dolt server that our app will connect to. I'm doing this through Hosted Dolt. 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 site, 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 "vercel-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 for me that I could use in my v0 web app.

Keep the deployment page open so that we can grab the database information later and tell v0.app how to connect to our database.

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 v0.app

Now that we've got a Dolt server running. Let's jump over to v0.app and start building our application with Dolt. After creating an account and logging in, I went to the Projects page and hit the New Project button:

To get the new project started, I gave it a prompt describing the inventory tracking website I wanted to build:

Once that prompt gets sent, v0.app starts churning away on building an app for us! Along the way, v0.app gives you a very good summary of what the overall plan is, and what it's working on.

After just a few minutes, v0.app shows us a view of the UI design for our app and lets us know that it's got an initial version of the app ready for us.

Connecting a Database

So far, we've had a pretty smooth experience with v0.app. We gave it a high level description of what we wanted to build and v0.app seemed to understand and get us off to a really good start. Unfortunately as I got deeper into building my app, I started to see more clumsiness from v0.app.

The next thing I needed to do was get my database hooked up before we can publish the app and try it out. In my initial prompt, I told v0.app that I had an external database running on Hosted Dolt, and that I'd give it the connection information later. For some reason, v0.app seemed to conveniently "forget" that and tried to push me towards starting up a Neon database. I had a similar experience in another test app I built with v0.app, although in that case, it was even more egregious – I had my app working with a Dolt database and then for no good reason v0.app changed the code to stop reading the environment variables that had my database connection information, which of course completely broke the app. At that point, v0.app decided it should tell me that I needed to spin up a Neon database.

In the image above, you can see that v0.app also generated a SQL script that can be used to initialize the schema, and another that can be used to insert some sample data. Generating these were pretty convenient, although, they aren't actually runnable by default. I had to tell v0.app that the run button wasn't enabled, and it ended up converting them into a Javascript file that I could run. However... trying to run that Javascript file still resulted in an error. I told v0.app about that, and it changed to inline the SQL statements directly into the Javascript file instead of loading that file as part of the script. I had a very similar experience with the other app I built through v0.app. It was disappointing that such a simple, basic feature like a SQL script for schema initialization didn't work smoothly and consistently.

After more back and forth with v0.app, I was able to convince it that I did in fact know what I was doing and had an external database running on Hosted Dolt that we needed to use in the app. It instructed me to fill in the DATABASE_URL environment variable with the connection URL string for my Dolt database. Since Dolt is MySQL-compatible, the connection URL needs to follow the standard MySQL format for connection URLs.

In v0.app, I went back to the projects page, then looked at the details for my Inventory Tracker project.

In the top right corner of the page, there's a gear icon that shows a context menu. I clicked on the "Env Variables" menu item, then it brought me to a pop-up where I could add environment variables to my project.

Once I had that environment variable set, I went back to the setup-database.js that v0.app had created, and I tried to run it, but was met with an error about SSL/TLS. Servers running on Hosted Dolt require a secure connection, so I told v0.app that, and it updated the code to ensure SSL/TLS was being used. I also told it to please run CALL dolt_commit() after creating the initial schema and after creating the sample data, so that I had some well-organized Dolt commits.

This time I was able to run the scripts successfully! It was very exciting to see the app coming together and starting to work with our Dolt database.

Publishing the First Version

Now that our database connection is set up correctly, let's deploy the first version of our web app. In the top right corner of the v0.app UI, you'll see a Publish button.

After just a minute or two, my v0.app was running and accessible. Here's what the initial app looks like.

The UI looks okay, but nothing actually works. There's data in the database, but none of that is actually be queried here and showing up the UI. When I tried to create a new inventory item, all I got was a pop-up saying "Failed to create inventory item".

I Can See the Issue!

v0.app's catchphrase seems to be "I can see the issue!". After seeing that from v0.app many times, often several times in a row, I started believing less and less that v0.app really did see the issue and knew what it was doing.

Here's what v0.app told me when I reported that the add inventory item functionality wasn't working.

At first, I was feeling impressed that v0.app had found the issue and fixed it, but after I deployed and saw that the app was even MORE broken than before, I was less impressed. This time, the app didn't even load any of the UI and instead just showed me a single piece of text: Application error: a client-side exception has occurred (see the browser console for more information).

Surely, I thought, after those issues that v0.app would get it working on the third time. But no... the app was still completely broken, with the exact same error message. This time, I popped up the developer console to look what was going on. Sure enough, there was a Javascript error that I copied and then gave to v0.app.

This time when I published the app, it finally worked!!!

While I was happy to see the app working, the issues I hit to get this very first version working sure felt clumsy. v0.app really makes a LOT of mistakes! It stumbles over itself doing the most simple things and most worrying, it doesn't seem to be able to do simple checks of its work. Giving me code that doesn't even compile is an egregious and easily preventable mistake. Instead, v0.app seems to really live the YOLO philosophy. I can see the issue!

Adding Versioning Features

Now that we've pushed on v0.app enough to get to a basic, working app, let's start adding some features to our UI that expose the data versioning features from Dolt. The first thing we want to add is a new page that shows the commit history for our database. Before we add that page, let's make sure the app is creating Dolt commits so that we have some content in our commit log.

Credit where credit is due – v0.app did this perfectly on the first try. I created several new inventory objects and updated several others through the web UI, then logged into the Dolt database to verify that the commits were being created correctly. Next I asked it to start building a commit history page, along with a context menu for each commit that would allow us to reset the database back to that commit using the dolt_reset() stored procedure.

This also went well (or so it seemed at first). Here's the first version of the commit history page that v0.app created.

At this point, I felt like we were on a roll and making swift progress. This winning streak unfortunately ended when I noticed that the "reset to this commit" menu item didn't show up. I'll spare you all the back and forth messages on this one, but it took SIX prompts before v0.app could find what it had down wrong and fix it. Each time, it naively exclaimed "I can see the issue!", and each time it failed to produce working code. Multiple times, it told me it was adding more logging to help figure out the problem, only to never actually get anything logged. It switched out the library it was using for the context menu, and generally clumsily tried different things and stumbled around. Eventually, it finally was able to produce working code.

It was really cool when this finally worked, but I'll admit, it would have been a hundred times cooler if it had actually worked on the first prompt, like I was expecting. However, there was still a UI refresh issue where the commit history wouldn't be updated, even if I refreshed the page. This was another issue that was frustrating to get v0.app to correct and again took SIX prompts and attempts for v0.app to fix it. It ended up being an issue where the app was caching all the data from each query and then never refreshing that data for the lifetime of the app. It sure seems like that default behavior would be a problem in any application other than just caching static data.

Now that dolt_reset() is working correctly, let's add support for calling the dolt_revert() stored procedure. This will allow someone to select any commit in the commit history to revert. Dolt will create a new commit at the tip of the commit history that undoes all the changes in the selected commit.

v0.app nailed it on the first try this time. Each commit on the commit history page now has a new "revert commit" context menu action that will use the dolt_revert() stored procedure to undo the changes from the selected commit.

Item History

Let's add a couple more features to help us see how our inventory items have changed over time. The first feature we want is a report for how each inventory item has changed over time. We want to see any time the price was adjusted, or the stock was updated. The dolt_history_inventory system table shows us the full history of the table – there is a row in this system table for each row, at each commit in the history of the table. All I needed to tell v0.app was that the data could be found in the dolt_history_inventory table and to filter by the inventory item name, and v0.app was very easily able to extend the UI with this new data.

Here's what the generated UI looks like.

There's one more versioning feature I'd like to add to our app. We have a commit history page where we can see all the changes made to our inventory. It would be nice if we could click on each commit and see a diff of exactly what changed in that diff. All I needed to tell v0.app was to use the dolt_diff() table function to get the data, give it some hints on what arguments to pass, and tell it how to show the data.

v0.app did a good job with this one, too. Here's an example of the generated UI where you can see exactly what changed in a selected commit. The UI shows how the price or quantity changed, highlighting the old price and quantity in red, and the new price and quantity in green.

Final Thoughts

Overall, my experience with v0.app was pretty good. I'm not a front-end developer, so building a nice looking UI would have taken me a LOT longer, and likely not turned out as good as what v0.app produced. That said, there were several really frustrating moments during development and v0.app generally came across as pretty clumsy. There were multiple times when I would tell v0.app to do something, and it would completely fail, but still tell me it was fixed. As with other generative AI coding tools, I found that when I was more prescriptive about what changes I wanted, v0.app did a better job completing them successfully.

Despite those frustrations, I still left this experience ready to build more with v0.app. It was pretty easy to build an app in v0.app that leverages Dolt's version-control features, but I didn't experiment with Dolt's branching and merging features yet. Those features could be really useful for testing out schema changes, or for developing multiple larger features in parallel. Stay tuned for a follow-up exploring some of those ideas.

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