Doltgres is a PostgreSQL-compatible database with Git-style version control built in. It gives you all the power of SQL with the ability to branch, merge, diff, clone, and push your data, using the same model you already know from managing your source code with Git. Doltgres implements the PostgreSQL wire protocol, syntax, and type system so that you can use it just like you use PostgreSQL.

We first announced Doltgres in November 2023 as an Alpha, then launched the Beta in April 2025, and now we’re announcing our next major milestone: Doltgres 1.0, coming August 6th. This date is pretty special for us here… it’s the eight-year anniversary of DoltHub! Eight years of hard work leading up to a production-ready, PostgreSQL-compatible versioned database! Not too shabby.

In this post, we’ll explain what 1.0 means for Doltgres, share what we’re focused on in the next few months, and let you know how you can help.

What Does 1.0 Mean?#

Doltgres reaching 1.0 is our signal that Doltgres is ready for production use. That means:

• Correctness Your queries reliably return the correct results, matching what PostgreSQL returns.
• Storage Stability The storage format is locked in, and we won’t make breaking storage serialization changes in the 1.x releases that require migrating your data.
• Performance Query latency is within an acceptable range of PostgreSQL’s performance. We’re shooting to be within 3x PostgreSQL’s latency for key sysbench measurements.
• Compatibility The tools, libraries, ORMs, and frameworks your team already uses work correctly with Doltgres, too.

Six months ago, we gave an update on Doltgres’ progress in the State of Doltgres. Since then, we’ve made significant progress towards a 1.0 milestone. Here’s what we’re focused on in the home stretch towards 1.0.

Correctness#

One of our key tools for testing SQL correctness is the SQLite SQL Logic Test suite. This is a large, open-source test suite originally developed by SQLite containing over seven million test queries covering a wide range of SQL expressions and statements. We’ve forked this module and added many more tests, and we run these against Dolt and Doltgres to measure compatibility and ensure that we’re returning correct results.

We’ve been tracking our progress on this suite since the early days of the project when we were only able to execute 70% of the statements correctly. Today, we’re passing a little over 96% of the tests correctly, and we’re digging into the failing tests to categorize them and tackle the discrepancies.

Our goal for 1.0 is to reach 99% SQL Logic Test compliance. Every percentage point matters here. At this scale of testing, 99% represents millions of individual queries and results that must match PostgreSQL exactly.

Storage Stability#

One thing that makes our major version releases meaningful is the storage format guarantee they carry. For Doltgres 1.0, we’re committing to a stable on-disk serialization format, just like we did for the Dolt 1.0 launch back in 2023. This means no data migrations will be required for any new features we add in the 1.x line of releases. Changing the storage serialization format requires data to be migrated from the old format to the new format, which is disruptive and inconvenient to customers, so we give this guarantee that the storage serialization format won’t change in the 1.x line. When we start to think about a 2.0 release for Doltgres, there may be compelling features or optimizations that require a serialization format change, but we don’t make those changes lightly. There’s a very high bar for backwards incompatible storage serialization changes once we’ve given our customers the green light to use a storage format in production.

Performance#

We’ve been benchmarking Doltgres performance from the beginning, and we continue to chase down performance bottlenecks as we find them. Because Doltgres uses the same query engine as Dolt (our MySQL-compatible database product), it has access to all the performance improvements we’ve done for Dolt. However, PostgreSQL raises the performance bar from where MySQL set it. In our testing, we found that PostgreSQL is more than twice as fast as MySQL, so we’ve been working hard to find more optimizations, do more performance testing, and keep inching closer to PostgreSQL’s performance.

Our performance goal for 1.0 is to get sysbench results for Doltgres to within 3x of PostgreSQL. We’re currently right on the cusp of achieving this, with a current performance multiplier of 3.3x.

We continue to find and fix performance issues as they come up. If you encounter a query that is unexpectedly slow, please file an issue and we’ll dig in and find a way to make it fast for you.

Compatibility#

PostgreSQL’s ecosystem is vast. Different clients, libraries, ORMs, and tools all speak the PostgreSQL wire protocol in subtly different ways. They use different combinations of the simple and extended query protocols, rely on different parts of pg_catalog, and have different expectations about types, encodings, and error messages.

For 1.0, we want to ensure broad compatibility across the PostgreSQL tools most teams are using. This means testing and fixing issues with popular clients and libraries including:

• Client libraries: psycopg2, asyncpg, pgx, pg (node-postgres), and more
• ORMs: Prisma, SQLAlchemy, ActiveRecord, Django ORM, Hibernate, and more
• Tools: psql, TablePlus, pgAdmin, Dolt Workbench, and more

Many of these tools, especially the ORMs and higher-level tools make extensive use of the system information tables in pg_catalog to introspect your schema and display it in a UI, generate migrations, or validate configurations, so this work also includes filling in gaps and fixing incorrect data in those tables so that tools can access the information they need to work correctly with Doltgres.

We’ve already done a lot of work in this area. We’ve previously written about supporting Prisma, Laravel, Django, SQLAlchemy, and KnexJS, but there’s more to do. We want to find the issues with popular tools before our customers do. This is another place where your real-world usage can help us find gaps. If you hit any issues with Doltgres and a SQL client library, ORM, or other SQL tool, please report it to us so we can dig in and fix it.

Other Features#

Beyond the core themes of correctness, storage stability, performance, and compatibility, there are several features we’re actively developing and vetting for Doltgres’ 1.0 launch:

Remotes and Push/Pull Remotes are a powerful feature that allow you to work in a distributed mode, by pushing data to remotes and pulling data from remotes, just like Git remotes. We’re working to ensure these features are fully supported in Doltgres, enabling the same kinds of remote collaboration and decentralized workflows that Dolt and Git users are familiar with.

Dolt Replication Protocol Doltgres supports two types of replication: the PostgreSQL replication protocol and a Dolt-specific replication protocol. The PostgreSQl replication protocol allows you to run DoltgreSQL as a replica of a PostgreSQL server. The Dolt-specific replication protocol allows you to set up more advanced primary/replica configurations and includes features for high-availability and hot-swappable replicas. We’re working to finish testing this support and make sure it’s ready for production.

Garbage Collection Improvements As databases accumulate history, they can grow large. Garbage collection helps keeps that growth manageable by cleaning up unreachable data that is no longer needed. Doltgres already supports the standard manually invoking garbage collection with the dolt_gc() stored procedure, but we don’t want to launch 1.0 without the latest garbage collection improvements: incremental garbage collection and automatic garbage collection.

Try Doltgres and Send Us Issues#

The best way you can help us get to 1.0 is to use Doltgres on real workloads and tell us what breaks.

Install Doltgres and try it with your existing PostgreSQL application. Point your ORM at it. Run your migrations. See what works and what doesn’t. Every issue you report makes the product better, and we love to move fast on customer-reported issues.

• Install: brew install doltgres or download from our GitHub releases
• Report issues: Create an issue in the Doltgres repository

We’re very excited to get Doltgres to 1.0 and announce that it’s ready for production workloads. If you want to be part of getting us there, now is a great time to try out Doltgres! Come by our Discord and let us know how your experience goes.