DoltHub Blog - Latest Posts

Doltgres 1.0

Zach Musgrave — Thu, 06 Aug 2026 00:00:00 GMT

At DoltHub, we’ve been in the version-controlled database business for eight years now. We made Dolt, the world’s first version-controlled SQL database, and after a few years in beta it hit 1.0 in 2023. It’s now running on thousands of machines around the world every day, powering as many interesting version-controlled applications.

Since we first announced Dolt, we’ve gotten one question more than any other:

What about a Postgres version?

Dolt speaks the MySQL dialect and wire protocol, so it’s compatible with any tool or library that can connect to MySQL. At the time we started writing the database, MySQL was far and away the most popular free SQL database, but that was already starting to change. Postgres was gaining ground and continues to do so. Today, few companies are building new products on top of MySQL. Nearly everyone chooses Postgres for new work. This means that most of the new generation of database application engineers are familiar with Postgres’s SQL dialect, toolchain, and ecosystem.

Doltgres is our way of meeting those customers where they live. Doltgres combines the performant Git-style version control that makes Dolt unique with full Postgres compatibility. Your favorite Postgres workbench or connection library can connect to Doltgres just like a normal Postgres database, but with extra system tables and functions for full version control of all schema and data.

It’s been almost three years since we announced Doltgres’s alpha release and about 18 months since we announced Doltgres Beta. Today is the 8th anniversary of DoltHub Inc., and we’re excited to announce that Doltgres has finally achieved its 1.0 release.

What does 1.0 mean?#

Doltgres 1.0 means four things.

Forward Storage Compatibility
Production Performance
Postgres Compatibility
Stable Version Control Interface

Forward Storage Compatibility#

All future 1.x versions of Doltgres will be backwards compatible with 1.0.

Dolt’s storage engine has gone through a couple of backwards-incompatible changes since its original beta, including one that required existing customers to migrate their data. Doltgres has likewise explored different ways of storing and versioning its data leading up to the 1.0 release, but managed to do so in a way that didn’t require any customer data migration.

With Doltgres 1.0 we are committing to the current storage format used for all data. There will be no backwards-incompatible storage changes in any 1.x release of Doltgres.

Production Performance#

Doltgres 1.0 has production level query performance.

Dolt is faster than MySQL on the standard sysbench performance suite. Doltgres uses Dolt’s underlying storage and query engine, so that same performance applies to Doltgres as well.

However, MySQL itself is roughly 2-3 times slower than Postgres. This means that Doltgres is about 2.7 times slower than Postgres as of this launch. But there are two pieces of good news here. First, databases are very fast. We’re talking about the difference between 0.2 milliseconds for a query versus 0.5 milliseconds. In practice, any difference in performance for typical OLTP queries in a database-backed application is dominated by network latency, with the database itself being a relatively small part of overall measured latency. Second, we’re continuing to make improvements to Dolt’s performance over time. We started out 5x slower than MySQL and have now passed it in performance.

Doltgres is slower than Postgres but still more than fast enough to handle your production workload. And it will only get faster in future releases.

Postgres Compatibility#

Doltgres 1.0 is 99% Postgres compatible.

Doltgres measures Postgres compatibility in two primary ways:

A test suite of 5.6 million SQL queries that are verified against real Postgres for correctness. These originally come from the sqllogictest project, which was developed for SQLite3. Doltgres currently scores over 99% on this suite.
Comprehensive integration tests of different client libraries in different languages. Currently over 20 have official support, with more being added all the time.

Compatibility has been our highest priority for the last year of development. We have imported many hundreds of real-world Postgres dumps and written tests for dozens of client libraries. This means we’re very confident your Postgres schema and queries will work in Doltgres. If you find that they don’t, we promise to fix the problem in 24 hours.

Stable Version Control Interface#

Doltgres 1.0 version control interfaces will not change.

The system tables and functions that implement the version control features of Doltgres have been battle-hardened by years of production use in Dolt. You can write applications that use them and be assured they will not change in any 1.x release of Doltgres.

We’ll of course continue innovating by adding new version control features and making the existing ones work better and faster. But the code and queries you write today will continue working for every 1.x release.

What’s next?#

Doltgres 1.0 is just the beginning. You can read our roadmap for details, but here are some highlights.

Support for common extensions including PostGIS
Vector indexes
Row-level security
Collation support
Better DDL support

Paying customers get write access to the roadmap.

Conclusion#

If you’ve been interested in a version-controlled SQL database but have been waiting for the Postgres version, this is your signal to try it out now. The current version has been years in the making and represents a lot of hard work and innovation by the team. We’re very excited for you to try it and to tell us what you think.

Questions about using the 1.0 release? Find a bug you want fixed? Come by our Discord to talk to our engineering team and meet other Doltgres users.

No Index GroupBy Optimization

James Cor — Mon, 03 Aug 2026 00:00:00 GMT

You may have heard that we’re launching Doltgres 1.0 on August 6th. As part of the launch, we’ve been improving Doltgres’s performance on Sysbench Latency. This blog focuses on one of the optimizations we made, specifically focusing on groupby_scan.

Discovering the Optimization#

Doltgres reuses large portions of Dolt and GMS, so it’s not unreasonable to assume that Doltgres should perform similarly to Dolt. Comparing latencies across the different platforms helps us highlight where we are underperforming and where we should focus our attention.

benchmark	dolt	doltgres	mysql	postgres
covering_index_scan	2.35	2.48	17.01	17.95
groupby_scan	144.96	147.61	144.97	40.37
index_join	1.93	2.30	3.43	1.82
index_join_scan	1.32	1.70	4.18	0.67
index_scan	219.36	493.24	350.33	179.94
oltp_point_select	0.25	0.39	0.19	0.15
oltp_read_only	5.00	6.79	3.68	2.66
select_random_points	0.52	0.80	0.36	0.22
select_random_ranges	0.65	1.21	0.39	0.42
table_scan	207.82	475.79	350.33	179.94
types_table_scan	458.96	1213.57	759.88	427.07
oltp_delete_insert	6.21	6.91	7.70	2.22
oltp_insert	3.19	3.89	4.10	1.10
oltp_read_write	11.24	14.46	8.90	4.33
oltp_update_index	3.30	3.82	4.41	1.14
oltp_update_non_index	3.02	3.55	4.18	1.12
oltp_write_only	6.32	7.43	5.18	1.79
types_delete_insert	6.79	7.56	8.43	2.30

Focusing on groupby_scan, we see that Postgres is somehow outperforming Dolt, Doltgres, and even MySQL by a significant margin; it’s over 3x faster. To see what they were doing, I ran EXPLAIN on each of the databases.

Dolt:

sbtest/main*> explain plan SELECT year_col, count(year_col), max(big_int_col), avg(small_int_col) FROM sbtest1 WHERE big_int_col > 0 GROUP BY year_col, set_col ORDER BY year_col;
+---------------------------------------------------------------------------------------------------------------------+
| plan                                                                                                                |
+---------------------------------------------------------------------------------------------------------------------+
| Project                                                                                                             |
|  ├─ columns: [sbtest1.year_col, count(sbtest1.year_col), max(sbtest1.big_int_col), avg(sbtest1.small_int_col)]      |
|  └─ Sort(sbtest1.year_col ASC)                                                                                      |
|      └─ GroupBy                                                                                                     |
|          ├─ select: AVG(sbtest1.small_int_col), COUNT(sbtest1.year_col), MAX(sbtest1.big_int_col), sbtest1.year_col |
|          ├─ group: sbtest1.year_col, sbtest1.set_col                                                                |
|          └─ IndexedTableAccess(sbtest1)                                                                             |
|              ├─ index: [sbtest1.big_int_col]                                                                        |
|              ├─ filters: [{(0, ∞)}]                                                                                 |
|              └─ columns: [small_int_col big_int_col set_col year_col]                                               |
+---------------------------------------------------------------------------------------------------------------------+
10 rows in set (0.00 sec)

Doltgres:

postgres=> explain SELECT year_col, count(year_col), max(big_int_col), avg(small_int_col) FROM sbtest1 WHERE big_int_col < 0 GROUP BY year_col, set_col ORDER BY year_col;
                                                                 plan                                                                  
---------------------------------------------------------------------------------------------------------------------------------------
 Project
  ├─ columns: [sbtest1.year_col, count(sbtest1.year_col) as count, max(sbtest1.big_int_col) as max, avg(sbtest1.small_int_col) as avg]
  └─ Sort(sbtest1.year_col ASC)
      └─ GroupBy
          ├─ select: COUNT(sbtest1.year_col), MAX(sbtest1.big_int_col), avg(sbtest1.small_int_col), sbtest1.year_col
          ├─ group: sbtest1.year_col, sbtest1.set_col
          └─ IndexedTableAccess(sbtest1)
              ├─ index: [sbtest1.big_int_col]
              ├─ filters: [{(NULL, 0)}]
              └─ columns: [small_int_col big_int_col set_col year_col]

MySQL:

mysql> explain analyze SELECT year_col, count(year_col), max(big_int_col), avg(small_int_col) FROM sbtest1 WHERE big_int_col > 0 GROUP BY year_col, set_col ORDER BY year_col;
+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                                                                                                    |
+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| -> Sort: sbtest1.year_col, sbtest1.set_col  (actual time=16.4..16.4 rows=765 loops=1)
    -> Table scan on <temporary>  (actual time=15.9..16.1 rows=765 loops=1)
        -> Aggregate using temporary table  (actual time=15.9..15.9 rows=765 loops=1)
            -> Filter: (sbtest1.big_int_col > 0)  (cost=995 rows=4896) (actual time=0.222..7.37 rows=4896 loops=1)
                -> Table scan on sbtest1  (cost=995 rows=9707) (actual time=0.219..6.36 rows=10000 loops=1)
 |
+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.02 sec)

Postgres:

postgres=# explain analyze SELECT year_col, count(year_col), max(big_int_col), avg(small_int_col) FROM sbtest1 WHERE big_int_col < 0 GROUP BY year_col, set_col ORDER BY year_col;
                                                      QUERY PLAN                                                      
----------------------------------------------------------------------------------------------------------------------
 Sort  (cost=427.98..429.89 rows=765 width=55) (actual time=6.003..6.057 rows=765 loops=1)
   Sort Key: year_col
   Sort Method: quicksort  Memory: 84kB
   ->  HashAggregate  (cost=381.77..391.34 rows=765 width=55) (actual time=5.183..5.672 rows=765 loops=1)
         Group Key: year_col, set_col
         Batches: 1  Memory Usage: 297kB
         ->  Seq Scan on sbtest1  (cost=0.00..318.00 rows=5102 width=17) (actual time=0.005..2.315 rows=5104 loops=1)
               Filter: (big_int_col < 0)
               Rows Removed by Filter: 4896
 Planning Time: 0.711 ms
 Execution Time: 6.327 ms
(11 rows)

Interesting, Dolt and Doltgres are using the secondary index defined over big_int_col, while MySQL and Postgres just perform a full table scan. Since the values in big_int_col are uniformly distributed around 0, the filter where big_int_col > 0 excludes roughly half the columns. It appears the MySQL and Postgres analyzer is smart enough to recognize that the additional lookup is suboptimal.

The flame graph supports this conclusion.

Here, we see that a large portion of the CPU is spent in prolly.Map.Get, which is the secondary key lookup.

Optimization#

Currently, our analyzer will always pick an index when applicable because we assume that will always be better. Evidently, we have discovered that isn’t always the case. We need to modify the existing coster to consider full table scans depending on how well the index filters the results. Fortunately, we implemented statistics a while ago, and we can use the histograms there to get a good estimate of how selective the filter is.

We added these new heuristics to the coster:

A primary key is always better than no index
A secondary index should only be used over a full table scan if it selects fewer than 25% of rows
A covering index is always better than no index

The rest of the coster remains the same. In the future, we should take into consideration things like the complexity of the filter, if the table can fit into memory, size of output row, etc., but this is good enough for now. If you’d like to read the implementation in greater detail, you can check out these PRs:

However, it took some extra work to carry these performance benefits over to Doltgres. While Doltgres does use the same costing logic, statistics weren’t even enabled. After enabling statistics, fixing some bugs, and adding some logic to get histograms working, these are the results:

benchmark	dolt	doltgres	mysql	postgres
covering_index_scan	2.35	2.43	17.01	17.95
groupby_scan	62.19	82.96	144.97	40.37
index_join	1.93	2.30	3.43	1.82
index_join_scan	1.32	1.67	4.18	0.67
index_scan	204.11	484.44	350.33	179.94
oltp_point_select	0.25	0.40	0.19	0.15
oltp_read_only	4.91	6.55	3.68	2.66
select_random_points	0.52	0.74	0.36	0.22
select_random_ranges	0.65	1.04	0.39	0.42
table_scan	204.47	475.79	350.33	179.94
types_table_scan	458.96	1213.57	759.88	427.07
oltp_delete_insert	6.21	6.79	7.70	2.22
oltp_insert	3.19	3.89	4.10	1.10
oltp_read_write	11.24	14.21	8.90	4.33
oltp_update_index	3.30	3.82	4.41	1.14
oltp_update_non_index	3.02	3.49	4.18	1.12
oltp_write_only	6.32	7.30	5.18	1.79
types_delete_insert	6.79	7.43	8.43	2.30

On Dolt, this brought down the latency for groupby_scan from 144.96ms to 62.19ms; this is a 57.1% improvement! On Doltgres, groupby_scan latency decreased from 147.61ms to 82.96ms, which is a 43.80% improvement. With these optimizations, Dolt’s latency for groupby_scan is less than half of MySQL’s. Unfortunately, Postgres still pulls way ahead with their latency being less than half that of Doltgres’s.

While we were focused on groupby_scan, there were also some improvements to index_scan. Dolt went from 219.36ms down to 204.11ms, which is a 6.95% improvement. Doltgres went from 493.24ms down to 484.44ms, which is a 1.78% improvement. Interestingly, a byproduct of this optimization is that the index_scan and table_scan benchmarks are essentially the same now. The resulting plans from both these queries avoid the secondary index, making them both full table scans with a filter.

Conclusion#

We continue to bring performance improvements to both Dolt and Doltgres. Making our coster just a little bit smarter has resulted in our groupby_scan benchmarks running two times faster. Stay tuned to hear more about the performance improvements included in the upcoming Doltgres 1.0 release! Feel free to chat with us on Discord or file a Github issue.

Running Ito, a Runtime Analysis Code Review Tool, on Doltgres

Jason Fulghum — Mon, 20 Jul 2026 00:00:00 GMT

