Over the past year, we’ve been having fun exploring all the generative AI tooling coming out for developers. We’ve tried out coding assistants like Cursor and Claude, and dug in to a bunch of app builders like Lovable, Bolt, Vercel, and Replit. It’s been fascinating to see how generative AI tools have begun to reshape how software is written and how applications are assembled.

App builders allow you to build some pretty impressive projects without much effort at all. Those projects often need some sort of database, and every app builder we tested defaulted to including a traditional database – not a version-controlled database, like Dolt. Two of the better app builders we tested, Replit and Vercel, both prefer to use Neon, which has some qualities of a version-controlled database, but not the full feature set. Neon supports copy-on-write branching, which means you can instantly spin up an isolated copy of the full database to work in. This is analogous to Dolt’s branches, but Neon doesn’t provide any way to diff the changes on those branches, or any way to merge the changes on those isolated branches back into other branches. Neon also limits you to a restore window on how far back you go with historical queries and rollbacks.

In this blog post, we explore why these app builders chose Neon as their default database to use in the applications they build, how Dolt compares, and how Dolt’s full set of version-control features could further improve app builders.

Why Neon?#

After seeing a couple of these app builders select Neon as their default database to use when building apps, we were curious why they chose Neon over other databases and how they were using Neon’s features.

Neon’s blog provides an answer to this question:

Since Replit has millions of users, adding Postgres support meant managing and scaling potentially millions of databases. Replit started to look for a partner that is aligned with their pursuit of great developer experience and can match their consumption based pricing mode.

This made Replit choose Neon so they can provide Postgres databases for their users powered by the modern serverless platform. Another added benefit is that Neon is built for the cloud and offers a usage-based pricing model, making it a cost-effective solution for companies like Replit which runs a large fleet of apps with variable usage. Since some of the apps only have episodic usage they really benefit from the ability of Neon to scale serverless Postgres to 0.

This highlights a few reasons why Neon is compelling for app builders like Replit:

• Postgres – The statement starts off with an assumption that Postgres support is a requirement, so it’s worth explicitly digging into that. Postgres has become the preferred open-source database engine and there are good reasons why Replit started their database provider search with the assumption that it needed to be a Postgres experience. Developers are comfortable with Postgres’ dialect and feature set and many prefer those over other database engines. Postgres also has awesome performance. Compared to MySQL, our testing shows that Postgres performs about twice as well as MySQL on sysbench measurements. Last but not least, Postgres has a vibrant ecosystem of extensions, with many, like PostGIS, that are extremely popular.
• Platform Scale – The main point emphasized in the Neon blog is that Replit needed a database management platform that can scale to support the millions of users on Replit and operates on a consumption-based pricing model. Like many online data services, Neon bills computation and storage usage separately. The blurb also calls out “scaling to zero”, meaning that if you aren’t using your Neon database currently, then you don’t need to pay for any compute resources. However, you’ll still be paying for storage costs, so “scaling compute to zero” is probably a more accurate, albeit less flashy, tag line to describe this quality.

The blurb above also hints at prioritizing “developer experience”, but doesn’t go into detail about specific features, so we took a closer look at how Replit uses Neon. Here are the primary Neon features that are used for a slick developer experience in Replit:

• Fast, Isolated Branches – Neon gives you the ability to create fast branches that take the current data in your database and creates an isolated branch where you can make changes. These branches are copy-on-write, so creating a new branch is instantaneous, no matter how much data you have stored in your database. They let you iterate on your database without affecting the production data or schema. When you’re done experimenting, you can swap out branches with each other, for example, replacing the production branch of your database with the development changes you just made. There are some pretty big limitations on what you can do with branches once you create them though, which we’ll dig into shortly.
• Point-in-Time Rollback and Time Travel – Neon databases keep a “restore window” where you can instantly roll back your entire database to any point in time recorded in that restore window. Similarly, the time travel feature lets you query older versions of your data, but is also limited to the same restore window. There are a few limitations to be aware of here, such as how much time this restore window covers (a maximum of 30 days for the best plan), and there’s currently no way to diff two points in the database to understand exactly what changes have been made.

How Does Dolt Compare?#

Let’s deep dive into those features and see how they compare to Dolt…

Postgres#

