2026 has been a big year for DoltHub so far. In May, we launched Dolt 2.0, our second major release of the world’s first version-controlled SQL database. Dolt 2.0 brought performance parity with MySQL, as well as much better disk usage and a lot of new features. Then in August, we launched Doltgres 1.0, signaling that the Postgres-flavored version of Dolt is ready for production use. On top of those two major releases, we’ve also seen a surge of new interest in Dolt as an enabler for agentic engineering, especially through the agent memory tool Beads, which uses Dolt as its storage backend. And we launched two new database products written with agentic engineering, DoltLite and DumboDB. All in all, 2026 has been a year of accelerating interest and usage for all our version-controlled database tools, with agents pouring fuel on the fire.

All this new attention has also shifted our engineering roadmap a bit. We publish updates to the roadmap at the start of every quarter, and Q4’s update just went out. In line with the increased number of eyeballs, this update is one of the largest ones we’ve ever released. Its main focus is Doltgres, where new customers are rapidly finding and filing issues for compatibility gaps.

Let’s take a look at the major themes.

Row-level security#

We’ve written a lot in the past about how Postgres’s surface area of features is just much, much larger than MySQL’s, but we continue to be surprised by just how much larger, and how many of these features are used by a critical mass of potential customers. One such feature is row-level security, which is a way to configure your server to return different rows for the same query to different users, or to prevent certain roles from inserting certain values or updating certain rows. It’s complex and can be used to enable a lot of different use cases.

We’re building support for row-level security into Doltgres now, and you can expect it before the end of the year.

Support for PostGIS and other popular Postgres extensions#

Postgres has a robust extension framework most commonly used to define new types and functions that operate on them. Some of these are very widely used, being part of standard Postgres in all but name. These include PostGIS, which supports spatial data and queries, as well as pgcrypto, which handles a variety of cryptographic concerns. Doltgres 1.0 shipped without support for these critical features, but we’re racing to close that gap.

Expect support for PostGIS and pgcrypto by the end of the year.

SELECT ... FOR UPDATE#

Since the launch of Dolt 1.0, exclusive row-level locking has been one of our most requested features. In the traditional database world, these locks are how you make sure that two concurrent clients can coordinate their writes safely. But Dolt took a very different approach to solving this same problem from the very beginning, merging concurrent writes together and detecting conflicts without any locking. For whatever reason, this alternate approach has worked great for Dolt’s customers but isn’t good enough for Doltgres’s customers. They are using tools that require the same row-level locking semantics that Postgres uses to make their applications work as expected.

So we’re fixing it. Expect row-level exclusive locks by early next year, for both Dolt and Doltgres.

Different transaction isolation levels#

SQL transactions can declare different levels of isolation from other concurrent transactions to control what writes from other sessions become visible to them, and when. The most common isolation level in the MySQL world is REPEATABLE_READ, which means that a transaction will not see writes committed by other transactions until it issues a COMMIT or ROLLBACK statement. This is what’s implemented by Dolt’s session management logic.

But in the Postgres world, the default is READ_COMMITTED, which means that a transaction will begin seeing updates from other transactions as soon as they are committed. Dolt has never supported this isolation level, and it’s a lot of work to do so. But this is what our new Doltgres customers need, so we’re building it.

Expect READ_COMMITTED support early next year, released in tandem with row-level locks.

But wait, there’s more!#

Our roadmap is deliberately curated to include only large-scale initiatives and frequently requested features. But we’re also constantly at work on bug fixes and smaller features requested by our customers. Read the blog or watch our GitHub issue queue to stay up to date on these frequent changes. You can also join the DoltHub Discord to discuss anything on your mind with our engineering team in real-time.

Our roadmap also currently excludes our two agent-written database products, DoltLite and DumboDB. These are both evolving so rapidly that any roadmap commitments would quickly become obsolete. But as these products mature and we get ready for their 1.0 releases, we’ll definitely add them to the roadmap.

Conclusion#

2026 is shaping up to be our biggest year of releases ever, and our roadmap is one of the most important ways we communicate our plans to our customers. Remember: paying customers get write access to those plans.

Have input on our roadmap? Anything important to your use case that we’re not working on but should be? Visit us on the DoltHub Discord where our engineering team hangs out all day. Hope to see you there.