We ship a lot of code at DoltHub, and coding agents, like Claude and Cursor, help us produce code even faster. However, we still need a human to review all of that code and sign off on it before it goes into our products. About six weeks ago, we started using Ito on the repository for our Postgres-compatible version-controlled database, doltgresql. Ito is ~~an AI QA agent~~ a runtime analysis code review tool that works off of GitHub PRs and takes a different approach than other AI tools that analyze PRs: instead of just reading your PR diff and commenting on it, Ito actually builds your application from the PR branch, runs it in a real environment, and exercises it like a user would. On Doltgres that means standing up a real doltgres server and running SQL queries against it. Ito can handle other types of applications, too, for example, running your web application and capturing a screen recording of the UI testing. This post is our review of Ito. We’ll cover what Ito is, how to enable it, dig into a couple of concrete examples of bugs it’s helped us find, and close out with the numbers on how effective it’s actually been over the six weeks we’ve been running it, including our estimated signal-to-noise ratio on the findings it’s raised. Ito doesn’t replace a human reviewer, but it aguments our review process and has been successful at helping us find bugs and broken edge cases.

What is Ito?#

AI tools that analyze GitHub PRs tend to work off the diff of your changes: they feed the changed lines (and maybe some surrounding context) to an LLM and ask it to spot problems. That’s useful for catching sloppy code and some obvious bugs, but it can’t tell you how your product actually runs with these changes, and it can’t test if your product is behaving as expected. A good code reviewer understands the codebase and the product experience and reviews the changes in that larger context.

Ito is different. Ito builds a containerized version of your application from the PR branch and actually runs it. It reads the diff and the PR description to figure out what area of your app is affected, generates a set of test scenarios targeting that area, and then executes them against the running application. For a web app, that means an agent driving a real browser session against your frontend and backend together. For Doltgres, it means opening a Postgres connection to a running doltgres server and issuing SQL statements. Either way, the approach is the same: it’s checking how your code actually behaves, not just what the diff looks like.

Every PR gets a comment from Ito summarizing what it ran, what passed, what failed, and a severity rating for anything it flagged, plus a top-line verdict on whether Ito thinks the PR is safe to merge. Failures come with reproduction instructions that make it easy to repro the failure yourself. For web-based applications, you even get a screen recording you can view that shows you exactly what Ito tested and how your application responded. The Ito website provides a more detailed view of the testing Ito performed. Here’s an example of a detailed report from the Ito website for changes it tested against the open-source chatwoot project.

Below, you can see an example of what an Ito summary comment looks like on one of our PRs. It shows us that it ran 15 tests and two of them failed. It gives a summary of the findings and a recommendation that this PR is not safe to merge yet.

In that same comment, you can drill into the “Tests run by Ito” section to see more detail. We’ll revisit these same findings below, when we talk about what kinds of bugs Ito has found for us.

Turning Ito On#

Setting up Ito is very easy. You create an account at app.ito.ai, install the Ito GitHub App on your organization (or a personal account), and select which repositories you want it watching. There’s no YAML to write and no config to tune before your first run. Ito maps out your codebase from what’s already there, and from that point on, it automatically picks up new and updated pull requests on the repos you selected. As PRs are reviewed, a bot account, itoqa, comments with results as they come in.

You can add custom variables, seed data, or secrets later if you want to point it at specific fixtures, but we haven’t needed to yet. It’s been running against our repo with the defaults.

Ito provides a free trial for startups and small teams, which makes it easy to test out Ito with your app and see how it can help your team.

Ito in Action#

Let’s take a closer look at some real examples of how Ito has helped us catch some pretty tricky bugs. One of the things we’ve noticed is that Ito does a realy good job of testing edge cases in SQL behavior. SQL is a well-documented spec, so it makes sense that a generative AI tool like Ito could use that information to effectively test edge cases and find bugs. This is where we’ve seen Ito be most helpful so far in our experience testing our product.

Two particularly good examples come out of PR #2913, which added native window function support to DoltgreSQL so that we could match PostgreSQL behavior exactly. Previously, Doltgres was relying on go-mysql-server’s implementation, which is implemented to match MySQL behavior, and doesn’t always match PostgreSQL’s behavior, particularly for return types. When I thought I was done with the work, I looked at the PR and noticed that Ito had added comments for two interesting issues it had found.

Bug: Named window reference `OVER w` produces a full-partition SUM instead of a running SUM within each partition#

SQL window function syntax allows you to define a “window” of result rows over which aggregate functions will operate. These window definitions can be inline (e.g. SELECT sum(y) OVER (ORDER BY z)) or they be defined as a named window (e.g. SELECT sum(y) over (w1) FROM a WINDOW w1 AS (order by z);). In either syntax form, if the ORDER BY clause is not specified for a window, then the window function operates over the full partition. In other words, there is a single partition containing all rows that the window function operates on. However, there was a bug hiding deep in our database engine where the correct window framing was applied only if the ORDER BY clause was defined inline. If the ORDER BY clause was defined in a named window, our code saw that there wasn’t an ORDER BY clause specified inline, and incorrectly defaulted to framing the window over the full result set. To execute this query correctly, our engine needed to recognize that a named window was being used and examine it to see if it declared an ORDER BY clause. Only when no inline window definition and no named window definition contained an ORDER BY clause should the engine default the window framing to a single window over the entire result set.

To make this more concrete, check out these statements that repro the issue:

CREATE TABLE a (x INT PRIMARY KEY, y INT, z INT);                                                                                                          
INSERT INTO a VALUES (0,0,0),(1,1,0),(2,2,0),(3,0,0),(4,1,0),(5,3,0);

-- the inline version worked correctly
SELECT sum(y) over (ORDER BY z) FROM a ORDER BY x;
-- correct:         0, 1, 3, 3, 4, 7   (running/cumulative sum)

-- referencing a named window did NOT work correctly
SELECT sum(y) over (w1) FROM a WINDOW w1 AS (order by z) ORDER BY x;
-- buggy (pre-fix): 7, 7, 7, 7, 7, 7   (full-partition sum on every row)                                                                                   
-- correct:         0, 1, 3, 3, 4, 7   (running/cumulative sum)

Note that when the window definition was defined inline (i.e. SELECT sum(y) over (order by z) FROM a ORDER BY x;), this query produced the correct results. This bug was specific to referencing a named window definition.

Here’s the comment Ito added for this issue:

Inside that comment, there is a lot of detail, including a summary of the finding, evidence for repro’ing the problem, and even a sample prompt you can pass to a coding agent to start debugging the issue. I was particularly interested in the repro instructions. I find that’s usually the fastest way for me to understand an issue. When testing a UI application, Ito will actually provide evidence as a screen recording of the testing with your UI, so you can see exactly how it was triggered and how your app responded. Since DoltgreSQL is a server process and not a UI, the evidence Ito provided for us is a repro script and some analysis. You can see the full evidence Ito provided below.

Click to see Ito's evidence for this bug

setup context#

setup_keys: default-superuser#

timestamp: 2026-07-13T20:11:56.578Z test execution for named window OVER w#

reproduction script#

DROP TABLE IF EXISTS t_named;
CREATE TABLE t_named(id int, grp int, amt int);
INSERT INTO t_named VALUES (1,1,10),(2,1,20),(3,2,5);

SELECT id, SUM(amt) OVER w AS s
FROM t_named
WINDOW w AS (PARTITION BY grp ORDER BY id)
ORDER BY id;

SELECT id, SUM(amt) OVER (PARTITION BY grp ORDER BY id) AS s
FROM t_named
ORDER BY id;

observed output#

DROP TABLE CREATE TABLE INSERT 0 3 id | s ----+---- 1 | 30 2 | 30 3 | 5 (3 rows)

inline baseline output#

id | s ----+---- 1 | 10 2 | 30 3 | 5 (3 rows)

tab/readback evidence#

test_start: Executed named window OVER w query against t_named#

test_start result: Returned id=1 s=30, id=2 s=30, id=3 s=5 - PARTITION BY grp works but ORDER BY id is ignored#

test_end result: Failed - named window ORDER BY id is not applied#

final result#

final result: PARSING-1 failed - named window reference OVER w returns full-partition SUM for grp=1 row id=1 (30) instead of running value (10).#

This issue was interesting for several reasons. First off, it’s a legitimate bug deep in our query processor, so it affected multiple products, including Dolt and Doltgres. It’s also syntax that we did have test coverage for in our query processor. Unfortunately, the test coverage we had was asserting incorrect results! This is a great example of a latent bug where it looked like we had good coverage, and we were indeed executing this syntax in tests, but we were asserting the wrong results. Ito provided great value here to help us catch this before a customer had to report it to us.

This also illustrates a powerful aspect of Ito. Nothing in the code diff in the PR that Ito reviewed had any direct sign of this bug. If Ito had only been looking at the diff lines from the PR, then it wouldn’t have caught this. Instead, Ito analyzed what was changing, used knowledge of window function syntax in SQL, and tested edge cases to see if it could find any problems, and sure enough, it did.

Bug: Inheriting or overriding a named window’s `ORDER BY` drops it#

The next issue that Ito found is a similar, but separate bug. Just like the previous issue, this one is a bug in how a named window definition is merged into a statement, specifically when an ORDER BY clause is provided in the statement to override the ordering in the named window definition. In this case, the overridden ORDER BY clause wasn’t getting applied correctly, and resulted in the aggregate function being incorrectly applied over a window covering all result rows, instead of using the correct window framing required by the ORDER BY clause.

Here’s a concrete example of this bug and how it affects the returned results:

CREATE TABLE t(id int, grp int, amt int);
INSERT INTO t VALUES (1,1,10),(2,1,20),(3,1,30),(4,2,5),(5,2,15);

SELECT id, SUM(amt) OVER (w1 ORDER BY id) AS s FROM t
    WINDOW w1 AS (PARTITION BY grp) ORDER BY id;