Dolt is a MySQL-compatible, version-controlled database. Dolt doesn’t contain any source code from MySQL, but it implements the MySQL dialect and wire protocol so that any MySQL tool can work with a Dolt database. Over the years, we’ve gotten increasingly more frequent requests for a Postgres version of Dolt, so we started building Doltgres – a PostgreSQL-compatible, version-controlled database. Dolt had a few years head start and is our mature, production-ready database. Doltgres is in beta currently, and we’re rapidly adding more support and heading towards a Doltgres 1.0 release, at which point we’ll declare it ready for production usage, too.

The main things people tell us they love about Postgres are 1) the dialect and feature set, 2) the ecosystem of extensions, and 3) the performance. Doltgres implements the same SQL dialect and feature set as Postgres and we are working on filling in the remaining feature gaps. Extensions are another area where we feel confident about our progress. Earlier this year, we released alpha support in Doltgres for loading Postgres extensions. Last but not least, we’ve been making major strides in performance over the past few years. When we first started building Dolt, our implementation was about 10x slower than MySQL on sysbench tests. We’ve done a TON of work over the years to improve that, and just this month we announced that Dolt is now as fast as MySQL on sysbench tests. This was a big milestone for us, but we aren’t resting on any laurels. In our own testing, we see that Postgres performs about twice as well as MySQL on sysbench tests. At this scale, the query latency differences are typically around a couple of milliseconds, which tends to be well within the acceptable latency range for most applications, and often dwarfed by network latencies anyway, but it’s definitely an area where we’ll be continuing to focus and optimize.

All in all, we know developers love Postgres and we’re getting very close to a production-ready release of Doltgres to fill this need. However, to be completely fair, we’ve got to call out that Neon takes the win here in this category.

Platform Scale#

The ability to scale to support millions of users, while still using compute resources efficiently was another key callout on why Replit chose Neon, so how does Dolt compare here?

There are several ways to provision and operate Dolt databases. One easy option is our Hosted Dolt platform. With Hosted Dolt, we provision, run, and operate your Dolt server for you. We take care of backups, perform automatic version upgrades, and provide monitoring. This is a great approach for ease of use, since all you need to do is use the database. Hosted Dolt will run your Dolt server for you, and you can create any number of branches on it for different features or developers. This is typically the approach we recommend to most customers, since it’s the easiest way to run a Dolt database.

There are options in Hosted Dolt to help you scale up horizontally as the load on your database increases, such as adding read replicas to your cluster, but it’s not the same as the serverless scaling model that Replit was looking for. Hosted Dolt also won’t get you the “scale compute to zero” quality that Neon advertises – you’d have to shut down your Dolt server, then reprovision another one from a backup when you want the sever to come back. To do something more similar to Neon, you could take advantage of Dolt remotes. Just like the remote concept in Git, in Dolt a remote is another copy of your Dolt database. Remotes allow you to store your data on a filesystem, behind a generic HTTP API, or in AWS or GCP. You can launch a Dolt server to front that remote data, then when you’re done with compute, just shut down the server. Your data is still stored on disk or in AWS or GCP and you can start up a server again whenever you need to run compute on your data. This gives you a “scale compute to zero” model where you only have to pay for the data storage costs if you don’t need any compute processing.

This one is a bit of a mixed bag. Dolt gives you the pieces to scale up and down, including scaling compute to zero, but currently requires you to assemble them. Because Neon provides this more directly in their serverless platform, I give them the win here.

Storage Efficiency#

Under the hood, Dolt and Neon take very different approaches to storing data. Understanding these differences in the storage layer also makes it much easier to understand why supporting diffing and merging is easier for Dolt, but much harder for Neon.

Neon’s storage layer tracks “timelines”. A branch is essentially a new timeline that starts from a point on an existing timeline. In Neon’s storage, there are “image layers” and “delta layers”. An image layer is a snapshot of all key-value pairs for a key range at a specific point in time. The size of an image layer aligns with the size of a page of memory, 8KB. Delta layers are created after an image layer to represent the changes that are being made on that timeline. When you query data, Neon will load the image layer for the appropriate key range, then read and apply all delta layers to find the current data values. As these delta layers accumulate, a background process periodically compresses them and creates a new image layer on the timeline.

Dolt’s storage engine uses a data structure known as prolly trees, a combination of content-addressed chunks with Merkle trees, which is very good at enabling efficient structural sharing. Dolt’s chunks are also smaller than Neon’s image layers/pages, which helps with more efficient storage and more efficient reuse of those stored chunks. In Dolt, chunks are variable size, targeting a size of around 4KB, but chunks are often smaller, even just a couple hundred bytes. When a single row changes a small chunk of the storage datastructure needs to be updated. Another key difference in storage efficiency is that Dolt is able to reuse chunks across branches, while Neon does not reuse image layers across timelines. A branch in Neon reuses the most recent image layers from the source timeline, but after branching, those image layers can’t be reused on other branches.

To sum up, both Neon and Dolt have different forms of structural sharing to store data efficiently, but Dolt’s structural sharing is more granular and more widely used across the database. The end result of this is that Dolt can store data more efficiently, and give customers lower data storage costs.

Version Control Features#

Things start to get a lot more interesting for Dolt as we get into the version-control features, like branching, diffing, and merging. Because Dolt supports vastly more sophisticated version-control features than Neon, this category is a resounding win for Dolt.

Fast, Isolated Branches#

Both Dolt and Neon allow you to instantaneously create branches of your database, and those branches give you an isolated space to make changes without affecting the data on the main branch of your database. However, the similarity stops here. Neon lets you create branches, but after that, there’s not much you can do with them other than query them. You can’t diff branches to see what’s changed on a branch, you can’t merge the changes from that branch into the upstream branch, and you can’t refresh that branch with the latest changes from the upstream branch.

Diffs#

The ability to diff and merge branches is core to a version-controlled database. These are also very technically challenging operations to pull off. Dolt is able to do efficient diffs and merges because Dolt’s storage layer is aware of versioning. Versioning is a core concept deep inside of Dolt, not extra metadata added on top of a traditional database storage layer. This also means that versioning operations are extremely efficient with Dolt, thanks again to structural sharing through prolly trees, like we described earlier. When you diff a table in two different branches, the processing time for computing that diff scales linearly with the size of the diff – not with the size of the data in the table. So if your table has 100 million rows in it, but only one row is different between your two branches, Dolt will compute a diff instantly since it can very quickly detect that only a single row is different between the two tables. This diff detection is so fast because Dolt can quickly compare the two prolly trees and see they share all the same content addresses, except for a single chunk.

Being able to diff your data also opens up new opportunities for AI agents to do more for you. One of the main reasons that AI agents have been so successful so quickly with coding tasks is because LLMs currently best understand our world through text, and programming is very much a text-oriented activity. What would happen if you allowed AI agents to understand the changes in your database, through textual diffs, the same way AI agents understand the changes in our code bases through code diffs? Agents could analyze how your data is changing, alarm on anomalous changes, suggest schema optimizations, and even predict future customer behavior. There’s an untapped opportunity here for app builders to enable agents to more deeply understand the applications they’re building. It doesn’t seem very controversial to state that an agent that can understand how your application’s data is changing could outperform an agent that doesn’t have that extra context.

Without the ability to diff branches, you just can’t even answer basic questions like “what changes have I made on my dev branch?”. Branches are an absolute requirement for a version-controlled database, but without diffing and merging, branches are pretty hamstrung.

Merges#

Not being able to merge a branch into another branch is another painful limitation for Neon. Branches, in Neon, are more of an isolated, throwaway working space. You can quickly spin up a branch and make whatever changes you want, but when you’re ready to publish those changes, you have to remember them and manually reapply them on the production branch. This is a very easy place to make a mistake, especially considering that you can’t diff your branch to determine exactly what you changed. In practice, you’re limited to using a tool or ORM that will manage migration scripts and replay the changes for you, since manually remembering changes and reapplying them to production would be a recipe for disaster. To be fair, Neon does allow you to swap the “pointers” for branches, so if you just have a single developer and a single change in flight, you could, in theory, just swap the production branch pointer for your dev branch pointer to publish those changes. However, that assumes that no changes were made to the production branch the whole time while you were developing the new feature, since you’d lose all those changes on the production branch by swapping the branch pointer, so in reality, this isn’t an approach that’s likely to work well for most systems.

Point-in-Time Rollback and Time Travel#