-- buggy:   60, 60, 60, 20, 20   (full-partition sum, w1's frame leaking through)                                                                          
-- correct: 10, 30, 60,  5, 20   (running sum, from the inline baseline SUM(amt) OVER (PARTITION BY grp ORDER BY id))

Here’s the comment Ito added for this issue:

As with the previous bug, Ito provided clear steps to reproduce this bug, which made it very easy to get started debugging it.

Click to see Ito's evidence for this bug

setup and reproduction SQL#

DROP TABLE IF EXISTS t_inherit;
CREATE TABLE t_inherit(id int, grp int, amt int);
INSERT INTO t_inherit VALUES (1,1,10),(2,1,20),(3,1,30),(4,2,5),(5,2,15);

-- Inheritance chain
SELECT id, SUM(amt) OVER w2 AS s FROM t_inherit
  WINDOW w1 AS (PARTITION BY grp), w2 AS (w1 ORDER BY id) ORDER BY id;

-- Explicit named-window override
SELECT id, SUM(amt) OVER (w1 ORDER BY id) AS s FROM t_inherit
  WINDOW w1 AS (PARTITION BY grp) ORDER BY id;

-- Inline baseline (control)
SELECT id, SUM(amt) OVER (PARTITION BY grp ORDER BY id) AS s FROM t_inherit ORDER BY id;

observed output#

Test 1: Named window inheritance chain w1 -> w2#

id | s ----+---- 1 | 60 2 | 60 3 | 60 4 | 20 5 | 20 (5 rows)

Test 2: Named window with override clause#

id | s ----+---- 1 | 60 2 | 60 3 | 60 4 | 20 5 | 20 (5 rows)

Test 3: Inline window baseline (correct expected behavior)#

id | s ----+---- 1 | 10 2 | 30 3 | 60 4 | 5 5 | 20 (5 rows)

additional mixed-form readback from run#

id | s1 | s2 | s3 ----+----+----+---- 1 | 38 | 38 | 38 2 | 38 | 38 | 38 3 | 20 | 20 | 20 4 | 20 | 20 | 20 5 | 38 | 38 | 38 (5 rows)

final result: PARSING-3 failed - named-window inheritance/reference forms return full-partition sums while equivalent inline OVER (PARTITION BY grp ORDER BY id) returns running sums.#

Like the previous bug, this bug was deep in our query processor, in the shared go-mysql-server module, so it affected all of our database products built on our query processor. Unlike the previous bug, this one was a gap in our test coverage. Thanks to Ito, we found this gap and added new tests for this case, ensuring that same tests will run for each of our database products and prevent a regression.

Not Just for SQL#

It’s worth noting that DoltgreSQL is not the typical product Ito can handle testing. Ito’s initial target was web applications: an agent drives a real browser against your app, clicks around like a user, and hands back a video replay of anything that broke, alongside the usual severity rating and repro steps. DoltgreSQL has no UI to click through. It’s a database engine that other programs talk to over the Postgres wire protocol. On our repo, Ito’s “user” is a SQL client instead of a browser, and its test scenarios are queries instead of clicks.

Ito Improvements#

We’ve only been using Ito for a little over a month, but even in that short amount of time, we’ve seen improvements in how well Ito is able to test our product. Like we mentioned earlier, the majority of Ito users are using it to test web-based applications. Because of that, Ito defaulted to taking screen recordings of the testing and showing that as the evidence for each bug report. As you can imagine… these screen recordings weren’t super interesting or helpful for a database server. The Ito team was receptive to this feedback and quickly rolled out changes so that non-UI products, like Doltgres, don’t include screen recordings, and instead, get a text file containing the evidence Ito used to determine each bug.

We had another issue where Ito was reporting false alarms about SQL syntax that didn’t work. This was initially confusing because the PR where we saw this was successfully running tests that showed the new syntax working. When we reported this to the Ito team, they were responsive and quickly identified that Ito hit a problem building the Doltgres binary on our PR branch and instead used an older binary, which didn’t have support for the new syntax added in the PR. The Ito team quickly rolled out a change to prevent Ito from falling back to an older binary. Now if the binary couldn’t be successfully built from the PR branch, Ito would fail with a clear error message. We were happy with the quick response from the Ito team and haven’t seen this issue again.

For the Doltgres database server, we’ve noticed that Ito does really well finding issues with some PRs, but on other PRs, there are sometimes comments or reported issues that aren’t as helpful and can add noise to your PRs. How effectively Ito can find bugs in your PRs seems to depend on what type of application you’re building and what type of changes you have in your PR. For example, in our experience, we’ve noticed that Ito does really well at finding bugs and broken edge cases when we’re implementing something well-documented, like features from the SQL spec. In the examples above, we were implementing well-defined syntax for SQL window functions, and Ito was able to identify a couple of broken edge cases. We’ve seen similarly helpful comments from Ito in other PRs where we implemented SQL functions, like COALESCE(). In PRs where we were making internal performance optimizations that didn’t directly affect SQL features, Ito wasn’t as helpful or sometimes even added comments that didn’t warrant any action.

By the Numbers#

The examples above are illustrative of the kinds of issues Ito has found for us. In addition to that, I also want to share some stats on the overall effectivness of Ito with our product so far. In the six weeks we’ve been using Ito, it has commented on 92 pull requests in the doltgresql repo. A little under half of those are dependabot-style PRs (e.g. automated dependency bumps, post-release metadata updates) with no real logic for Ito to exercise, so we’ll exclude those from our analysis. That leaves 43 substantive PRs where Ito actually had something to test.

Of the 38 of those 43 PRs that have since merged or closed: 20 came back clean on every run, and on the 18 remaining PRs, Ito reported at least one issue. So, Ito is reporting issues for about half of our PRs. 8 of those 18 show a fix-and-re-verify cycle directly in Ito’s comment history before merge. That shows that for about half of the PRs where Ito is reporting issues, the PR author is seeing those issues and addressing them before merging the PR. This is still undercounting by a bit, since some Ito reported issues get fixed in a follow-up PR or moved to be tracked in our GitHub backlog. Based on that data, and rounding up a bit for issues that are addressed in follow-up PRs or added to the backlog, roughly 33% of our PRs are benefiting from the findings Ito is reporting.

It’s also worth noting how often Ito finds bugs that have nothing to do with the PR it’s reviewing. In 26 of those 43 PRs (~60%), Ito surfaced at least one issue explicitly flagged as pre-existing and unrelated to the PR specific changes. Ito found those by understanding the functionality changing and testing edge cases around it, not because the PR touched that code path. That’s a different kind of value than catching a regression in the PR: it’s deeply testing parts of the product and finding existing issues that we didn’t know about yet.

As one final angle, we went back through every review thread looking for cases where someone on the team weighed in directly on a specific Ito finding, calling it either legitimate or a false alarm. Across those judgment calls, we confirmed more than twice as many findings as we dismissed. A more than 2:1 ratio of confirmed-to-dismissed, on a tool that’s finding real bugs, is a worthwhile trade.

Summary#

We’ve been using the Ito automated review tool on PRs in the Doltgres repository for about six weeks now. After a few initial bumps getting our product working with Ito, which were all quickly resolved by the Ito team, we’ve been getting real value from the comments Ito leaves on our PRs. The numbers above bear that out, including a more than 2:1 signal-to-noise ratio on the findings we’ve actually sat down and judged. It’s been particularly helpful at catching broken edge cases in PRs related to SQL features. In this blog, we showed examples of Ito finding two bugs with SQL window framing, that both existed deep in our query processor dependency.

We’re still experimenting with Ito and seeing where it is most helpful. When we’ve hit an occassional issue using the tool, the Ito team has been responsive and quick to roll out a solution to improve our experience, including making their product work well for non-web-UI products, like Doltgres.

If you’re curious about Ito, you should try it out! It’s easy to create an account with Ito and hook up the ItoQA GitHub action to your GitHub repository. If you are hesitant to change your repository settings, you can also try out Ito by analyzing a single PR. This gives you a really lightweight way to see the Ito experience on your own PR. You can find more details on Ito’s pricing online, which includes options for a free trial, as well as free use for approved open-source projects.

Last, but not least, if you want to talk about version-controlled databases, or AI tooling, please come by the DoltHub Discord. We’re always around Discord and happy to talk about the benefits of version-controlled databases and how AI tooling is changing the software development experience.

Dolt in Four Flavors

Tim Sehn — Thu, 16 Jul 2026 00:00:00 GMT

We’ve been building Dolt for almost eight years now. The first seven of those years produced two Dolt flavors: classic MySQL-flavored Dolt and the much anticipated Postgres-flavored Doltgres. The past year has produced two additional flavors: the SQLite-flavored DoltLite and the MongoDB-flavored Dumbo. Coding agents rapidly accelerated our company’s ability to build new products. DoltLite and Dumbo are entirely agent-made.

Why all the flavors? Which flavor should you choose for your use case? Which flavors work with other services like Hosted Dolt or DoltHub? This article explains.

Why All the Flavors?#

Version control is useful, and essential if agents are involved, in every database format, and our product catalog now reflects that. Moreover, over the eight years we’ve been building Dolt, users have asked for almost every database flavor. There is demand for all manner of version-controlled databases.

Of the four Dolt flavors, only Dolt and Doltgres are redundant. MySQL and Postgres are mostly interchangeable as Online Transaction Processing (OLTP) SQL databases. DoltLite and Dumbo have completely different form factors. DoltLite is an embedded database, not an OLTP database. Dumbo is an OLTP database but not a SQL database.

So why Dolt and Doltgres? Database formats are very sticky. You are either a MySQL shop or a Postgres shop. Convincing people to switch database formats is harder than providing both options. Postgres has definitely become the default OLTP SQL format. This was not the case in 2018 when we started building Dolt. MySQL was still very popular. Today, not so much. A Postgres flavor is required in 2026. Doltgres goes 1.0 in August, signaling it is ready for production use.

Which Flavor Is Right for You?#

Now that Dolt has four flavors, how do you pick the flavor that is right for you? This really comes down to what type of database you need.

Do you want an OLTP database like MySQL or Postgres? Most OLTP databases are used to power the backends of websites or mobile applications. The database is run as a server that hosts one or many clients. If the answer to that question is yes, you have narrowed your choice down to Dolt, Doltgres, or Dumbo. If the answer is no, you probably want an embedded database and DoltLite is for you.

Do you want your data structured as tables and accessed using SQL? If yes, then you can choose between Dolt and Doltgres. If no, Dumbo’s document format is for you.

Choosing between Dolt and Doltgres comes down to your preference. Dolt is older and more stable. If you don’t care about SQL format, we always recommend choosing Dolt over Doltgres. If you are migrating from Postgres or wedded to Postgres as a company, choose Doltgres.

The Dolt Ecosystem#

What about DoltHub, DoltLab, Hosted Dolt, and the Dolt Workbench? If I want to share my data on DoltHub, can I use Doltgres?

The goal is for all four flavors of Dolt to work with DoltHub, DoltLab, Hosted Dolt, and the Dolt Workbench with one exception: DoltLite will not be hosted. However, we’re probably 6-12 months away from reaching that goal.

With DoltHub and DoltLab, there are two components. Can you push to them as a remote? Can you view your database contents using the user interface? Supporting the first is pretty easy while supporting the second is more involved. User interface features are things like pull requests and SQL queries. Here’s a compatibility matrix with estimated dates for the unsupported cells.

Conclusion#

We now have the Dolt that is right for you! Be that classic Dolt, Doltgres, DoltLite, or Dumbo. Soon, all these databases will work with DoltHub, DoltLab, Hosted Dolt, and Dolt Workbench. Want something prioritized? Come by our Discord and let us know. We’re always willing to shift the schedule based on user feedback.

Dolt + TeamCity: Data Commits Now Trigger Builds

Elian Deogracia-Brito — Mon, 13 Jul 2026 00:00:00 GMT

Here are two builds of the same tiny game, one database commit apart:

=== Battle report: 3 units in the roster (config hnak4bdfk10s) ===
Footman vs Archer: draw at 6 hits each

=== Battle report: 3 units in the roster (config lravfogrck8d) ===
Footman vs Archer: Footman wins in 5 hits

No source code changed between these builds. A designer ran one SQL UPDATE, committed it, and a CI server was alerted to test and ship a new binary with the commit hash stamped inside. The database is Dolt, the world’s first version-controlled SQL database. The CI server is TeamCity, which as of this year can treat a Dolt database as a first-class version control system.

It’s a collaborative sequel. Two years ago we wrote about how Scorewarrior manages their game configuration with Dolt: designers tune stats on branches, changes merge through pull requests, and shipping means cutting a tag and building binary artifacts. That post ended right where the config leaves Dolt and enters the build system. Now the engineer who ran that build system just fixed its one missing piece.

What Is TeamCity?#

TeamCity is JetBrains’ continuous integration (CI) server for developers and build engineers. If CI is new to you: it’s the practice of committing changes to a shared repository many times a day, with every commit followed by an automated build and test run, so integration problems surface in minutes instead of at release time. TeamCity is a veteran of the field, available on-premises or as a managed cloud service, and the free Professional license is generous: 100 build configurations, 3 build agents, no restrictions on users or runtime, and the full feature set for commercial, open-source, and personal projects alike.

The architecture has two primary components: the TeamCity server, which provides the web UI for managing configuration and results, and build agents, the workers that execute your builds. You configure everything through the UI, through the Kotlin DSL, or a hybrid of both, with UI changes committed back to your repository as code.

Notice the word “repository”. TeamCity is built around version control: it polls your VCS for commits, lists them in a Changes tab, triggers builds when they land, and pins every build to the revision that caused it. That raises our favorite kind of question: what if the thing under version control is a database?

TeamCity and Dolt, Before#

Yury Dynnikov, formerly of Scorewarrior and now at JetBrains, spent years building game configs from Dolt into binary packages with TeamCity. However, TeamCity did not understand Dolt’s version control: commits, branches, and tags were all invisible. Still, a pipeline could work with a separate replica server just to have something stable to build from, branch names passed around as build parameters instead of TeamCity’s native branch handling, and some other not-so-cool tricks.

Look, a Cool New Plugin!#

Yury’s fix is a Dolt plugin for TeamCity (source on GitHub, MIT licensed). He is clear it’s a personal project rather than a JetBrains product, but it does what his old pipeline always wanted: install it and “Dolt” appears in TeamCity’s Type of VCS dropdown, right next to Git, Subversion, and Perforce.

Commits show up in the Changes tab with hash, author, and message. Branch specifications work, so a commit to staging builds apart from main, each branch with its own build history:

There are two connection modes: Remote JDBC points at a dolt sql-server you already run, while Local mode clones from DoltHub or DoltLab and manages its own SQL server, with private repos handled through an Ed25519 keypair flow, the same credential mechanism dolt login uses, except TeamCity generates the keypair and you register its public half on DoltHub.

Yury also runs a public demo server (guest login) where the plugin builds the Endless Sky game data through a real pipeline: export, data-quality tests, release bundles, all configured in Kotlin DSL.

The Query Behind the Changes Tab#

The plugin renders data changes and schema changes as different entries, and you can see how via a common Dolt SQL function:

SELECT * FROM DOLT_DIFF_SUMMARY('hnak4bdfk10s...', 'lravfogrck8d...');
+-----------------+---------------+-----------+-------------+---------------+
| from_table_name | to_table_name | diff_type | data_change | schema_change |
+-----------------+---------------+-----------+-------------+---------------+
| units           | units         | modified  | 1           | 0             |
+-----------------+---------------+-----------+-------------+---------------+

A data_change without schema_change makes the Changes tab show tables/units. But run the same function against our branch that adds an armor column and both flags flip on, so the tab renders tables/units (schema) as its own entry.

Why bring this up? Risk. The Footman buff changes a number the game already knows how to read, so CI can test it and ship it to live servers right away. The armor column changes the shape of the data, and every program that reads the config now has to be updated to match, so that commit should get extra checks.

Since the plugin writes the two as different paths, TeamCity trigger rules can route each kind to the right build automatically.

Setup#

Installers are available for Linux, macOS, and Windows, but we used JetBrains’ own recommended Docker distribution. After all, this is an inherently multi-service system: the TeamCity server needs the TeamCity agent image to spawn build processes, plus a Dolt SQL server to be the repository. (New to Dolt in Docker? We have a getting started post.) Three containers, wired like this:

This Compose file is everything you need to follow along:

services:
  dolt:
    image: dolthub/dolt-sql-server:latest
    environment:
      DOLT_ROOT_PASSWORD: dolt
      DOLT_ROOT_HOST: "%"    # let other containers connect as root
    ports:
      - "3306:3306"
  server:
    image: jetbrains/teamcity-server:latest
    ports:
      - "8111:8111"
    volumes:
      - tc_data:/data/teamcity_server/datadir
      - tc_logs:/opt/teamcity/logs
  agent:
    image: jetbrains/teamcity-agent:latest
    environment:
      SERVER_URL: http://server:8111
volumes:
  tc_data:
  tc_logs:

Run docker compose up -d, give TeamCity a couple of minutes to boot, then open http://localhost:8111 and click through the one-time wizard: accept the defaults (the internal database is fine for evaluation), create your admin user, and authorize the agent under Agents, Unauthorized. Next, install the plugin: download the zip from the Marketplace page, upload it on the Plugins page behind the Admin gear in the left-hand navigation bar, and restart the server. You need TeamCity 2025.11.3 or newer.

While that restarts, give Dolt something worth building. Connect with any MySQL client (mysql -h127.0.0.1 -uroot -pdolt) and seed a tiny game config:

CREATE DATABASE gameconfig;
USE gameconfig;
CREATE TABLE units (id INT PRIMARY KEY, name VARCHAR(64), hp INT, attack INT);
INSERT INTO units VALUES (1,'Footman',100,12),(2,'Archer',70,18),(3,'Knight',180,25);
CALL DOLT_COMMIT('-Am', 'Initial game config');

Finally, connect the two. Create a project (TeamCity’s onboarding will offer to connect VCS hosting accounts and set up pipelines along the way; skip all of it, because your version control is the database), add a VCS root of type “Dolt”, and fill in the form: connection mode Remote JDBC, host dolt (the Compose service name), port 3306, database gameconfig, user root, password dolt, and branch specification +:* to watch every branch. Test connection, green.

One last piece of plumbing: a build configuration, so those commits have something to trigger. Click “Create build configuration”, and on the “Set up your build” page keep the plain “Build configuration” option and pick your gameconfig-dolt root under “From an existing VCS root”:

Give it a Command Line build step; even dolt version works as a placeholder while you wire things up. Then add a VCS trigger under Triggers so new commits start builds on their own:

The steps our demo build runs are more specific (i.e., data-quality probes and compilation) which will come up in later sections.

A Data Commit Walks Into a Build#

Here is the whole chain, end to end:

Let’s say a designer is buffing a stat, expressed as SQL against the running server:

CALL DOLT_CHECKOUT('main');
UPDATE units SET attack = 14 WHERE name = 'Footman';
CALL DOLT_COMMIT('-Am', 'Balance pass: buff Footman attack 12 -> 14');

About a minute later the commit is in the Changes tab and the VCS trigger has started a build. A row update just triggered continuous integration.

TeamCity hands every build the commit that triggered it as %build.vcs.number%, and Dolt can query any table as of any commit. Build steps therefore read the data exactly as it was at the triggering revision, even if someone commits again while the build waits in the queue:

dolt sql -q "SELECT * FROM units AS OF '%build.vcs.number%'"

Watch a Test Turn Red#

Our build step runs data-quality probes before anything ships, each reported through TeamCity service messages so a bad commit fails the build as a named red test instead of a wall of log text, and the step halts on a red probe so bad config never reaches the compiler. Here is the entire mechanism, two probes and a gate:

PROBES_FAILED=0
probe() {
  echo "##teamcity[testStarted name='$1']"
  bad=$(dolt --host dolt --port 3306 -u root -p dolt --use-db gameconfig --no-tls \
    sql -q "$2" -r csv | tail -1 | tr -d '\r')
  if [ "${bad:-error}" != "0" ]; then
    echo "##teamcity[testFailed name='$1' message='${bad:-probe query failed} offending rows']"
    PROBES_FAILED=1
  fi
  echo "##teamcity[testFinished name='$1']"
}
probe "data.units.positive_stats" \
  "SELECT COUNT(*) FROM units AS OF '%build.vcs.number%' WHERE hp <= 0 OR attack <= 0"
probe "data.units.unique_names" \
  "SELECT COUNT(*) - COUNT(DISTINCT name) FROM units AS OF '%build.vcs.number%'"

if [ "$PROBES_FAILED" != "0" ]; then
  echo "Data-quality probes failed; skipping compile and package."
  exit 1
fi

A probe is a COUNT(*) of rows that should not exist, and any nonzero answer becomes a failed test. We committed a unit with attack zero to showcase:

##teamcity[testStarted name='data.units.positive_stats']
##teamcity[testFailed name='data.units.positive_stats' message='1 offending rows']
##teamcity[testFinished name='data.units.positive_stats']

The build goes red in the overview:

Opening the failed build shows the step halted by the gate:

The Tests tab names the exact check that caught it, and nothing gets packaged:

Revert the commit (CALL DOLT_REVERT('HEAD')) and the revert, being itself a commit, triggers one more build. That one is green.

Two Builds, Two Games, One Commit Apart#

Our build step generates Go source from the config at the pinned revision, compiles an actual game binary with the Dolt commit stamped inside via ldflags, and cross-compiles it for Linux, Windows, and Mac from one Linux agent. The binaries self-identify: the config hnak4bdfk10s in that first line of output is the real Dolt commit hash the artifact carries.

They are also reproducible. Building the same commit twice yields byte-identical output:

build1 sha256: a1d97cf4d47502e5...
build2 sha256: a1d97cf4d47502e5...

Dolt pins the data, the build pins everything else, and any artifact in the wild traces back to the exact data commit that produced it. The build’s Artifacts tab lists the binaries, each named after its revision:

The Fine Print#

The plugin is young, and its documentation is upfront about the edges: data changes currently show row counts rather than row-level diffs, the Changes tab is a linear list without a commit graph, and there is no write-back yet, so no merges or pre-tested commits driven from TeamCity. That last item is on the roadmap, and it’s the one to watch: CI gating merges to your data the way it gates merges to your code.

If that idea appeals, and you would rather not run your own CI server, we have been building it from the hosted side for a while: DoltHub supports CI testing on data and pull request CI, and we were wiring data CI out of webhooks back in 2020. Yury’s plugin brings the same conviction to your own TeamCity, where your builds may already live.

Conclusion#

The Scorewarrior post asked what you would use a version-controlled SQL database for. This plugin answers one layer up the stack: you build from it, test against it, and ship artifacts traceable to it, with your CI server treating data commits as what they are, commits. Give the plugin a spin, poke at the demo server, and tell Yury what you think. He asked for ideas on showcasing it, and when we checked, the download counter read five. Let’s fix that.

Curious about version-controlled databases, or want to talk CI on data? Stop by the DoltHub Discord and say hello. Our engineering team hangs out there all day.

Doltgres Reaches 99% Compliance on SQL Logic Tests

Jason Fulghum — Fri, 10 Jul 2026 00:00:00 GMT

Two weeks ago, we announced that Doltgres 1.0 is coming August 6th. In that post, we laid out the four things we’re focused on to get there: correctness, storage format stability, performance, and compatibility. Correctness was measured by one very concrete number: 99% compliance on our SQL Logic Test suite. At the time we were sitting at a little over 96%. Today, we’ve hit our target: Doltgres passes 99% of the suite. That’s one more box checked on the road to 1.0. 🎉

SQL Logic Test#

SQL Logic Test is a test suite originally built for SQLite, containing millions of statements and queries that exercise SQL expressions, joins, aggregates, and type coercion rules. We forked it years ago and extended it with more tests to measure how correctly Dolt (and now Doltgres) execute SQL statements. The test suite in SQL Logic Test specifically stress tests the expression support in each engine. 99% represents millions of individual queries whose results have to match PostgreSQL exactly, down to the type and formatting of every returned value. This gives us a high confidence that Doltgres can correctly execute a wide range of statements and expressions.

Establishing a Baseline Against PostgreSQL#

Before we could chase down our own bugs, we needed to answer a more basic question: how many of these tests are even valid against PostgreSQL? The suite was originally written for SQLite, and over the years it’s been adapted and extended for MySQL as we’ve used it to test Dolt. Postgres has never been the primary target, so we couldn’t assume the entire test suite would execute cleanly against Postgres.

We pointed our test runner at a real PostgreSQL server and ran the full suite against stock PostgreSQL first, to establish a baseline of how compatible the tests actually were with Postgres. That baseline surfaced a number of places where the tests themselves (or in many cases, the runner’s expectations about results) were still encoding SQLite or MySQL behavior and not compatible with slightly different behavior in Postgres. Fixing those was a prerequisite before we could start figuring out what changes were needed in Doltgres.

A few examples of what we found and fixed:

Integer vs. float schema types. The test format encodes an expected type for each result column (I for integer, R for float/real), based on SQLite’s type affinity rules. Postgres is stricter about numeric types than SQLite, so expressions SQLite treats as integers may legitimately come back as floats from Postgres, and vice versa. We updated the runner’s schema comparison to treat I and R as compatible in both directions, and to normalize whole-number floats (like 3.000) to integer formatting (3) so the value comparison succeeds when the underlying values genuinely match. Limiting this to whole-number floats only means we still detect correctness errors if the values don’t logically match, but we’re more flexible on the returned result type so that we can use the same tests to match against Postgres.
Empty result sets. SQLite reports SQLITE_NULL as the type for every column when a query returns zero rows, which doesn’t correspond to anything meaningful in Postgres. We updated the runner to skip schema-type verification entirely when both the expected and actual result sets are empty, since there’s nothing to compare.
Postgres-specific type names in the harness. Our test harness inspects the driver’s reported column types to decide how to parse and compare each value. It was written with MySQL’s type names in mind (INT, BIGINT, DECIMAL, and so on), so it didn’t know what to do with Postgres-specific names like BOOL, INT2, or FLOAT4. We filled in the missing cases so those types get parsed and compared correctly instead of falling through and failing.
MySQL-only statements. Some tests exercise MySQL-specific syntax or behavior that has no Postgres equivalent at all. Rather than force those through, we added skip directives so they’re excluded when running against Doltgres, the same way we already skip SQLite-specific tests.

In addition to those improvements, we also invested in running the suite in parallel, spinning up a single shared Doltgres server and fanning test files out across concurrent workers, each against its own isolated database. At the scale of millions of test queries, that’s the difference between a test run that takes minutes and one that takes hours, which matters a lot when you’re iterating on fixes.

Bugs the Tests Found in Doltgres#

With those changes in place, we could now run the SQL Logic Tests against a real PostgreSQL server and get over 99% correctness. There are still some issues for the test suite to run 100% against PostgreSQL, and we’ll keep chipping away at those in future passes. After these improvements, the remaining test failures with Doltgres were much more likely to be real Doltgres bugs that we needed to dig into. The most interesting was in our COALESCE() implementation: when called with mixed numeric types (say, an int4 and an int8, or an int4 and a float8), it was using a generic type conversion instead of Postgres’ assignment cast rules to compute the common type. That’s an important distinction. Assignment casts are what Postgres itself uses to widen mixed-type arguments to a common type, and using the wrong conversion path meant we could return incorrectly typed or incorrectly rounded results for a fairly common pattern in real SQL.

On Track for August 6th#

Correctly executing 99% of the SQL Logic Test suite was our target for Doltgres’ 1.0 release. It gives us high confidence that a wide range of statements and SQL expressions are executing correctly in Doltgres. By baselining the test suite against PostgreSQL, we discovered that we were closer to this milestone than we initially expected. We thought we still had many remaining gaps to fill to reach that milestone, but it turned out that how the results were being processed by the test runner accounted for most of the gap.

Executing queries correctly, and returning identical results as PostgreSQL, is the foundation for our 1.0 launch. Without correct query execution, the other goals, like fast execution of queries and tool compatibility, just don’t matter. Overall, we’re making great progress on our 1.0 punch list and remain on track for August 6th.

If you’re running Doltgres and you hit a query that returns the wrong result, an error you don’t expect, or behavior that just doesn’t match Postgres, please send us a GitHub issue and let us know. We want to find and fix as many of these as possible before 1.0 ships, and customer-reported issues go straight to the top of our queue.

If you haven’t started using Doltgres yet, give it a shot! You can install Doltgres by running brew intall doltgres on a Mac with Homebrew, or you download a binary from our GitHub releases. Our dev team hangs out on the DoltHub Discord server every day, so feel free to come by and tell us how it’s going. We’re closing in on 1.0 and every bit of feedback helps us get there!

Doltgres 1.0 Coming August 6th

Jason Fulghum — Fri, 26 Jun 2026 00:00:00 GMT

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.

What People Are Saying: LWN Edition

Nick Tobey — Thu, 18 Jun 2026 00:00:00 GMT

In 2019, we released Dolt, the world’s first version-controlled SQL database. In the seven years since, we’ve seen a gradual but steady influx of attention as people become aware we exist.

You can clearly see the first time we got mentioned on HackerNews in 2021.

More and more, this attention is taking the form of people not just noticing us, but talking about us to others. We love that. We think that word-of-mouth buzz is a strong signal for the genuine usefulness of a tool.

Last month, Daroc Alden over at LWN wrote about us.¹ It was really cool to see an outside perspective. I think they did a great job of explaining what Dolt is and how it can be used. They also have a great explanation of Prolly Trees, the B-tree inspired data structure that makes Dolt possible. We’re kind of obsessed with Prolly Trees, so it’s cool to see someone else understand them and even see them talk about some of the improvements that we made to Prolly Trees to improve node size distribution.

Overall, I think the LWN article did a great job introducing Dolt to a new audience and I’m happy to see it. But there were a couple of misconceptions in the article, so for the sake of completeness I wanted to clear them up.

Project Architecture#

Two related misconceptions we see pop up on occasion is the claim that:

Dolt and its siblings (Doltgres and DoltLite) are plugins/forks of common SQL engines.
Each project is a different wrapper around an otherwise identical storage layer.

Combined, these two ideas paint the picture that Dolt / Doltgres / DoltLite each take the same underlying storage format and bridge it to MySQL / PostgreSQL / SQLite, respectively.

LWN repeats both of these ideas in their article. To quote:

[Dolt, Doltgres, and Doltlite] have separate frontends for the different SQL dialects, but the projects share a common storage backend that supports version-control operations.

That competitive performance is possible because Dolt only changes the storage layer of the database. The query planner, index maintenance, and so on all reuse MySQL, PostgreSQL, or SQLite’s existing implementations.

The reality is slightly more nuanced. We maintain our own SQL engine, go-mysql-server. Like the name suggests, it was originally made for the MySQL dialect, but recently we’ve also been adding support for Postgres.

We also have a common storage backend, designed for use with go-mysql-server. Both Dolt and Doltgres use this backend. They aren’t plugins, and they don’t depend on the MySQL or Postgres code bases at all.

On the other hand, DoltLite is a custom storage backend for SQLite, and as such, it doesn’t use the common storage backend, but rather its own format and implementation. It’s based on the same design as the original, but the formats are not compatible.

The Power of Git#

There’s a lot of reasons why applying the Git model to databases makes sense. The LWN article points out the biggest one:

The real utility of Dolt comes from the ability to restore old commits, fork historical states of the database, and merge in changes after review.

This is 100% true, and it’s the most common way we see users take advantage of Git-style version control. But there’s another big benefit to Git-style version control too: remotes.

Just like Git, Dolt allows you to clone a database from a remote and then sync incrementally. When you dolt pull or dolt push, only the new changes get sent. This lets you get a local, up-to-date copy by only downloading the parts that actually changed. That turns out to be a pretty powerful feature for replicas.

How Git and Dolt Store Snapshots#

Git and Dolt take a “snapshot” approach to version control, where each commit represents is an independent snapshot of the data at a specific point in time.² But in the event that not much has changed between commits, what stops all the different snapshots from taking up lots of extra storage space?

A common Git misconception is that Git reduces storage by storing commits internally as deltas. The article repeats that misconception and suggests that this is the main reason why Git (and by extension Dolt) require data structures that can be diffed efficiently. To quote:

Each commit is logically independent, and could in theory just be stored as-is. In practice, most Git repositories do not completely change between commits, and it’s more efficient to store the differences between subsequent snapshots, rather than the snapshots themselves.

Git, which works with entire directory trees, relies on being able to quickly check whether a particular sub-tree has changed in order to produce compact diffs that include only the actual changes.

There’s some truth to this: Git does have the ability to produce compact diffs (such as with the git diff command). And Git’s storage format does have the ability to store deltas on individual files. But it doesn’t store the whole commit as a delta, and deltas aren’t the primary method for achieving efficient storage.

The actual method by which Git and Dolt achieve compact storage is much simpler: when two commits trees contain identical sub-trees, Git and Dolt simply only store that identical tree once. And indeed further down, the LWN article explains exactly that:

Content-addressed storage is a scheme that many version-control systems use to deduplicate data: a particular diff or other object is stored in a location based on the hash of its contents. This ensures that duplicate items will reuse the same storage space.

This trick of reusing the unchanged parts of the tree is called structural sharing. In order to make this possible, the data being stored requires that two trees containing the same items are exactly identical, regardless of how those items were inserted. This property is called history independence, and its the property that Prolly Trees provide that B-trees don’t. History independence is also how both Git and Dolt can produce efficient diffs.

So Git and Dolt’s efficient storage isn’t because of their diffing capabilities, but rather the same property (history independence) allows for both fast diffs and compact storage.

Dolt’s Dynamic Node Size Thresholds#

It was really cool to see this get a shout-out.

A known shortcoming of the original prolly tree design is that it produces trees where the number of elements per node follows a geometric distribution. This is a pretty big problem, because it both means that there’s no theoretical upper bound on node sizes, and it leads to imbalanced trees with worse performance.

Think about it this way: if a small number of nodes in your tree are much larger than others, then those nodes are not only going to take longer to process, but they’re also going to get visited more frequently because they have more children. This makes tree operations more likely to hit slow paths.

Dolt has a pretty clever solution to this problem, and not only did the article talk about it, it spawned some good discussion in the comments. Basically, Dolt uses a dynamic threshold to decide how to draw boundaries between tree nodes: as a tree node fills up, the probability of the next element causing a split increases.

One small correction though: the dynamic threshold isn’t based on the number of node elements like the example suggests, but rather the number of bytes written. This matters when the elements are variable-length, and gives us better control over the exact distribution of node sizes.

That’s All, Folks#

This was a great read. It was really cool to see an outsider’s perspective on Dolt. The readers of LWT are lively and did a lot of engaging in the comments of the original article.

If you’d like to engage with us more, consider joining our Discord. We’re always down to chat and answer questions.

What does LWN stand for? Apparently nothing anymore, but it used to stand for Linux Weekly News. ↩
This is in comparison to delta-based version control systems, where each commit represents a diff on the previous commit. We’ve written in the past about the different types of version control schemes. ↩

Git For Context

Tim Sehn — Mon, 15 Jun 2026 00:00:00 GMT

Here at DoltHub we tend to view everything through the lens of version control. We built Dolt, the world’s first version-controlled SQL database after all. Would this new tool be better with branches? Diffs? Merges? Clones? Inevitably, we see some opportunities.

Databases? Check.
Spreadsheets? Eventually.
Coding agents? Hmmm. I wonder…

With the rise of vibe coding and agents in general, we’re looking at context with a lustful, content-addressed eye. What if there was “Git for Context”? What would it look like? What features would developers love? This article won’t just answer those questions — it will answer them with a demo.

Context#

I’m sure most people already know this but let’s start with a quick definition of context. Context is the prompt and additional metadata that is sent to a large language model to produce a response. One of the key innovations with agents was the ability to iterate on a context/response action loop, combined with tool use to allow agents to do useful work like writing code. Agents generally have an append-only context with a compaction step when it gets too big.

For most agents, full context is hidden from the user, but you can dig into files in your .claude or .codex. It started as raw text files, but recently, most agents are discovering the need for structured data in context for more targeted retrieval, quality control, and concurrency management. So now you’ll see a lot of JSON format files and even, for the more cutting edge agents, SQLite files.

Open Code#

Enter Open Code, the most popular open source coding agent. An open source coding harness? Yes please.

Obviously, as an open source company ourselves, we love and support open source. One of the benefits of open source is that you can show, not tell. We saw Open Code migrated their persistence to SQLite and thought “How hard would it be to add version control for context using Dolt or DoltLite? It’s already SQL.”

Even the maintainers were goading us into it. This quote is ripped from one of their issues.

This is not very big or complex data.

Sounds like a perfect place to add version control.

Why Version Control Context?#

I wrote a whole article about agentic memory that makes a deeper case for version-controlled context: Git for Context.

But for Open Code in particular, we think Git for Context starts first and foremost as a development tool for Open Code contributors. What specifically happens to context after compaction? What if I compact 10 times on 10 different branches? How consistent is compaction? What if I manually strip out code comments from context on one branch and leave them on another? I’ll compare the context and code after 5 turns. Branches and diffs are powerful development tools for testing and comparing different strategies in the probabilistic environment agents live in. Could Git for Context make Open Code better, faster?

If Open Code contributors find Git for Context useful, maybe the most useful features could become user facing features? Having ten sub-agents work from the same context base on branches, comparing outputs, and merging good outcomes seems like a workflow that could work for some tasks. My only hesitation is the user experience. Adding version control to anything is a UX challenge.

But I think the most important user-facing feature would probably be context preservation. It seems weird to me already that we don’t push the context of our coding agents up to an immutable repository and link to it in our pull requests. Stored context is the agent stack trace. When something goes wrong, surely we will want humans or even other agents to dig through the context to figure out what happened. This can be closely linked to multiplayer mode. Pull an agent’s context locally and have an agentic engineering expert resume the session where it went off the rails as a teaching moment for other engineers. This is more GitHub for Context than Git for Context, but you can’t have one without the other.

Why Talk When You Can Show?#

We built it! You can check out version-controlled Open Code on GitHub, also free and open source.

Clone and Build our Open Code Fork#

First, you need to clone and build our Open Code fork. Before you get started, make sure you have bun installed. The example assumes you are running OSX with an ARM64 chip. If your architecture is different, the commands below will be similar but for your architecture.

cd ~/opencode-demo
git clone git@github.com:dolthub/opencode.git
cd opencode
bun install
cd opencode/packages/opencode
bun run build --single --skip-install --skip-embed-web-ui
mv dist/opencode-darwin-arm64/bin/opencode ~/bin/

Now, you have an opencode binary in ~/bin. If ~/bin is at the front f your PATH your PATH, you can just run opencode or you can run it directly with a full path.

But first, let’s create and start a Dolt server to house your version-controlled context. I would do this in a new shell so you can watch the query logs.

cd ~/opencode-demo
mkdir db
cd db
dolt init
dolt sql -q "CREATE USER 'dolt'@'%' IDENTIFIED BY 'pass1234';"
dolt sql -q "GRANT ALL PRIVILEGES ON *.* TO 'dolt'@'%';'"
dolt sql -q "CREATE DATABASE opencode;"
dolt sql-server -H127.0.0.1 --loglevel DEBUG

Try It#

Now, you’re ready to try version-controlled OpenCode.

OPENCODE_MYSQL_URL=mysql://dolt:pass1234@127.0.0.1:3306/opencode ~/bin/opencode ~/myproject/

Version-controlled Open Code exposes the following new version control commands. If you’re familiar with Git, these will look familiar.

/commit <message>

/log

/branch [-v]
/branch <name> <ref>
/branch <name> <[prompt_index]> -m <message>

/checkout <branch_name>
/checkout -b <branch_name>

/reset
/reset <ref>
/reset <[prompt_index]>

/context [--show]
/context <ref> [--show]

/diff-stat
/diff-stat <ref>
/diff-stat <ref1> <ref2>

/diff-context
/diff-context <ref>
/diff-context <ref1> <ref2>`

/history [-v]
/history <ref> [-v]

/sql <SQL STATEMENT>

Demo#

As many of you know, my pet project is DoltLite, a fork of SQLite with Dolt-inspired version control. I asked Open Code to clone a copy and give it a code review, making commits along the way. I’m just going to show the diff functionality today and come up with a more complex demo for another blog article.

ok. we're going to be working on doltlite. can you give it a code review for duplicate code?

There was a lot of output. But how did the context change? I can use /diff-stat for a raw view of what’s changed in my context.

[/diff-stat]
Diff stat HEAD → WORKING
message:
  rows:   3 → 35 (+32)
  added:    +32 rows, +160 cells
  deleted:  -0 rows, -0 cells
  modified: ~0 rows, ~0 cells
  data:   0 B → 13.5 KB (+13.5 KB)
    added rows:    +13.5 KB
    deleted rows:  -0 B
    modified rows: 0 B
part:
  rows:   9 → 142 (+133)
  added:    +133 rows, +798 cells
  deleted:  -0 rows, -0 cells
  modified: ~0 rows, ~0 cells
  data:   0 B → 248.5 KB (+248.5 KB)
    added rows:    +248.5 KB
    deleted rows:  -0 B
    modified rows: 0 B
todo:
  rows:   0 → 5 (+5)
  added:    +5 rows, +35 cells
  deleted:  -0 rows, -0 cells
  modified: ~0 rows, ~0 cells

Now, I’ll make another /commit and ask Open Code to fix the first item in the review.

After a few minutes, I’ll use /diff-context this time to see a more human readable diff.

[/diff-context]
Context diff HEAD → WORKING
Model:           opencode/big-pickle (unchanged)
Messages:        64 → 124 (+60)
  assistant    32 → 62 (+30)
  tool         29 → 58 (+29)
  user         3 → 4 (+1)
Tool calls:      41 → 75 (+34)
Total chars:     168023 → 275974 (+107951)
Approx tokens:   42006 → 68994 (+26988)
Changes by position:
  [0..63]  identical (64 msgs)
  [64]      added    user (+57 chars)
  [65]      added    assistant (+20832 chars)
  [66]      added    tool (+803 chars)
  [67]      added    assistant (+919 chars)
  [68]      added    tool (+3971 chars)
  [69]      added    assistant (+710 chars)
  [70]      added    tool (+1663 chars)
  [71]      added    assistant (+8361 chars)
  [72]      added    tool (+790 chars)
  [73]      added    assistant (+625 chars)
  [74]      added    tool (+4655 chars)
  [75]      added    assistant (+391 chars)
  [76]      added    tool (+1364 chars)
  [77]      added    assistant (+4381 chars)
  [78]      added    tool (+149 chars)
  [79]      added    assistant (+953 chars)
  [80]      added    tool (+805 chars)
  [81]      added    assistant (+306 chars)
  [82]      added    tool (+9912 chars)
  [83]      added    assistant (+8428 chars)
  [84]      added    tool (+149 chars)
  [85]      added    assistant (+3446 chars)
  [86]      added    tool (+150 chars)
  [87]      added    assistant (+715 chars)
  [88]      added    tool (+150 chars)
  [89]      added    assistant (+681 chars)
  [90]      added    tool (+807 chars)
  [91]      added    assistant (+662 chars)
  [92]      added    tool (+17608 chars)
  [93]      added    assistant (+18140 chars)
  [94]      added    tool (+149 chars)
  [95]      added    assistant (+720 chars)
  [96]      added    tool (+809 chars)
  [97]      added    assistant (+298 chars)
  [98]      added    tool (+141 chars)
  [99]      added    assistant (+294 chars)
  [100]      added    tool (+1141 chars)
  [101]      added    assistant (+1398 chars)
  [102]      added    tool (+135 chars)
  [103]      added    assistant (+1117 chars)
  [104]      added    tool (+135 chars)
  [105]      added    assistant (+506 chars)
  [106]      added    tool (+8433 chars)
  [107]      added    assistant (+421 chars)
  [108]      added    tool (+4157 chars)
  [109]      added    assistant (+1946 chars)
  [110]      added    tool (+542 chars)
  [111]      added    assistant (+525 chars)
  [112]      added    tool (+624 chars)
  [113]      added    assistant (+1340 chars)
  [114]      added    tool (+274 chars)
  [115]      added    assistant (+811 chars)
  [116]      added    tool (+263 chars)
  [117]      added    assistant (+507 chars)
  [118]      added    tool (+417 chars)
  [119]      added    assistant (+2730 chars)
  [120]      added    tool (+291 chars)
  [121]      added    assistant (+847 chars)
  [122]      added    tool (+809 chars)
  [123]      added    assistant (+1562 chars)

Compare this to my next make a pr prompt. Much lighter weight.

  [/diff-context]
Context diff HEAD → WORKING
Model:           opencode/big-pickle (unchanged)
Messages:        124 → 136 (+12)
  assistant    62 → 68 (+6)
  tool         58 → 63 (+5)
  user         4 → 5 (+1)
Tool calls:      75 → 82 (+7)
Total chars:     275974 → 298799 (+22825)
Approx tokens:   68994 → 74700 (+5706)
Changes by position:
  [0..123]  identical (124 msgs)
  [124]      added    user (+34 chars)
  [125]      added    assistant (+971 chars)
  [126]      added    tool (+20477 chars)
  [127]      added    assistant (+449 chars)
  [128]      added    tool (+418 chars)
  [129]      added    assistant (+1098 chars)
  [130]      added    tool (+382 chars)
  [131]      added    assistant (+342 chars)
  [132]      added    tool (+327 chars)
  [133]      added    assistant (+1061 chars)
  [134]      added    tool (+174 chars)
  [135]      added    assistant (+215 chars)

The agent created this PR which failed CI with a build error on the sqllogictest job. I made another commit and then asked the agent to fix its build. At this point, the agent was ready for compaction and I hit a bug in our prototype. I have it trying to fix itself now.

As you can see, this diff functionality would be very useful for Open Code developers to track the evolution of context, especially under code changes to Open Code.

Conclusion#

We’re definitely looking for feedback here. Please try out this harness and tell us what you think. Were the Git features useful? Do you want to see others? As always, you can come chat with us on our Discord or create a GitHub issue.

How Fast Is DoltLite?

Tim Sehn — Mon, 08 Jun 2026 00:00:00 GMT

A couple months ago, we released DoltLite, a free open-source drop-in replacement for SQLite with Dolt-style version control features. DoltLite works by ripping out SQLite’s B-Tree storage engine and replacing it with a content-addressed Prolly Tree, the same data structure that powers Dolt.

We’ve been benchmarking Dolt against MySQL for years using sysbench. Recently, Dolt got faster than MySQL on sysbench. But, Dolt and MySQL are completely separate SQL engines. Most of the performance difference comes from the SQL engine, not the B-tree vs Prolly Tree difference. “How much?”, you ask. It was hard to tell.

Until now. DoltLite is SQLite from the B-tree interface up, in other words, the same SQL engine. The only difference between DoltLite and SQLite is B-tree versus Prolly Tree, a true performance bake off. We can finally answer the question “What’s the Prolly Tree performance tax?” This article does just that.

The Prolly Tree Tax#

Here’s the whole article in one table. Same SQL engine on both sides, so every number below is purely the Prolly Tree versus SQLite’s B-tree, nothing else. We run in memory to keep it a clean race, with no disk or page cache to muddy the result. The one exception is autocommit writes, which only mean anything on disk, since committing is a durability cost. Lower is better for DoltLite:

Workload	Prolly Tree tax
Reads	1.20x — a 20% tax
Batched writes	1.67x — a 67% tax
Autocommit writes	4.00x — the real tax lives here

The Prolly Tree tax is modest on reads, noticeable on batched writes, and only really bites when you commit every single write. And on that last one you usually have an out: batch your writes in a transaction.

A True Bake-Off#

DoltLite is a drop-in replacement for SQLite, and that’s exactly what makes this measurement clean. Everything from the B-tree interface up — the parser, the planner, the whole SQL engine — is line-for-line SQLite. The only thing we changed is the storage engine underneath. So when we run the identical SQL through both and compare, the difference is the Prolly Tree tax, isolated. No SQL-engine variable muddying the result the way there is when we benchmark Dolt against MySQL.

To isolate the data structure even further, the numbers in this article are from in-memory databases. That strips out the disk and the page cache, leaving the raw cost of walking and updating a Prolly Tree instead of a B-tree.

We build stock SQLite straight out of the same source tree (make DOLTLITE_PROLLY=0 sqlite3) and run a sysbench-style OLTP suite against both on every PR: 100,000-row tables, the median of 5 invocations per test (9 for autocommit writes), workload-only timing off a monotonic clock. CI enforces a hard ceiling: 2.5x on any individual test, 2x on a section average. The build goes red if we regress performance. We run the whole thing four times with different key types: integer, text, blob, and composite.

The full table gets posted as a comment on every PR.

Reads#

In memory, reads cost about 20% more than SQLite:

Test	SQLite (us)	DoltLite (us)	Multiplier
oltp_point_select	23,710	29,457	1.24
oltp_range_select	10,124	11,930	1.18
oltp_sum_range	9,490	11,938	1.26
oltp_order_range	2,572	2,953	1.15
oltp_distinct_range	3,628	4,013	1.11
oltp_index_scan	3,951	5,275	1.34
select_random_points	10,245	11,268	1.10
select_random_ranges	2,979	4,117	1.38
covering_index_scan	4,124	4,380	1.06
groupby_scan	30,945	33,884	1.09
index_join	6,005	8,159	1.36
index_join_scan	3,396	4,597	1.35
types_table_scan	1,057,625	1,218,914	1.15
table_scan	1,233,810	1,304,540	1.06
oltp_read_only	102,177	120,120	1.18
Average			1.20

Why 20%? A Prolly Tree node is content-addressed, so every step down the tree is a hash lookup in the chunk cache plus a decode of the node’s packed key/value layout, where SQLite’s B-tree just follows a page pointer. That extra indirection is the tax.

Batched Writes#

Batched into a transaction, writes cost about 67% more in memory:

Test	SQLite (us)	DoltLite (us)	Multiplier
oltp_bulk_insert	181,919	253,557	1.39
oltp_insert	15,472	27,785	1.80
oltp_update_index	51,887	89,758	1.73
oltp_update_non_index	34,388	59,641	1.73
oltp_delete_insert	46,005	71,917	1.56
oltp_write_only	22,530	44,628	1.98
types_delete_insert	24,611	40,401	1.64
oltp_read_write	72,397	108,598	1.50
Average			1.67

A 67% tax to get full history, branching, diff, and merge on your data. Sounds like a good trade to me.

Writes cost more than reads because a Prolly Tree is immutable. Changing one row can’t overwrite a node in place the way a B-tree does. It re-hashes that node and every node above it up to the root, allocating new content-addressed chunks along the way. That’s more work per write, even inside a single transaction. The flip side is that the very same immutability is what buys you cheap branching and content-addressed diffs.

Autocommit Writes#

It was going so well. Committing every write is where the Prolly Tree performance story gets a little gnarly. This is the one section measured on disk: a commit is a durable write, so it only means anything with a real file behind it.

Test	SQLite (us)	DoltLite (us)	Multiplier
oltp_bulk_insert_ac	20,541	75,772	3.69
oltp_insert_ac	23,297	91,726	3.94
oltp_update_index_ac	26,183	104,527	3.99
oltp_update_non_index_ac	21,466	86,763	4.04
oltp_delete_insert_ac	22,961	96,960	4.22
oltp_write_only_ac	23,384	95,285	4.07
types_delete_insert_ac	20,889	93,985	4.50
oltp_read_write_ac	29,065	103,041	3.55
Average			4.00

About 4x. This is structural, not a bug. Every commit in a Prolly Tree re-hashes the path from the changed leaf up to the root and writes new immutable, content-addressed chunks. That cost is O(log n) in the tree’s depth, but with a bigger constant than SQLite, so it grows as tables get bigger. Back when we ran the suite at 10,000-row tables, autocommit writes were comfortably under 2x, versus the 4x you see here at 100,000 rows. SQLite just mutates a page in place and shifts the index if necessary.

Moreover, DoltLite’s content-addressed store must update more physical locations on disk as well as the manifest and the branch HEADs. This just adds to the performance overhead.

Keep DoltLite Fast#

The sysbench metrics suggest two pieces of DoltLite performance advice.

Batch Writes#

The autocommit write fix is the same advice you’d get for stock SQLite: batch your writes.

BEGIN;
-- thousands of inserts here
COMMIT;

Those same operations get much cheaper the moment you wrap them. Batching amortizes the per-commit re-hashing across thousands of rows, which is exactly why the batched-writes tax (1.67x) is so much smaller than the autocommit one (4x).

Let’s keep the 4x in perspective. That autocommit test is 200 separate committed inserts, ~25ms total in SQLite versus ~100ms in DoltLite. Per write, that’s about 0.125ms versus 0.5ms, both faster than a single frame of video. Unless you’re committing one row at a time in a loop, you will never feel it. So go ahead and use autocommit if it’s easier. For most applications the tax simply won’t matter.

Use Integer Keys#

We run everything with a few different primary key types to see what, say, UUID-shaped keys cost. In memory, text keys push reads to about 1.5x and batched writes to about 1.9x, with range scans climbing toward 2.3x. The takeaway: if you care about speed, integer primary keys are the fast path. UUIDs work, they just cost more.

Conclusion#

So what’s the Prolly Tree tax? For years we could only guess. Dolt is faster than MySQL, but they’re different SQL engines, so the storage layer’s contribution was buried. DoltLite finally lets us measure it in isolation. The Prolly Tree tax is about 20% on reads, 67% on batched writes, and 4x on single-row autocommit writes. Just like my beloved California, the taxes are worth it. In California, you get the weather. With DoltLite, you get the version control.

Packing your bags and joining the DoltLite gold rush? Come by our Discord, and we’ll give you a warm welcome in the #doltlite🪶 channel.

Announcing Dumbo Garbage Collection

Neil Macneale — Tue, 02 Jun 2026 00:00:00 GMT

DumboDB is a document database inspired by MongoDB, built on top of Dolt’s storage. DumboDB combines the flexibility of a document database with the power of Git-like version control, allowing you to track changes, branch, and merge your data with ease.

It’s early days for DumboDB, but thanks to leveraging Dolt’s underlying architecture, we’re able to rapidly iterate and add new features. In release 0.1.3, we’re excited to announce the addition of garbage collection (GC) to DumboDB!

What is Garbage Collection?#

In many databases, as you update your data on disk, old versions of your data will accumulate over time. Cleaning up this data goes by many names. In PostgreSQL, it’s called VACUUM. In MySQL, it’s called purging. In Dolt, it’s called garbage collection.

In traditional databases, it makes sense that garbage would exist. When you update a row in a table, the old version of that row is still on disk until the database decides to clean it up.

Dolt and Dumbo are version-controlled databases, so it’s reasonable to assume we store every version of the data forever. Unfortunately, it’s not that simple. Dolt and Dumbo keep track of all committed data, specifically data that has been committed to the database and is part of the commit history.

In scenarios where you insert or update many documents, there are intermediate versions of the data that are not committed to the commit history. These intermediate versions take up disk space and may not be necessary to keep around indefinitely. This is where garbage collection comes in.

How Does Dumbo’s Garbage Collection Work?#

The short answer is that it’s just like Dolt’s Session Aware GC.

I won’t go into that level of detail here, but at a high level, every chunk of data in a Dolt (and Dumbo) database must be reachable from the commit history of all branches. We build a list of all chunks in the database, then walk the commit history to find all chunks that are reachable from commits. Any chunks that are not reachable from the commit history are considered garbage and can be safely deleted.

This becomes more complicated when you consider that there may be active sessions in the database that are still using some of the intermediate versions of the data. We don’t want to delete any chunks that are still being used by active sessions, so we need to keep track of those as well.

Dolt’s GC process takes this into account by keeping track of the active sessions and ensuring that any chunks that are still being used by those sessions are not deleted during the GC process. This allows us to safely clean up any garbage data without affecting any active operations in the database.

DumboDB uses the same storage engine as Dolt, so we were able to leverage the existing GC implementation in Dolt to add GC support to DumboDB. This means that DumboDB can now automatically clean up any garbage data that may be taking up space on disk, without affecting any active sessions or operations in the database.

Using Garbage Collection in DumboDB#

Garbage collection has been added in the latest release of DumboDB.

Be sure that the mongo driver is installed for Python:

pip install pymongo

Then create a script that creates a bunch of garbage chunks. Put this text in a file called make_garbage.py:

import random
import secrets
from pymongo import MongoClient

client = MongoClient("mongodb://127.0.0.1:27017")
db = client["gcdemo"]
coll = db["items"]

for b in range(50):
    docs = []
    for i in range(100):
        docs.append({
            "_id":   f"b{b}-d{i}-{secrets.token_hex(4)}",
            "name":  f"user-{secrets.token_hex(3)}",
            "email": f"{secrets.token_hex(4)}@example.com",
            "age":   random.randint(18, 80),
            "score": random.random() * 100,
        })
    coll.insert_many(docs)
    db.command({"dumboCommit": 1, "message": f"batch {b}", "author": "gcdemo <gcdemo@example.com>"})
    print(f"batch {b + 1}/50 committed")

client.close()

This script creates 50 commits, each with 100 new random documents. As a result, it creates a lot of intermediate data versions that are not committed to the commit history and are therefore considered garbage. Run the script:

$ python make_garbage.py
batch 1/50 committed
batch 2/50 committed
[... snip ...]
batch 49/50 committed
batch 50/50 committed

In another file, run_gc.py, add the following code to trigger the GC process:

from pprint import pprint
from pymongo import MongoClient

client = MongoClient("mongodb://127.0.0.1:27017")

res = client["gcdemo"].command({"dumboGC": 1})

pprint(dict(res))
client.close()

When you run this script, it will trigger the GC process in DumboDB and print out the results:

$ python run_gc.py
{'chunksAfter': 6608.0,
 'chunksBefore': 7119.0,
 'db': 'gcdemo',
 'durationMs': 163.0,
 'mode': 'default',
 'ok': 1.0,
 'sizeAfter': 5929327.0,
 'sizeBefore': 7452156.0}

The command returns statistics about the number of chunks before and after the GC process, the database size before and after, and how long the GC process took to run.

Comparison to Dolt#

One of the reasons I wanted to add GC to DumboDB is to see how Dumbo’s storage usage compares to Dolt’s. I added parity tests to generate equivalent data in both Dolt and Dumbo, then ran GC on both databases to see how much space was used for each.

The results aren’t fantastic, I’m not gonna lie. There is clearly something amiss. When storing about 1M documents, Dumbo is using about 6x the amount of space after GC compared to Dolt.

It’s not clear yet if this is the result of a bug in how Dumbo stores data or if we are being too conservative when we garbage collect. As we discussed in a previous post, this kind of side-by-side comparison is one of the main ways we can verify that a vibe-coded product such as Dumbo is working correctly. My gut says that we should have collected more data in our example and we are being too conservative. We will be investigating this issue in the coming weeks and will share our findings in a future blog post.

What’s Next?#

Sorting out the storage discrepancy just mentioned is the top priority. After we sort that out, automatic garbage collection is the next step. Similar to Dolt, when the server determines that there is a reasonable amount of garbage data that can be cleaned up, it will automatically trigger the GC process. This will help ensure that your DumboDB instance stays clean and efficient without requiring manual intervention.

Want to learn more about Dolt and Dumbo? Hop on our Discord to ask questions and nerd out about version-controlled databases!

Evolving with Beads

Dustin Brown — Fri, 29 May 2026 00:00:00 GMT

Beads is a tool for extending the memory of coding agents, such as Claude Code, allowing them to manage tasks (i.e. beads) themselves. It was originally built by Steve Yegge and is now part of Gaslandia, which comprises of Beads, Gastown, Gas City, and Wasteland. Beads is backed by Dolt, and version v1.0.5 is available now.

In today’s blog, I’ll cover a common question we’ve seen from Beads users about how to evolve with the tool: “I’ve been using Beads classic and want to know how to move to server mode, when should I do that, and how do I do that?” I’ll answer this by migrating from the most simple, “classic”, single-agent mode to the server and shared-server modes that better support multi-agent workflows.

Beads Classic#

Most Beads users use the “classic” mode of Beads, which provides a coding-agent persistent memory and an interface for self-managing it. In this example, I have the latest Dolt installed, v2.0.8, and will make a new Git project where my coding agent will work.

➜  repros git:(main) dolt version
dolt version 2.0.8
➜  repros git:(main) ✗ mkdir evolving_demo
➜  repros git:(main) ✗ cd evolving_demo
➜  evolving_demo git:(main) ✗ echo "# evolving_demo" >> README.md
➜  evolving_demo git:(main) ✗ git init
Initialized empty Git repository in /home/dustin/cursor_src/repros/evolving_demo/.git/
➜  evolving_demo git:(main) ✗ git add .
➜  evolving_demo git:(main) ✗ git commit -m 'README.md'
[main (root-commit) 9dffb6e] README.md
 1 file changed, 1 insertion(+)
 create mode 100644 README.md
➜  evolving_demo git:(main) git remote add origin https://github.com/coffeegoddd/evolving_demo.git
➜  evolving_demo git:(main) git push origin main
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Writing objects: 100% (3/3), 250 bytes | 250.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)
To https://github.com/coffeegoddd/evolving_demo.git
 * [new branch]      main -> main
➜  evolving_demo git:(main)

I’ve initialized my git project and pushed it to GitHub as well. Next, I also have the latest version of Beads installed, and I can run bd init to initialize the project with everything my agent will need to use Beads successfully.

➜  evolving_demo git:(main) ✗ bd version
bd version 1.0.5 (dev: 801fb95d1767)
➜  evolving_demo git:(main) bd init
  ✓ Configured Dolt remote: origin → git+https://github.com/coffeegoddd/evolving_demo.git
  Repository ID: 76062c1e
  Clone ID: 642acc6d98a2785e

▶ Already configured as: maintainer
Change role? [y/N]: n

▶ Auto-export can keep .beads/issues.jsonl up to date after write commands.
  This optional JSONL export is useful for viewers (bv), interchange, and issue-level migration.
  Dolt remotes/backups handle cross-machine sync and backup.

Enable auto-export? [y/N]: n
  ✓ Auto-export disabled (enable later with: bd config set export.auto true)
  Hooks installed to: .beads/hooks/
  ✓ Created AGENTS.md with agent instructions
Installing Claude hooks for this project...
✓ Registered SessionStart hook
Installing Claude Code integration...
✓ Created new CLAUDE.md with beads integration

✓ Claude Code integration installed
  File: /home/dustin/cursor_src/repros/evolving_demo/CLAUDE.md
No additional configuration needed!

✓ Claude Code integration installed
  Settings: /home/dustin/cursor_src/repros/evolving_demo/.claude/settings.json

Restart Claude Code for changes to take effect.
Installing Beads agent skill...
✓ Beads agent skill installed
  Skill: /home/dustin/cursor_src/repros/evolving_demo/.agents/skills/beads/SKILL.md
Installing Codex native hooks for this project...
✓ Codex native hooks installed
Installing Codex instructions for this project...
✓ Codex instructions installed
  File: /home/dustin/cursor_src/repros/evolving_demo/AGENTS.md
Restart Codex if it is already running.
  ✓ Committed beads files to git

⚠ Git upstream not configured
  For sync workflows, set your upstream with:
  git remote add upstream <repo-url>


✓ bd initialized successfully!

  Backend: dolt
  Mode: embedded
  Database: evolving_demo
  Issue prefix: evolving_demo
  Issues will be named: evolving_demo-<hash> (e.g., evolving_demo-a3f2dd)

Run bd quickstart to get started.

Importantly, always choose the role ‘maintainer’ and choose ‘no’ for auto-export.

Contributor mode is outside the scope of this blog, and auto-export is a legacy feature.

After Beads is initialized in my repo, I can create a sample bead to test it out before my agent takes over.

➜  evolving_demo git:(main) bd create "my first bead" -t task -p 2
✓ Created issue: evolving_demo-0v4 — my first bead
  Priority: P2
  Status: open

💡 Tip: Install the beads plugin for automatic workflow context, or run 'bd setup claude' for CLI-only mode
➜  evolving_demo git:(main) bd list
○ evolving_demo-0v4 ● P2 my first bead

--------------------------------------------------------------------------------
Total: 1 issues (1 open, 0 in progress)

Status: ○ open  ◐ in_progress  ● blocked  ✓ closed  ❄ deferred

Next, I’ll delete this sample issue and turn things over to Claude to start working.

➜  evolving_demo git:(main) bd delete evolving_demo-0v4 --force
✓ Deleted evolving_demo-0v4
  Removed 0 dependency link(s)
  Updated text references in 0 issue(s)

Starting my agent in the repo brings it up with all the context it needs to use Beads on its own, so I can just talk to the agent normally, and it will get to work.

In this example I’ve asked it to write me a news fetching application, and when Claude starts working, I can see what it’s doing in the bd list output.

➜  evolving_demo git:(main) bd list
○ evolving_demo-2wo ● P2 Unit test RSS client with httptest fixture
○ evolving_demo-gby ● P2 Implement output formatters (text and JSON)
◐ evolving_demo-mlq ● P2 Scaffold Go module and CLI entry point
○ evolving_demo-p5d ● P2 Implement Google News RSS client
○ evolving_demo-y7r ● P2 Wire main.go: client + formatter + error handling
○ evolving_demo-6ed ● P3 Write README with build and usage instructions

--------------------------------------------------------------------------------
Total: 6 issues (5 open, 1 in progress)

Status: ○ open  ◐ in_progress  ● blocked  ✓ closed  ❄ deferred

When Claude is done, it closes the beads it worked on, and my app is ready to use. But Claude did not know that it can push the beads of this repo up to GitHub too, just like it pushes code, so I let Claude know.

● Committed as 9ed3470. Working tree clean, only the gitignored usnews binary remains untracked. All 6 beads issues closed. No
  remote to push to.

✻ Baked for 25s

❯ there is a remote, try bd dolt push

● Bash(bd dolt push)
  ⎿  Pushing to Dolt remote...
     Push complete.

● Beads pushed. Now checking the git remote.

It actually used to be the case that there was nothing visible on GitHub when using it as a Dolt remote, but we recently added some visual cues to more easily tell that your Git repo has Dolt data.

Git Dolt remotes now also create and push to a branch __dolt_remote_info__, and this branch will have a file updated on each dolt push that tells you the ref Dolt is using and its HEAD sha.

This is the standard Beads Classic usage pattern and app development style. And the application Claude wrote works great.

➜  evolving_demo git:(main) go run .
 1. U.S., Iran nearing deal to end war and reopen Strait of Hormuz — The Washington Post (1h ago)
 2. Judge halts Trump ‘anti-weaponization’ fund after Jan. 6 prosecutor sues — NBC News (1h ago)
 3. Former AG Pam Bondi testifies before Congress over handling of the Epstein files — NPR (23m ago)
 4. Romania Says It Could Invoke NATO’s Article 4. What Would That Do? — The New York Times (4h ago)
 5. Kenyan court halts US plans for Ebola quarantine facility for Americans — politico.eu (5h ago)
 6. Trump Loses It at Jill Biden in Morning Rage Post — The Daily Beast (4h ago)
 7. Bus hits cars in Virginia, killing 5 people and injuring 34, state police say — AP News (3h ago)
 8. California House Primary in Sacramento Displays Democrats’ Fierce Generational Battle — The New York Times (7h ago)
 9. Mullin plan to punish sanctuary jurisdictions by targeting their airports faces fierce headwinds — CNN (7h ago)
10. In Carroll Lawsuits Inquiry, Scrutiny Turns Toward Private Citizens Who Antagonized Trump — The New York Times (51m ago)

Server Mode#

The next phase of evolving with Beads is transitioning from classic to server mode. Server mode here means Beads will run a local Dolt server on your host, instead of using the non-server embedded Dolt mode, which is the default.

But why use server mode in the first place?

The reason users may want to consider running Beads in server mode is because it allows you to run many coding agent sessions against the same Git repo, since server mode is designed for multi-process concurrent use. This is a limitation of Beads classic, which is single-writer.

To migrate from classic mode to server mode, let’s first make a new bead that we can easily track across the migration from classic to server mode.

➜  evolving_demo git:(main) ✗ bd create "from classic to server mode" -p 2
✓ Created issue: evolving_demo-w1g — from classic to server mode
  Priority: P2
  Status: open

Then, to perform the migration we actually want to take a backup of our Beads database in classic mode, then after we initialize Beads in server mode, we’ll restore from the backup, which will give us our database back.

To do this I first make a new directory to use as my database backup, then initialize it with the bd backup init command. After initialization I can run bd backup sync to sync my database to the backup destination.

➜  evolving_demo git:(main) ✗ mkdir ../ed_backup_1
➜  evolving_demo git:(main) ✗ bd backup init ../ed_backup_1
Backup destination configured: file:///home/dustin/cursor_src/repros/ed_backup_1
Run 'bd backup sync' to push your data.
➜  evolving_demo git:(main) ✗ bd backup sync

Backup synced in 20ms

With the backup synced, I can then remove the .beads directory in my Git repo, which will delete the classic mode database (or just mv it to not be named .beads just in case), and then re-initialize Beads using the --server flag.

➜  evolving_demo git:(main) ✗ rm -rf .beads
➜  evolving_demo git:(main) ✗ bd init --server
Bootstrapped from remote: git+https://github.com/coffeegoddd/evolving_demo.git
Synced database from git+https://github.com/coffeegoddd/evolving_demo.git
  ✓ Bootstrapped from remote: git+https://github.com/coffeegoddd/evolving_demo.git
  Repository ID: 76062c1e
  Clone ID: 642acc6d98a2785e
  ✓ Adopted project identity from existing database

▶ Already configured as: maintainer
Change role? [y/N]: n

▶ Auto-export can keep .beads/issues.jsonl up to date after write commands.
  This optional JSONL export is useful for viewers (bv), interchange, and issue-level migration.
  Dolt remotes/backups handle cross-machine sync and backup.

Enable auto-export? [y/N]: n
  ✓ Auto-export disabled (enable later with: bd config set export.auto true)
  Hooks installed to: .beads/hooks/
  ✓ Updated beads section in AGENTS.md to latest format
Installing Claude hooks for this project...
✓ Hook already registered: SessionStart
Installing Claude Code integration...
✓ Updated existing beads section in CLAUDE.md

✓ Claude Code integration installed
  File: /home/dustin/cursor_src/repros/evolving_demo/CLAUDE.md
No additional configuration needed!

✓ Claude Code integration installed
  Settings: /home/dustin/cursor_src/repros/evolving_demo/.claude/settings.json

Restart Claude Code for changes to take effect.
Installing Beads agent skill...
✓ Beads agent skill installed
  Skill: /home/dustin/cursor_src/repros/evolving_demo/.agents/skills/beads/SKILL.md
Installing Codex native hooks for this project...
✓ Codex native hooks installed
Installing Codex instructions for this project...
✓ Codex instructions installed
  File: /home/dustin/cursor_src/repros/evolving_demo/AGENTS.md
Restart Codex if it is already running.
  ✓ Committed beads files to git

✓ bd initialized from git remote!

  Backend: dolt
  Mode: server
  Server: root@127.0.0.1:46091

  ⚠ Server host defaulted to 127.0.0.1.
    If your Dolt server is remote, set BEADS_DOLT_SERVER_HOST or pass --server-host.
  Database: evolving_demo
  Issue prefix: evolving_demo
  Issues will be named: evolving_demo-<hash> (e.g., evolving_demo-a3f2dd)

Run bd quickstart to get started.

As before, I keep my role as ‘maintainer’ and decline auto-export. This time though Beads is using a local server running on port 46091, as shown in the output above.

Now I can restore from the backup I made earlier to get all my beads back.

➜  evolving_demo git:(main) bd backup restore ../ed_backup_1 --force
✓ Restore complete
➜  evolving_demo git:(main) ✗ bd list
○ evolving_demo-w1g ● P2 from classic to server mode

--------------------------------------------------------------------------------
Total: 1 issues (1 open, 0 in progress)

Status: ○ open  ◐ in_progress  ● blocked  ✓ closed  ❄ deferred

And you can see that the bead I made is available and ready. I can also see the “status” of my Beads server by running bd dolt status.

➜  evolving_demo git:(main) ✗ bd dolt status
Dolt server: running
  PID:  778645
  Port: 46091
  Data: /home/dustin/cursor_src/repros/evolving_demo/.beads/dolt
  Logs: /home/dustin/cursor_src/repros/evolving_demo/.beads/dolt-server.log
➜  evolving_demo git:(main) ✗

If I wanted to actually poke around in the state of my Beads database, I could do so with a standard MySQL client. As of this blog, Beads servers always run with root and no password.

➜  evolving_demo git:(main) ✗ docker run --rm -it --network host mysql:8 mysql -h 127.0.0.1 -P 46091 -u root
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 27
Server version: 8.0.33 Dolt

Copyright (c) 2000, 2026, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| dolt               |
| evolving_demo      |
| information_schema |
| mysql              |
+--------------------+
4 rows in set (0.00 sec)

mysql> use evolving_demo;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> select count(*) from issues;
+----------+
| count(*) |
+----------+
|        7 |
+----------+
1 row in set (0.00 sec)

mysql> exit
Bye

Our issue count in our restored database has our bead that we tracked across the classic to server migration and the six now closed issues used to build the news application.

From this point forward, we could continue to use Beads in single-player mode as we did with classic mode, or we could open multiple terminal sessions against this repo and dispatch agents in each in parallel (non-overlapping) feature work.

Shared-server Mode#

Lastly, let’s say I’ve been enjoying using Beads on many projects on my host, both in classic mode and server mode, but have noticed that each server mode project spins up a new Dolt sql-server process. Instead of doing this, can Beads run just a single Dolt sql-server for all my projects?

Why yes it can, and this is the motivation behind shared-server mode. In this mode, Beads will manage a single global Dolt server that can house all Beads for your Git projects on the host, and these Beads will be isolated, so Beads will not leak between projects.

To migrate from normal --server mode to --shared-server mode, we simply need to go through our backup and restore flow we did above, making sure to stop the running --server mode process before starting the new --shared-server process. If you have many --server mode Beads projects on your host, you’ll want to do this for each one.

To start, let’s remove the old bead we made and make a new one to watch across the migration.

➜  evolving_demo git:(main) bd list
○ evolving_demo-w1g ● P2 from classic to server mode

--------------------------------------------------------------------------------
Total: 1 issues (1 open, 0 in progress)

Status: ○ open  ◐ in_progress  ● blocked  ✓ closed  ❄ deferred
➜  evolving_demo git:(main) bd delete evolving_demo-w1g --force
✓ Deleted evolving_demo-w1g
  Removed 0 dependency link(s)
  Updated text references in 0 issue(s)
➜  evolving_demo git:(main) ✗ bd list
No issues found.
➜  evolving_demo git:(main) ✗ bd create "from server to shared-server" -p 2
✓ Created issue: evolving_demo-pz8 — from server to shared-server
  Priority: P2
  Status: open
➜  evolving_demo git:(main) ✗ bd list
○ evolving_demo-pz8 ● P2 from server to shared-server

--------------------------------------------------------------------------------
Total: 1 issues (1 open, 0 in progress)

Status: ○ open  ◐ in_progress  ● blocked  ✓ closed  ❄ deferred

Next, we will need a new backup directory for our existing --server mode Beads database.

➜  evolving_demo git:(main) mkdir ../ed_backup_2
➜  evolving_demo git:(main) bd backup init ../ed_backup_2
Backup destination configured: file:///home/dustin/cursor_src/repros/ed_backup_2
Run 'bd backup sync' to push your data.
➜  evolving_demo git:(main) ✗ bd backup sync
Backup synced in 50ms

Once the backup is synced I can stop the --server mode server with bd dolt stop.

➜  evolving_demo git:(main) bd dolt stop
Flushed working set for 1 database(s) before server stop
Dolt server stopped.

Then, like before, I can remove the existing .beads directory in my Git project and reinitialize Beads with the --shared-server flag.

➜  evolving_demo git:(main) ✗ rm -rf .beads
➜  evolving_demo git:(main) ✗ bd init --shared-server
  ✓ Bootstrapped from remote: git+https://github.com/coffeegoddd/evolving_demo.git
  ✓ Shared Dolt server started
  ✓ Global database beads_global available
  ✓ Global database schema initialized
  ✓ Configured Dolt remote: origin → git+https://github.com/coffeegoddd/evolving_demo.git
  Repository ID: 76062c1e
  Clone ID: 642acc6d98a2785e
  ✓ Shared server mode enabled

▶ Already configured as: maintainer
Change role? [y/N]: n

▶ Auto-export can keep .beads/issues.jsonl up to date after write commands.
  This optional JSONL export is useful for viewers (bv), interchange, and issue-level migration.
  Dolt remotes/backups handle cross-machine sync and backup.

Enable auto-export? [y/N]: n
  ✓ Auto-export disabled (enable later with: bd config set export.auto true)
  Hooks installed to: .beads/hooks/
  AGENTS.md already has current agent instructions
Installing Claude hooks for this project...
✓ Hook already registered: SessionStart
Installing Claude Code integration...
✓ Updated existing beads section in CLAUDE.md

✓ Claude Code integration installed
  File: /home/dustin/cursor_src/repros/evolving_demo/CLAUDE.md
No additional configuration needed!

✓ Claude Code integration installed
  Settings: /home/dustin/cursor_src/repros/evolving_demo/.claude/settings.json

Restart Claude Code for changes to take effect.
Installing Beads agent skill...
✓ Beads agent skill installed
  Skill: /home/dustin/cursor_src/repros/evolving_demo/.agents/skills/beads/SKILL.md
Installing Codex native hooks for this project...
✓ Codex native hooks installed
Installing Codex instructions for this project...
✓ Codex instructions installed
  File: /home/dustin/cursor_src/repros/evolving_demo/AGENTS.md
Restart Codex if it is already running.
  ✓ Committed beads files to git

✓ bd initialized from git remote!

  Backend: dolt
  Mode: server
  Server: root@127.0.0.1:3308

  ⚠ Server host defaulted to 127.0.0.1.
    If your Dolt server is remote, set BEADS_DOLT_SERVER_HOST or pass --server-host.
  Database: evolving_demo
  Issue prefix: evolving_demo
  Issues will be named: evolving_demo-<hash> (e.g., evolving_demo-a3f2dd)

Run bd quickstart to get started.

Again, the role is ‘maintainer’ and ‘auto-export’ is disabled.

Now I can restore from my --server backup.

➜  evolving_demo git:(main) bd backup restore ../ed_backup_2 --force
✓ Restore complete
➜  evolving_demo git:(main) ✗ bd list
○ evolving_demo-pz8 ● P2 from server to shared-server

--------------------------------------------------------------------------------
Total: 1 issues (1 open, 0 in progress)

Status: ○ open  ◐ in_progress  ● blocked  ✓ closed  ❄ deferred

And once I do that, I’m successfully running in Shared-server mode!

Bonus#

As I mentioned earlier, Beads are scoped to a single Git repository and single Dolt database, so there is currently no way to share beads across projects.

Except actually, there kinda is… As a maintainer of Beads I snuck in a unique feature to Beads Shared-server mode which seemed like it needed, but didn’t have a way to share beads across projects.

In Shared-server mode there is a unique global beads database that works like a normal Beads database, except it is readable and writeable by all clients of the Shared server. This database is not tied to any specific Git project, so it does not have the same restrictions as ones that are tied to a specific Git project.

For this reason, if you did need to share beads between projects, you can do so by reading and writing beads with the --global flag, which will route the bd command to the global database instead of the project scoped one.

Here’s an example. First let’s delete the old migration bead we made.

➜  evolving_demo git:(main) ✗ bd delete evolving_demo-pz8 --force
✓ Deleted evolving_demo-pz8
  Removed 0 dependency link(s)
  Updated text references in 0 issue(s)

Then, we’ll make another Beads project on our host and register it on the shared server by initializing Beads with --shared-server.

➜  evolving_demo git:(main) bd list
No issues found.
➜  evolving_demo git:(main) cd ..
➜  repros git:(main) ✗ mkdir different_project
➜  repros git:(main) ✗ cd different_project
➜  different_project git:(main) ✗ git init
Initialized empty Git repository in /home/dustin/cursor_src/repros/different_project/.git/
➜  different_project git:(main) echo "# different project" >> README.md
➜  different_project git:(main) ✗ git add .
➜  different_project git:(main) ✗ git commit -m 'README.md'
[main (root-commit) a11c0f1] README.md
 1 file changed, 1 insertion(+)
 create mode 100644 README.md
➜  different_project git:(main) bd init --shared-server
  ✓ Global database beads_global available
  ✓ Global database schema initialized
  Repository ID: ad3c7c9e
  Clone ID: d9436fdceeb5a843
  ✓ Shared server mode enabled

▶ Already configured as: maintainer
Change role? [y/N]: n

▶ Auto-export can keep .beads/issues.jsonl up to date after write commands.
  This optional JSONL export is useful for viewers (bv), interchange, and issue-level migration.
  Dolt remotes/backups handle cross-machine sync and backup.

Enable auto-export? [y/N]: n
  ✓ Auto-export disabled (enable later with: bd config set export.auto true)
  Hooks installed to: .beads/hooks/
  ✓ Created AGENTS.md with agent instructions
Installing Claude hooks for this project...
✓ Registered SessionStart hook
Installing Claude Code integration...
✓ Created new CLAUDE.md with beads integration

✓ Claude Code integration installed
  File: /home/dustin/cursor_src/repros/different_project/CLAUDE.md
No additional configuration needed!

✓ Claude Code integration installed
  Settings: /home/dustin/cursor_src/repros/different_project/.claude/settings.json

Restart Claude Code for changes to take effect.
Installing Beads agent skill...
✓ Beads agent skill installed
  Skill: /home/dustin/cursor_src/repros/different_project/.agents/skills/beads/SKILL.md
Installing Codex native hooks for this project...
✓ Codex native hooks installed
Installing Codex instructions for this project...
✓ Codex instructions installed
  File: /home/dustin/cursor_src/repros/different_project/AGENTS.md
Restart Codex if it is already running.
  ✓ Committed beads files to git

⚠ No Dolt remote configured
  Issues are stored in local Dolt. .beads/issues.jsonl is an export,
  not cross-machine sync or the source of truth.
  To enable durable sync, add a git origin and then run:
    bd dolt push

✓ bd initialized successfully!

  Backend: dolt
  Mode: server
  Server: root@127.0.0.1:3308

  ⚠ Server host defaulted to 127.0.0.1.
    If your Dolt server is remote, set BEADS_DOLT_SERVER_HOST or pass --server-host.
  Database: different_project
  Issue prefix: different_project
  Issues will be named: different_project-<hash> (e.g., different_project-a3f2dd)

Run bd quickstart to get started.

Then, we can use the project as normal, and beads will route to their project scoped database.

➜  different_project git:(main) bd list
No issues found.
➜  different_project git:(main) bd create "my first different project bead" -p 2
✓ Created issue: different_project-s9i — my first different project bead
  Priority: P2
  Status: open

💡 Tip: Install the beads plugin for automatic workflow context, or run 'bd setup claude' for CLI-only mode
➜  different_project git:(main) bd list
○ different_project-s9i ● P2 my first different project bead

--------------------------------------------------------------------------------
Total: 1 issues (1 open, 0 in progress)

Status: ○ open  ◐ in_progress  ● blocked  ✓ closed  ❄ deferred

If we return to our earlier project which also uses this shared-server, you’ll see that it won’t be able to see the bead created and scoped to different_project.

➜  different_project git:(main) cd ../evolving_demo
➜  evolving_demo git:(main) bd list
No issues found.

Buuuuuuuut, if we go back to different_project and create a bead using --global, we’ll create a global bead that all shared-server projects can access.

➜  evolving_demo git:(main) cd ../different_project
➜  different_project git:(main) bd create --global "my first global bead" -p 2
✓ Created issue: global-wqk — my first global bead
  Priority: P2
  Status: open

Notice the different output of bd list with and without the --global flag.

➜  different_project git:(main) bd list
○ different_project-s9i ● P2 my first different project bead

--------------------------------------------------------------------------------
Total: 1 issues (1 open, 0 in progress)

Status: ○ open  ◐ in_progress  ● blocked  ✓ closed  ❄ deferred
➜  different_project git:(main) bd list --global
○ global-wqk ● P2 my first global bead

--------------------------------------------------------------------------------
Total: 1 issues (1 open, 0 in progress)

Status: ○ open  ◐ in_progress  ● blocked  ✓ closed  ❄ deferred

And similarly, if we return to the previous project we see the scoped beads versus the global ones, by using the --global flag.

➜  different_project git:(main) cd ../evolving_demo
➜  evolving_demo git:(main) bd list
No issues found.
➜  evolving_demo git:(main) bd list --global
○ global-wqk ● P2 my first global bead

--------------------------------------------------------------------------------
Total: 1 issues (1 open, 0 in progress)

Status: ○ open  ◐ in_progress  ● blocked  ✓ closed  ❄ deferred

Conclusion#

I hope this helps clarify some common usage patterns for Beads, and we encourage you to give it a try if you haven’t already.

Also, feel free to join both the Gaslandia Discord and the Dolt Discord if you haven’t already. We’d love to chat with you and discuss building for the agentic future.

How TPC-C Works

James Cor — Thu, 14 May 2026 00:00:00 GMT

Dolt is a version-controlled database that works as a drop-in MySQL replacement. In addition to correctness parity with MySQL, we are also determined to reach performance parity with MySQL. For years now, we’ve been improving Dolt performance on both Sysbench and TPC-C benchmarks. Towards the end of 2025, Dolt reached parity with MySQL on Sysbench when averaging reads and writes. Shortly after, we managed to reach MySQL parity on both read and writes. Now, we surpass MySQL on Sysbench reads and writes with a 0.95 reads mean multiplier and 0.87 write mean multiplier.

While we are proud of our accomplishments on Sysbench, TPC-C Benchmarks are arguably more important to the average user experience. This blog will go into detail about the TPC-C benchmarks and the kinds of queries run against the database.

What is TPC-C#

TPC-C stands for Transaction Processing Performance Council Benchmark C. It is the industry standard benchmark used for OLTP databases. TPC-C simulates real-world usage of a database by modeling transactions for a wholesale supplier. Dolt actually uses a slightly modified version of the official TPC-C benchmarks from Percona Labs.

Settings#

We run TPC-C with these settings:

./tpcc.lua \
  --db-driver="mysql" \
  --mysql-db="sbtest" \
  --mysql-host="127.0.0.1" \
  --mysql-port="$PORT" \
  --mysql-user="$USER" \
  --mysql-password="$PASS" \
  --time=800 \
  --report_interval=10 \
  --threads=1 \
  --tables=1 \
  --scale=1 \
  --trx_level="RR" run

The benchmarks are run with a single thread for 800 seconds with autocommit and foreign_key_checks disabled. trx_level="RR" is REPEATABLE_READ (the MySQL/Innodb default), which means that SELECT results are isolated within a transaction. Uncommitted writes to a table from another transaction will not be visible to this transaction. We compare the 95th percentile latency and number of transactions per second (tps) against MySQL.

Tables#

Here is a brief summary of the tables created.

warehouse with 1 row
district with 10 rows
customer with 30000 rows
orders with 30000 rows
new_orders with 9000 rows
order_line with 299293 rows
item with 100000 rows
stock with 100000 rows
history with 30000 rows

Many of these tables have primary keys, secondary keys, and foreign keys (even though foreign_key_checks are disabled).

Transactions#

TPC-C randomly selects between 5 different transaction types with varying odds. Each transaction starts with a BEGIN and ends with COMMIT. Without spelling out every query run within a transaction, here is a high-level overview of each transaction.

trx_type	run_percent
`new_order`	43.48%
`payment`	43.48%
`order_status`	4.35%
`delivery`	4.35%
`payment`	4.35%
TOTAL	≈100.00%

1. `new_order`#

Description: This transaction simulates a customer order of 5 - 15 quantity of an item. The new order is logged in the orders, new_orders, and order_line tables, and the item and stock tables are updated accordingly.

Percent Run: 43.49% (10/23)

# of SQL Statements: 25 - 65

Reads Tables: customer, district, item, stock, warehouse

Writes Tables: district, orders, order_line, new_orders, stock

2. `payment`#

Description: This transaction simulates a customer making a purchase. It reads the customer’s payment details (name, address, etc.) from the customer table, update their account balance, and logs the transaction in the history table.

Percent Run: 43.48% (10/23)

# of SQL Statements: 6 - 10

Reads Tables: customer, district, warehouse

Writes Tables: customer, district, history, warehouse

3. `order_status`#

Description: This transaction simulates a customer inquiring about their order details. It performs a series of SELECT queries into the customer, orders and order_line tables.

Percent Run: 4.34% (1/23)

# of SQL Statements: 3 - 4

Reads Tables: customer, orders, order_line

Writes Tables: NONE

4. `delivery`#

Description: This transaction simulates a customer’s order getting delivered. An order is removed from the new_orders table and the appropriate entries are updated in orders, order_line and customer.

Percent Run: 4.34% (1/23)

# of SQL Statements: 1 - 6

Reads Tables: orders, order_line, new_orders

Writes Tables: customer, orders, order_line, new_orders

5. `stocklevel`#

Description: This transaction simulates a query over existing inventory. It is a few SELECT queries that aggregate over the order_line and stock tables that count the quantity of certain items.

Percent Run: 4.34% (1/23)

# of SQL Statements: 3+

Reads Tables: district, orders, stock, order_line

Writes Tables: NONE

You can explore the TPC-C database in more detail here: https://www.dolthub.com/repositories/jcor/sbtest

Conclusion#

We have been focused on Dolt performance on TPC-C, which aims to simulate a real user experience with an OLTP database. Over the last few months we have made substantial improvements to TPC-C. Stay tuned for a future blog describing how we’ve broken the 2x MySQL multiplier on TPC-C. Have any performance issues? Cut a bug on our GitHub issues page. Want to talk to anyone on our team? Join our Discord.

DoltHub Blog - Latest Posts

Doltgres 1.0

What does 1.0 mean?#

Forward Storage Compatibility#

Production Performance#

Postgres Compatibility#

Stable Version Control Interface#

What’s next?#

Conclusion#

No Index GroupBy Optimization

Discovering the Optimization#

Optimization#

Conclusion#

Running Ito, a Runtime Analysis Code Review Tool, on Doltgres

What is Ito?#

Turning Ito On#

Ito in Action#

Bug: Named window reference OVER w produces a full-partition SUM instead of a running SUM within each partition#

setup context#

setup_keys: default-superuser#

timestamp: 2026-07-13T20:11:56.578Z test execution for named window OVER w#

reproduction script#

observed output#

inline baseline output#

tab/readback evidence#

test_start: Executed named window OVER w query against t_named#

test_start result: Returned id=1 s=30, id=2 s=30, id=3 s=5 - PARTITION BY grp works but ORDER BY id is ignored#

test_end result: Failed - named window ORDER BY id is not applied#

final result#

final result: PARSING-1 failed - named window reference OVER w returns full-partition SUM for grp=1 row id=1 (30) instead of running value (10).#

Bug: Inheriting or overriding a named window’s ORDER BY drops it#

setup and reproduction SQL#

observed output#

Test 1: Named window inheritance chain w1 -> w2#

Test 2: Named window with override clause#

Test 3: Inline window baseline (correct expected behavior)#

additional mixed-form readback from run#

final result: PARSING-3 failed - named-window inheritance/reference forms return full-partition sums while equivalent inline OVER (PARTITION BY grp ORDER BY id) returns running sums.#

Not Just for SQL#

Ito Improvements#

By the Numbers#

Summary#

Dolt in Four Flavors

Why All the Flavors?#

Which Flavor Is Right for You?#

The Dolt Ecosystem#

Conclusion#

Dolt + TeamCity: Data Commits Now Trigger Builds

What Is TeamCity?#

TeamCity and Dolt, Before#

Look, a Cool New Plugin!#

The Query Behind the Changes Tab#

Setup#

A Data Commit Walks Into a Build#

Watch a Test Turn Red#

Two Builds, Two Games, One Commit Apart#

The Fine Print#

Conclusion#

Doltgres Reaches 99% Compliance on SQL Logic Tests

SQL Logic Test#

Establishing a Baseline Against PostgreSQL#

Bugs the Tests Found in Doltgres#

On Track for August 6th#

Doltgres 1.0 Coming August 6th

What Does 1.0 Mean?#

Correctness#

Storage Stability#

Performance#

Compatibility#

Other Features#

Try Doltgres and Send Us Issues#

What People Are Saying: LWN Edition

Project Architecture#

The Power of Git#

How Git and Dolt Store Snapshots#

Dolt’s Dynamic Node Size Thresholds#

That’s All, Folks#

Footnotes#

Git For Context

Context#

Bug: Named window reference `OVER w` produces a full-partition SUM instead of a running SUM within each partition#

Bug: Inheriting or overriding a named window’s `ORDER BY` drops it#

1. `new_order`#

2. `payment`#

3. `order_status`#

4. `delivery`#

5. `stocklevel`#