Neon’s support for point-in-time rollbacks allow you to roll back the data and schema in your database to any point within your configurable “restore window”. For free Neon accounts, this window is the last six hours, but for paid plans you can go up to 7 days with the Launch plan, and up to 30 days with the Scale plan. Neon has to store additional metadata alongside your data in order to support these point-in-time rollbacks, so the larger your restore window, the more space your database will need for that metadata. Because Dolt uses a completely different storage layer that has versioning built in from the start, there is no need for Dolt to limit you to a restore window. Dolt allows you to roll back or inspect any point in time on any branch in your database. Want to go back and see how your data has changed over the past year? That’s easy with Dolt, but just not possible with Neon’s much more limited restore windows.

Point-in-time rollbacks are a really cool feature. Because Neon limits you to an arbitrary restore window and Dolt allows you to do point-in-time rollbacks from any point in any branch in your database, this one is another clear win for Dolt. The obvious benefit here is that with Dolt, Replit would be able to do point-in-time rollbacks to ANY previous commit in the history of your database.

Neon’s restore window is also what limits how far back you can go with their time travel feature, which lets you query your database as it existed at an earlier point in time. Because of Neon’s restore window limitation, no previous versions past the restore window can be accessed. So even if you don’t want to completely roll back your database, the restore window still greatly limits you on how many historical versions of your data you can access. Want to see what your inventory data looked like last year? You can’t do that with Neon’s time travel feature because the restore window only covers at most a month of versions. Need to support compliance requirements and audit the provenance of all data in your database? You can’t do that with Neon. In contrast, Dolt lets you track the full history of every single cell of data in your database. The root cause of this limitation is because version control data is added on top of Neon’s storage layer, and is not an integral part of how the data is stored.

Multiplayer Mode#

App builders today tend to perform best as single-user tools. As they become more popular, it will be important for them to grow into collaborative environments. Multiple developers, end users, or AI agents will all be working on the same application simultaneously to add features, adjust schemas, generate seed data, or experiment with new ideas. For app builders to make this leap, the challenges is coordination – not concurrency. What matters is not just that changes can be made safely, in isolation, but that changes can be understood, reviewed, and reconciled when multiple lines of work evolve in parallel.

Neon’s branching support is great at creating cheap, isolated environments, but those branches are effectively dead ends. Like we explained earlier, once two branches diverge, Neon provides no mechanism to diff them, explain how they differ, or merge them back together. This forces app builders into serial workflows: one branch “wins”, while others are manually replayed or discarded, and parallel development becomes increasingly difficult as the number of actors grows.

Dolt enables a fundamentally different model, something more akin to a “multiplayer database”. Each user, feature, or AI agent can operate in its own branch, with first-class support for diffs, three-way merges, and conflict detection at the data and schema level. Changes can be inspected, reviewed, commented on, selectively merged, or rolled back, making collaboration explicit rather than implicit. For app builders, this transforms the database from backend infrastructure into an active participant in collaborative application development.

Wrap Up#

App builders are ushering in a new era in how applications are created. These platforms let you stay focused on your product ideas instead of the mechanics of implementation. It’s clear why Neon has emerged as a strong default choice for several of today’s most popular AI-driven app builders. Its Postgres support, serverless scaling model, and fast, isolated branches align well with platforms that need to spin up millions of short-lived applications with minimal operational overhead. For single-developer workflows or ephemeral experimentation, Neon’s branching model works well enough and delivers a smooth experience for app builders.

However, as applications grow more complex, and as collaboration shifts from a single developer to teams, users, and AI agents all working in parallel, the limitations of branch-only workflows become increasingly apparent. Without the ability to diff, merge, and reason explicitly about how data changes over time, branches become disposable rather than composable. This forces serial workflows, manual reapplication of changes, and a reliance on external tooling to compensate for missing database-level capabilities.

Dolt takes a fundamentally different approach: version control is built directly into its core storage engine, which enables a more collaborative, inspectable, and ultimately more powerful development model. As app builders evolve toward truly multiplayer experiences, and as AI agents become first-class contributors to applications, we believe version-controlled databases that can explain and reconcile changes will prove to be indispensable.

If you’re experimenting with app builders, or trying out Dolt in your projects, we’d love to hear what you’re building and what kinds of version-control features are helpful. Come by our Discord to talk to our engineering team and share your ideas!