DoltHub Blog - Latest Posts

Home and Pricing Page Redesign

Tim Sehn — Tue, 15 Sep 2026 00:00:00 GMT

Dolt now comes in four flavors: Dolt, Doltgres, DoltLite and Dumbo. Our redesigned homepage and pricing page reflect that expanded lineup. This article walks through the new designs and highlights some of the messages we’re trying to emphasize.

Homepage#

DoltHub started as a data sharing company. We still think DoltHub is great for sharing data but our customers mostly want to run our databases in production instead. Our fastest-growing use case is serving as the backing store for systems where agents make writes. Our new homepage reflects that.

A few things to note about this design: the image of agents hanging out on the branches of a tree growing from a database-shaped pot is not new. But it’s one of my favorite images our designers have ever made. It stays. We also wanted to make sure people knew from the start that we are the version-controlled database company and that our databases are perfect for agents. The new above-the-fold language reflects this.

AGENTS NEED VERSION CONTROL
We Build Databases for Agents
The only databases with version control

We also wanted to highlight our three non-alpha databases above the fold: Dolt, Doltgres, and DoltLite. Dumbo will be included once it sheds the alpha tag.

When we only had Dolt, most new folks visiting the homepage would assume Dolt was a MySQL add-on. Now that Dolt comes in four flavors, it’s clearer from the start that our databases are built from the ground up on novel storage to provide Git-style features. The messaging no longer centers on MySQL.

Clicking on a database in the first section takes you to a card explaining what that database is and when to use it. These cards are my favorite part of the homepage. I think they are the best distillation of what makes each Dolt flavor special.

Also, while you’re down there, throw my baby DoltLite a star. It’s getting mogged by Dolt and Doltgres.

Pricing#

We applied lessons from designing the database cards to the new pricing page.

All of our databases are free and open source. We wanted to make that clear from the pricing page.

We make money in two ways:

Enterprise Support
Services

The pricing page explains our services and links to our Enterprise Support page. I have a few ideas about how we could make paid support a clearer option so come back and refresh the pricing page every once in a while if you are curious.

Conclusion#

How do you like the new homepage and pricing page? Did we accomplish our design goals? Come by our Discord and give us your feedback.

Postgres follows the SQL standard for UPDATE statements, unlike MySQL

Zach Musgrave — Fri, 11 Sep 2026 00:00:00 GMT

Doltgres, the world’s first version-controlled Postgres-compatible database, just hit 1.0, meaning that it’s ready for production use. We want Doltgres to be a drop-in replacement for Postgres so that customers can use the entire ecosystem of Postgres-compatible tools and libraries, or port their existing database application to Doltgres without changing any code. This means getting all the nuanced semantics of Postgres’s behavior correct in our emulation. And we think we’ve done pretty well here — our compatibility tests encompass over two dozen tools and languages.

But Doltgres shares the same SQL engine Dolt uses, which was built to emulate MySQL semantics. For most queries this works fine, but MySQL plays famously fast and loose with the SQL standard, while Postgres takes it much more seriously. And because we take client compatibility very, very seriously, that means that we need an engine that reproduces all of MySQL’s wacky non-standard behavior for Dolt and Postgres’s dignified, correct behavior for Doltgres.

Today’s blog is a case study of one area where the engine’s behavior differs to match the emulation target, and a look under the hood for how we manage these differences internally in our interfaces.

UPDATE with column values from the same row#

This issue was brought to our attention by an early adopter customer: Doltgres had the wrong behavior when an UPDATE statement referenced table columns in its update expressions.

CREATE TABLE t_seq (a int, b int);
INSERT INTO t_seq VALUES (1, 0);
UPDATE t_seq SET a = 2, b = CASE WHEN a = 1 THEN 100 ELSE -1 END;
SELECT a, b FROM t_seq;

The SQL standard says that an UPDATE statement that references column values should use the value from the pre-update row, in all cases. So the SELECT query in the above block should return this:

 a |  b
---+-----
 2 | 100    -- per the SQL standard, every assignment reads the pre-update row

But MySQL doesn’t behave this way for an UPDATE. It ignores the SQL standard and uses the new, updated column values in every UPDATE expression as it executes them one by one, left to right, on each row. So in MySQL, and Dolt, the above select returns this:

 a |  b
---+-----
 2 |  -1    -- the CASE saw the NEW value of a (=2)

And until earlier this week, Doltgres behaved this way too. But that’s wrong, and breaks client expectations for Postgres application developers. We needed to change this behavior in the engine, but only when running in Postgres emulation mode.

How do we do that?

Introducing engine overrides#

During development of Doltgres, we experimented with a lot of different mechanisms to vary the engine’s behavior for Doltgres, either to reflect needed differences for Postgres compatibility or to implement features that MySQL doesn’t have. These include new rules during query analysis, new plan nodes that wrap or otherwise alter existing ones, as well as more hacky fixes like swapping function pointers during program init. For something like this divergence in behavior, there wasn’t an existing extension point in the query engine. We designed the engine to make the database backend swappable, as well as some of the query planning logic. But for something as fundamental as applying updates to a row, we had not bothered to make the behavior pluggable.

Our current approach in this kind of situation is to provide the engine with a set of well-defined behavioral extension points at construction. Unlike the interfaces that define tables, databases, functions, etc. that allow integrators to implement a custom database storage backend, these extension points alter the query-time behavior of the engine itself, independent of the storage backend. They’re currently stored in a struct called EngineOverrides. To solve this particular problem, we introduced the new UpdateExpressionApplier interface at the bottom of the struct.

type EngineOverrides struct {
	// Builder contains functions and variables that can replace, supplement, or override functionality within the builder.
	Builder BuilderOverrides
	// SchemaFormatter is the formatter for schema string creation. If nil, this will format in MySQL's style.
	SchemaFormatter SchemaFormatter
	// Hooks contain various hooks that are called within a statement's lifecycle.
	Hooks ExecutionHooks
	// CostedIndexScanExpressionFilter is used to walk expression trees in order to apply index scans based on
	// filter expressions. Some expressions may need to be modified or skipped in order to properly apply indexes
	// for all integrators.
	CostedIndexScanExpressionFilter ExpressionTreeFilter
	// UpdateExpressionApplier evaluates UPDATE assignments. If nil, the engine uses
	// MySQL's sequential assignment evaluation and IGNORE conversion handling.
	UpdateExpressionApplier UpdateExpressionApplier
}

The new interface looks like this:

// UpdateExpressionApplier evaluates the assignments for a row in an UPDATE statement.
// It does not apply to procedural SET or INSERT ON DUPLICATE KEY UPDATE statements.
type UpdateExpressionApplier interface {
	ApplyRowUpdate(ctx *Context, updateExprs *UpdateExprs, tableSchema Schema, oldRow Row, ignore bool) (Row, error)
}

For MySQL behavior, we have a simple interface that applies updates the same way it always has (matching MySQL, not Postgres). For Doltgres, we implemented a new one that we plug in at engine construction time.

func (UpdateExpressionApplier) ApplyRowUpdate(ctx *sql.Context, updateExprs *sql.UpdateExprs, tableSchema sql.Schema, oldRow sql.Row, _ bool) (sql.Row, error) {
	newRow := oldRow.Copy()
	for _, expr := range updateExprs.ExplicitUpdateExprs() {
		assignment, ok := expr.(*gmsexpression.SetField)
		if !ok {
			return nil, fmt.Errorf("UPDATE: expected SetField, found %T", expr)
		}
		// SetField performs assignment conversion and returns a copy of oldRow.
		// Merge only its target, so later assignments cannot undo earlier writes.
		value, err := assignment.Eval(ctx, oldRow)
		if err != nil {
			return nil, err
		}
		...
}

Now Doltgres returns the expected result, the same as Postgres.

a |  b
---+-----
2 | 100    -- per the SQL standard, every assignment reads the pre-update row

Check out these two PRs for the full details.

Conclusion#

Doltgres 1.0 already launched, but Doltgres’s compatibility story is definitely not over. Keep the issues coming and we’ll keep knocking them down in 24 hours.

Have a divergence in Postgres behavior to report? Want to learn more about Doltgres? Visit us on the DoltHub Discord where our engineering team hangs out all day. Hope to see you there.

Implementing Type Contracts via Mutually Referencing Type Parameters

Nick Tobey — Fri, 28 Aug 2026 00:00:00 GMT

I work for Dolt, the world’s first version-controlled database. We made Dolt as a drop-in replacement for MySQL, since MySQL was the most commonly used SQL database in production when we started. But new teams by-and-large are not choosing MySQL; they’re using Postgres. So we also made Doltgres, a alternate version of Dolt that speaks the Postgres dialect.

Unsurprisingly, Dolt and Doltgres share a lot of common code. But there’s also subtle differences between MySQL and Postgres’s feature set. We want to use shared code for things that the projects have in common, and interfaces to implement behavior where they differ.

One of our big features is Git-style branches. A client session operates on a currently checked-out branch, and is completely independent of the other branches in the database. Except when I say “completely independent”, I actually mean “mostly independent.” When we made Dolt, we decided that there was one specific situation where we wanted branches to not be independent: auto incrementing columns.

In MySQL, if a table has a column declared with the AUTO_INCREMENT modifier, inserts aren’t required to specify a value for that column. Instead, a new value will be generated that is guaranteed to not conflict with any values currently in the table. This is true even when multiple sessions are making transactions concurrently, which each transaction getting a different value for the column. While transactions are typically independent from each other, MySQL makes an exception here so that the transactions won’t conflict if both are committed.

We decided that it made sense to apply that same behavior to branches: if sessions on two different branches are inserting into the same table with an auto increment column, Dolt is guaranteed to generate non-conflicting values for that column. If we didn’t do this, then any attempt to merge those branches would result in a merge conflict.

In contrast, Postgres doesn’t have AUTO INCREMENT. Instead, it has SERIAL columns, which behave similarly but have some key differences:

In MySQL, AUTO INCREMENT values are always unsigned, while in Postgres, SERIAL values are always signed.
SERIAL columns are backed by a data type called a Sequence, which has configuration parameters such as the min and max values, whether the generated values are incremented or decremented, whether they wrap around when they reach the end, etc.

Synchronizing the behavior across all branches and all transactions has a lot of tricky corner cases, that we’d already gotten right with AUTO INCREMENT, and duplicating that logic would be a bad idea. So we designed a data model that could handle both:

A Sequence is an item in the database capable of producing a sequence of values, such as a MySQL table with an AUTO INCREMENT column, or a Postgres sequence.
A SequenceValue is a value produced by a sequence.
A SequenceState is a type that represents the current state of a Sequence and can be incremented to produce new SequenceValues.

Using these definitions, we were able to implement all of the behavior common to both MySQL tables and Postgres sequences as generic methods on these types.

This reminded me of a similar situation I encountered two years ago, involving pairs of data structures each consisting of a mutable type and an immutable type that could be converted between each other. The goal was to write something like the below, that could be used with any pair of types that satisfied this contract:

func ApplyMutations(immutable ImmutableValue, mutations []Mutation) ImmutableValue {
  mutableValue := immutable.Mutate()
  mutableValue.ApplyMutations(mutations)
  return mutableValue.Flush()
}

I wrote a blog post talking about my solution to that problem, how I’d used a Golang generic interface to model a situation where a group of types collectively implement some contract. But there’s a lot in that I got flat-out wrong about how go Golang generics worked, and I got rightfully chewed out for it in the responses to the extent that I’m a bit embarrassed to bring it up again.¹

This time, I was determined to make a better solution. This is a real problem, and it’s worth understanding the correct way to tackle it in Go because it’s a useful design pattern for writing type-safe code.

The Problem#

In Go, if you want a function to operate on multiple different types, you can define an interface. An interface is a contract: it specifies a set of constraints that the implementing type must satisfy, usually methods that the type must implement. Any type that implements these methods will satisfy the interface. But this interface only constrains a single type. Sometimes, you have a group of types that need to implement a contract together. How can we use Go’s language features to solve this problem?

What Doesn’t Work: Interfaces#

If we were to express the above-mentioned Sequence data model as interfaces, it might look something like this:

type SequenceValue interface {
    int64 | uint64
}

type SequenceState interface {
    CurrentValue() SequenceValue
    Advance() (nextValue SequenceValue, nextState SequenceState)
}

type Sequence interface {
    CurrentState() SequenceState
    UpdateFromGlobalState(SequenceState) Sequence
}

But making these types regular interfaces is a bad idea for several reasons:

There’s a performance penalty for calling interface methods due to dynamic dispatch.
All values of an interface type are boxed and their underlying values are stored on the heap.
Go doesn’t actually allow interfaces with shape constraints (like SequenceValue above) to be used in method signatures.

But the biggest problem is that this fails to give us the compile-time type safety we want. It doesn’t document or enforce that a particular SequenceState implementation is always expected to have a specific type for SequenceValue. We could need to insert check-casts every time one of these methods is called. If we ever call a method with the wrong implementation, we would panic at runtime.

This isn’t a good use of interfaces, because we’re paying a cost in performance and code complexity but not getting anything out of it.

The Bad Idea: A Single Generic Interface#

This was the concept in my previous attempt that rightly got a lot of pushback.

The basic idea was that if interfaces are how you achieve polymorphism in Go, and an interface is defined by a set of behaviors on a single type, then you can achieve a contract on multiplace types by implementing an interface that accepts each of those types as a generic type parameter.

So in this case, you would have a “contract” type that defines all the necessary behavior, and generic code must call methods on this contract type:

type SequenceContract[SequenceValue any, SequenceState any, Sequence any] interface {
    SequenceState_CurrentValue(SequenceState) SequenceValue
    SequenceState_Advance(SequenceState) (nextValue SequenceValue, nextState SequenceState)
    Sequence_CurrentState(Sequence) SequenceState
    Sequence_UpdateFromGlobalState(Sequence, SequenceState) Sequence
}

The main downside of this is that it’s ugly. Shared code can’t call methods on the component types because they all have an any type constraint. Instead it must call the methods on SequenceContract, which will likely just delegate to the corresponding methods on the component types.

This approach also requires that shared code takes a SequenceContract value as an extra parameter. This also requires the shared code to be itself generic, which means that prior to Go 1.27 it couldn’t be a method and had to be a function.

There are some possible upsides to this approach: implementations of the contract type are allowed to have state, and it’s possible to define multiple contracts on the same collection of types. But these “upsides” are a double-edged sword, because now you’re adding further complexity to your data model. This is rarely the best approach.

Almost A Solution: Generic Interfaces#

We could attempt to capture the relationship between types via generic interfaces. Going back to original example with the corresponding mutable and immutable types, we could attempt to write interfaces like so:

type ImmutableValue[T ...] interface {
  Mutate() T
}
  
type MutableValue[T ...] interface {
  ApplyMutations([]Mutation)
  Flush() T
}

But what do we put in place of ”…” in the example above?

We can’t have the two interfaces reference each other (that is, we can’t write type ImmutableValue[T MutableValue]) because MutableValue isn’t a complete type. And even if we could somehow do that, prior to Go 1.26 we weren’t allowed to have both ImmutableValue and MutableValue reference each other in their type constraints.

One option is to just use any:

type ImmutableValue[T any] interface {
  Mutate() T
}
  
type MutableValue[T any] interface {
  ApplyMutations([]Mutation)
  Flush() T
}

But this alone isn’t enough to let us write a function like ApplyMutations above: if the return type of Mutate() is constrained by any, then we can’t call any methods on it.

As we’ll soon see, Go 1.26 added Recursive Type Parameters, which actually gives us something that we can put here. But as we’ll also see, putting a strict type constraint here isn’t actually necessary, and doesn’t actually change what the correct solution looks like.

The Correct Idea: Mutually Referential Type Parameters#

This is a technique originally described in the original Go type parameters proposal.

The idea is to let go of the idea that every part of your data model needs to be described with interfaces. What actually matters is your functions and structs, which describe the data that they accept. An interface is powerful because it allows you to name a set of constraints and reuse them. It’s a useful tool for deduplicating constraint defitions and for composing them, but they’re a means to an end.

So building on the previous example, we can use any type constraints in the interface definitions, and then further constraint them when these interfaces are actually used:

type ImmutableValue[T any] interface {
  Mutate() T
}
  
type MutableValue[T any] interface {
  ApplyMutations([]Mutation)
  Flush() T
}

func ApplyMutations[
    ImmutableType ImmutableValue[MutableType],
    MutableType MutableValue[ImmutableType],
](
    immutable ImmutableValue,
    mutations []Mutation,
) ImmutableValue {
  mutableValue := immutable.Mutate()
  mutableValue.ApplyMutations(mutations)
  return mutableValue.Flush()
}

And for the case of the Sequence type, which must be able to return itself, it can take a self-referential type constraint. These interfaces are then used in creating the full set of type constraints for a struct, which contains our actual business logic as methods:

type SequenceState[Self any, ValueType any] interface {
    CurrentValue() ValueType
    Advance() (nextValue ValueType, nextState Self)
}

type Sequence[Self any, StateType any, ValueType any] interface {
    CurrentState() StateType
    UpdateFromGlobalState(StateType) Self
}

type SequenceTracker[
    ValueType any,
    StateType SequenceState[StateType, ValueType],
    SequenceType Sequence[SequenceType, StateType, ValueType]
] struct {
    ...
}

Note that even though the interface defintions don’t enforce any requirements for their type parameters, the code is still fully type-safe because the types are fully constrained where they’re actually used.

The one downside is that the function and struct defintions themselves can become quite verbose. And every function that accepts these types must duplicate the type constrainted. The interface definitions can reduce the verbosity but don’t eliminate it. Fortunately, all these types can be inferred at the callsite, so the callsite remains clean.

Go 1.26 allows us to further constrain the interface definitions by allowing the type constraints to reference the interface type being defined:

type SequenceState[
    Self SequenceState[Self, ValueType],
    ValueType any
] interface {
    CurrentValue() ValueType
    Advance() (nextValue ValueType, nextState Self)
}

type Sequence[
    Self Sequence[Self, StateType, ValueType],
    StateType SequenceState[Self, ValueType],
    ValueType any,
] interface {
    CurrentState() StateType
    UpdateFromGlobalState(StateType) Self
}

However, this does not reduce any type constraints in the functions and structs that use these interfaces. In my experience the main benefit of this is to make the types more self-documenting, not to provide additional type safety.

Everything example I’ve shown except for the last one has existed since Go 1.18, when type parameters were first added. So why didn’t I identify the proper solution previously?

There were two facets that I think blindsided me: the use of any within type constraints, and the ambiguous documentation around self-referential type constraints.

`any` Type Constraints#

It’s generally discouraged to use any as a parameter type, and recommended to use the most specific type possible in interfaces and APIs. Given that advice, I had attempted to avoid using any as a type constraint outside of situations where it was explicitly expected to support any type. Then, because it wasn’t possible to fully express these constraints within interface definitions prior to 1.26, I concluded that it wasn’t possible to write valid interface definitions for this situation.

But in fact, it’s perfectly fine to use any as a type constraint, and it doesn’t mean that the code you write will have to accept any as a variable type.

Think of a generic type for a data structure:

type MinHeap[T any] interface { ... }

This doesn’t imply that you’re actually going to specialize it with any. It’s just a constraint. Don’t be afraid of any in type constraints.

Ambiguity in documentation#

The original proposal for type parameters describes the above pattern as “mutually referencing type parameters”. And indeed, the only examples provided are cases where two type parameters reference each other. There are no examples of type parameters that reference themselves.

When I initially attempting to write a type constraint for the ImmutableValue interface above, I attempted to write the version with the recursive type constraints, which would not be supported until 1.26. When this was rejected, I incorrectly assumed that it was the self-referential nature of the type constraint that made it not allowed. In fact, it has always been allowed for a type constraint to reference its own type parameter.

Conclusion#

Go isn’t like other languages, and its worth learning its idioms and coding patterns. I still have my gripes: I don’t like how verbose this approach is, how it contains duplicate type constraints at every generic function that needs to operate on the defined types. But adopting the recommended coding styles has also helped to expand how I think about generic code in Go.

As always, if you have thoughts or if you want to tell me how wrong I am, feel free to join our Discord and shoot me a message.

But you can still read it here, if you like. ↩

Introducing the Hosted Dolt REST API

Taylor Bantle — Thu, 20 Aug 2026 00:00:00 GMT

Hosted Dolt is for running online, production Dolt and Doltgres databases. You choose the server and disk you need, and we provision the resources and run the database for you, complete with logging, metrics, backups, and upgrades.

Up until now, the only way to create or manage one of those deployments was from the web UI. Today I’m happy to announce that Hosted Dolt has an official REST API. It’s live at https://hosted.doltdb.com/api/v1/, and it’s documented at dolthub.com/docs/products/hosted/api/v1.

If you’ve used the DoltHub API v2 we released last month, this one will look familiar because it’s purposely built on the same contract.

Motivation#

Hosted Dolt has had two programmatic surfaces for a while. Both are good at what they were designed for, but neither was designed specifically for managing deployments.

The first is your deployment’s SQL endpoint. That’s a live Dolt or Doltgres server, so anything Dolt can do, you can do over a normal MySQL or Postgres connection, including branches, merges, diffs, and the rest of the version control system tables and procedures. This is limited to the data within your database and can not be used to provision or manage the deployment itself.

The second is the GraphQL API behind the Hosted website. A little over a year ago we wrote a blog called “Hosted Dolt’s Hidden GraphQL API”, which walked through pulling the hostedToken cookie out of your browser dev tools and hand-writing GraphQL queries against it. That post opened with a warning that it wasn’t an official API and could change at any time. People used it anyway because it was the only programmatic option for managing deployments.

Creating and managing deployments and instances will always be available from the web UI. But we believe Dolt is the database for agents, and in the age of agents it because increasingly important to provide an API an agent can use. Branching and diffing let an agent work in isolation and have changes audited before they merge, and you’ve been able to connect an agent to a Hosted deployment over MCP since February. Giving it a documented REST API with real status codes and a stable error model means it can provision the database it works in too, so the whole loop, from creating a deployment to querying it to shutting it down when it’s done, is something an agent can run end to end.

Built on the DoltHub API v2#

When we built the DoltHub API v2, the goal was a contract-first API where an OpenAPI 3.1 spec is the source of truth and everything else is generated from it: the published docs, the TypeScript types, the runtime request validation, and the contract tests. Adding an endpoint means editing the spec first, and anything that doesn’t match the spec doesn’t build.

That worked well enough that we reused the whole thing for Hosted. openapi/v1.yaml is the contract, the generated types are checked in and verified against the spec in CI, request bodies are validated at runtime against the spec’s schemas, and a breaking change check runs on every pull request. Both specs are even gated by the same CI workflow, one matrix entry each, so the two APIs can’t drift in how we detect breakage.

More importantly, the parts you actually touch as a caller are the same:

One success envelope. Every 2xx body is { "data": ..., "meta": ... }. data is the resource or the array of resources, and meta is optional.
One error model. Every non-2xx response is an RFC 9457 problem document, with a stable code in SCREAMING_SNAKE_CASE that you can branch on instead of parsing English.
Cursor pagination. Where a list paginates, the response has a meta.next_page_token that you pass back as page_token.
Bearer auth. Authorization: Bearer <token>, 401 if the credential is missing or bad, 403 if it’s valid but not allowed.
snake_case everywhere, and an x-request-id on every response, including successful ones.

There’s one deliberate difference. On DoltHub, endpoints are public unless they opt in to auth, because public database reads are its baseline. On Hosted, every endpoint requires a token and has to opt out. Hosted’s control plane has nothing that’s anonymously readable, so we flipped the default.

What it covers#

There are eleven endpoints today, and they cover your deployments, the instances behind them, their backups and configuration, and the options you can create them with.

Endpoint	What it does
`GET /api/v1/user`	The authenticated user’s profile
`GET /api/v1/deployment-options`	The zones, instance types, and storage a deployment can be created with
`POST /api/v1/deployments`	Create a deployment
`GET /api/v1/deployments/{owner}`	List an owner’s deployments
`GET /api/v1/deployments/{owner}/{deployment}`	Get a deployment
`POST /api/v1/deployments/{owner}/{deployment}/disable`	Disable a deployment
`GET /api/v1/deployments/{owner}/{deployment}/instances`	List the instances behind a deployment
`POST /api/v1/deployments/{owner}/{deployment}/instances`	Add a read replica
`DELETE /api/v1/deployments/{owner}/{deployment}/instances/{id}`	Remove an instance
`GET /api/v1/deployments/{owner}/{deployment}/backups`	List a deployment’s backups
`GET /api/v1/deployments/{owner}/{deployment}/config`	Get a deployment’s database configuration

This API is the deployment control plane only. Querying the data inside a deployment isn’t part of this API and won’t be. Your deployment already exposes a SQL endpoint you connect to directly with your own database credentials, and that’s a much better interface for queries than anything we’d put over HTTP. For the same reason, your database credentials are deliberately not part of the deployment resource, so reading a deployment never hands out a credential.

Getting a token#

First you’ll need a token. Create one from the Tokens section of your user settings. Hosted API tokens are prefixed hsat.v1., they carry the same permissions as the user who created them, and they expire on a date you pick.

export HOSTED_TOKEN=hsat.v1.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

The quickest way to check it works is GET /api/v1/user. A 200 tells you the token is good and whose access it carries.

curl -s 'https://hosted.doltdb.com/api/v1/user' \
  -H "Authorization: Bearer $HOSTED_TOKEN"

{
  "data": {
    "username": "acme-ops",
    "display_name": "Acme Operations",
    "company": "Acme Corp",
    "email_addresses": [
      { "address": "ops@acme.com", "is_verified": true, "is_primary": true }
    ]
  }
}

Creating a deployment#

1. See what you can create#

GET /api/v1/deployment-options tells you the options you can use to create a deployment or instance. It narrows in steps, since each choice depends on the one before it. Pass cloud on its own to get its zones, add zone to also get that zone’s instance types, and add instance_type_id to also get the storage that works with that instance. Anything you haven’t narrowed enough to determine is left out rather than returned empty.

curl -s -G 'https://hosted.doltdb.com/api/v1/deployment-options' \
  -H "Authorization: Bearer $HOSTED_TOKEN" \
  -d cloud=aws \
  -d zone=us-east-1 \
  -d instance_type_id=aws.t2.medium

{
  "data": {
    "cloud": "aws",
    "zones": ["us-east-1"],
    "instance_types": [
      {
        "id": "aws.t2.medium",
        "name": "t2.medium",
        "cpus": 2,
        "memory_gb": 4,
        "description": "Trial tier, the lowest spec that runs a Dolt SQL server.",
        "hourly_cost_usd": 0.06849315
      }
    ],
    "storage_options": [
      {
        "id": "aws.ebs.gp3_50",
        "name": "Trial 50GB EBS",
        "description": "Trial tier storage capped at 50GB",
        "min_size_gb": 50,
        "max_size_gb": 50,
        "monthly_cost_usd_per_gb": 0
      }
    ]
  }
}

Note that you will need the id, not the name, for the create deployment endpoint.

2. Create it#

curl -s -X POST 'https://hosted.doltdb.com/api/v1/deployments' \
  -H 'Content-Type: application/json' \
  -H "Authorization: Bearer $HOSTED_TOKEN" \
  -d '{
    "owner": "acme",
    "name": "analytics",
    "cloud": "aws",
    "zone": "us-east-1",
    "instance_type_id": "aws.t2.medium",
    "volume_type_id": "aws.ebs.gp3_50",
    "volume_size_gb": 50
  }'

You get back a 202, meaning we’ve accepted the request and provisioning continues after the response. host is empty until the deployment comes up.

{
  "data": {
    "owner": "acme",
    "name": "analytics",
    "state": "starting",
    "cloud": "aws",
    "zone": "us-east-1",
    "cluster_type": "dolt",
    "instance_type_name": "t2.medium",
    "volume_type_name": "Trial 50GB EBS",
    "volume_size_gb": 50,
    "replicas": 0,
    "host": "",
    "port": 3306,
    "caller_role": "admin",
    "created_by": "acme-ops",
    "created_at": "2026-08-11T09:14:00Z"
  }
}

cluster_type defaults to dolt. Pass doltgres if you want a Doltgres deployment, or mysql_with_dolt_replicas for a MySQL primary with Dolt read replicas.

3. Wait for it to start#

The DoltHub API v2 routes its async work through a single Operation resource that you poll. We didn’t need one here, because the deployment is already the thing whose state you care about. So you poll the deployment until state is started.

curl -s 'https://hosted.doltdb.com/api/v1/deployments/acme/analytics' \
  -H "Authorization: Bearer $HOSTED_TOKEN"

{
  "data": {
    "owner": "acme",
    "name": "analytics",
    "state": "started",
    "cloud": "aws",
    "zone": "us-east-1",
    "cluster_type": "dolt",
    "instance_type_name": "t2.medium",
    "volume_type_name": "Trial 50GB EBS",
    "volume_size_gb": 50,
    "replicas": 0,
    "database_version": "1.58.4",
    "host": "analytics.dbs.hosted.doltdb.com",
    "port": 3306,
    "hourly_cost_usd": 0.06849315,
    "webpki_cert": true,
    "expose_remotesapi_endpoint": false,
    "expose_mcp": false,
    "expose_stats": false,
    "disable_automatic_dolt_updates": false,
    "caller_role": "admin",
    "created_by": "acme-ops",
    "created_at": "2026-07-01T18:22:04Z"
  }
}

host and port are your connection details, and from here you’re in normal Dolt territory.

mysql -h analytics.dbs.hosted.doltdb.com -P 3306 -u <user> -p

The same starting to started transition covers restarts and resizes too, so the same poll works for those.

Inspecting a deployment#

GET /api/v1/deployments/{owner} lists deployments for an owner name. It takes an optional state filter and it paginates. The items are a summary rather than the full deployment, so it drops the connection details and adds last backup information.

curl -s -G 'https://hosted.doltdb.com/api/v1/deployments/acme' \
  -H "Authorization: Bearer $HOSTED_TOKEN" \
  -d state=started

{
  "data": [
    {
      "owner": "acme",
      "name": "analytics",
      "state": "started",
      "cloud": "aws",
      "zone": "us-west-2",
      "cluster_type": "dolt",
      "instance_type_name": "m5.large",
      "volume_type_name": "gp3",
      "volume_size_gb": 100,
      "replicas": 0,
      "database_version": "1.58.4",
      "hourly_cost_usd": 0.192,
      "webpki_cert": true,
      "last_backup_time": "2026-08-10T02:00:00Z",
      "last_backup_size_bytes": 1048576
    }
  ],
  "meta": {
    "next_page_token": "eyJvZmZzZXQiOjI1fQ"
  }
}

Pass the next_page_token back as page_token for the next page, and stop when meta isn’t there anymore.

You can list the backups we’re holding for a deployment, newest first:

curl -s 'https://hosted.doltdb.com/api/v1/deployments/acme/analytics/backups' \
  -H "Authorization: Bearer $HOSTED_TOKEN"

{
  "data": [
    {
      "id": "20260812T020000.000",
      "databases": ["analytics", "staging"],
      "instance_index": 0,
      "created_at": "2026-08-12T02:00:00Z"
    },
    {
      "id": "20260811T020000.000",
      "databases": ["analytics", "staging"],
      "size_bytes": 1048576,
      "instance_index": 0,
      "created_at": "2026-08-11T02:00:00Z"
    }
  ]
}

The newest backup there doesn’t have a size_bytes yet. That’s expected, since we measure it asynchronously after the backup is taken, so a recent one has no size for a few minutes.

And you can read a deployment’s database configuration. This returns every setting Hosted supports, at the value the deployment is actually running, which is the same thing the Configuration page in the UI shows you. is_overridden tells you whether you changed it, and default tells you what it would go back to.

curl -s 'https://hosted.doltdb.com/api/v1/deployments/acme/analytics/config' \
  -H "Authorization: Bearer $HOSTED_TOKEN"

{
  "data": {
    "settings": [
      {
        "key": "listener_max_connections",
        "value": "500",
        "default": "100",
        "is_overridden": true
      },
      {
        "key": "behavior_read_only",
        "value": "false",
        "default": "false",
        "is_overridden": false
      }
    ]
  }
}

Values come back as strings exactly as they’re stored, including the numeric and boolean ones.

Disabling a deployment#

POST .../disable tears a deployment’s instances and storage down. You get a 202 with the deployment in stopping, and you poll the deployment until it’s stopped.

curl -s -X POST 'https://hosted.doltdb.com/api/v1/deployments/acme/analytics/disable' \
  -H "Authorization: Bearer $HOSTED_TOKEN"

{
  "data": {
    "owner": "acme",
    "name": "analytics",
    "state": "stopping"
  }
}

Take a backup first if you want the data.

The deployment record itself sticks around. It stays readable with disabled_at and disabled_by set, which is why this is a POST to an action rather than a DELETE on the deployment. To bring it back, add an instance to it, which clears the shutdown and starts it up again. Pass a backup_id from the backups list on that request to restore your data into it, or it’ll come back empty.

Documentation#

The full reference lives at dolthub.com/docs/products/hosted/api/v1. Every endpoint, schema, error code, and security scheme there is rendered straight from the OpenAPI spec, so there’s no drift between what the docs say and what the server does.

If you’d rather generate a typed client in your language of choice, the spec itself is in our docs repo. Grab it and point your generator at it.

Future work#

v1 is additive. We can add endpoints, optional request fields, response fields, and new error codes within v1, and we’d only need a v2 to rename or remove a field or change what an existing one means. So you can build against what’s live today without worrying that the rest of it will move underneath you.

There’s more coming:

Pull requests: creating, viewing, and merging them. Every other version control operation is available over SQL on your deployment, but pull request metadata lives in Hosted’s application database rather than in your Dolt database, so there’s no query that opens or manages one.
Credentials: issuing and rotating a deployment’s database credentials.
Configuration writes: updating deployment settings and Dolt configuration.
Deployment actions: upgrading Dolt/Doltgres, rebooting an instance, and restarting an application.
Access management: adding and removing collaborators and their roles.
CLIs: we’re building a command line tool on top of this API and the DoltHub API v2, along the lines of GitHub’s gh, so you can drive either product from your terminal without writing the HTTP calls yourself.

Conclusion#

Between this and the DoltHub API v2, building against either of our products should feel like working with the same API. If it doesn’t somewhere, that’s a bug and we want to hear about it.

Create a token and try it out. File an issue if there’s an endpoint you want sooner or is not covered above, or come to talk to us on Discord.

What's New With Golang Generics

Nick Tobey — Fri, 14 Aug 2026 00:00:00 GMT

I write Dolt, a version controlled database written 100% in Go. This wasn’t a choice we made so much as a choice that was made for us, since it’s based on noms and built on go-mysql-server, which were both written in Go.

As a result, I use Golang every day, but I’m neither a devoted advocate nor a hater. Go is a tool, and given that we used it to build a drop-in replacement for MySQL that’s faster than MySQL, it does a perfectly decent job.

Go’s design philosophy is that it’s simple by design, and the language is very conservative about adding new features unless those features can be demonstrated to be actually necessary and do more good than harm. It’s a high bar, but a bar than can and has been met in the past. Remember that Go used to not support generics, but support was finally added in 1.18, after it was clear that they were needed.

Since then, Go’s generic support has slowly improved. Features are added when they allow for cleaner and more expressive code, but avoided when it would only lead to messier, harder-to-maintain code. Last year, I ruminated about potential features that Golang might add to generics, debating for each one whether or not it met the bar. I essentially asked for each feature: “Generic code was already hard to read, does adding this allow for even more complicated code? Or do they allow for cleaner ways to express existing ideas?

Cut to two years later, and some of the features I ruminated about have since been more-or-less added to the language. I decided to see how these additions had impacted Dolt, whether we had adopted them and whether they had enabled us to write cleaner code.

Generic Type Aliases (Added in Go 1.24)#

Prior to Go 1.24, the following was invalid:

type Set[T comparable] = map[T]struct{}

While generic type aliases don’t add any expressiveness to the language, they can remove a lot of repetition and clutter. They’re mostly useful when you intend to repeatedly use a specific type for some of a generic’s type parameters, so you partially specialize it once.

I was an advocate for generic type aliases last time, and I’m excited to see that they’re supported now. But they’re also very situational: I searched Dolt’s codebase and found 0 uses. So their use cases are indeed pretty narrow.

That said, now that they’re available, it’s possible they might find a home in Dolt in the future.

Recursive Type Constraints (Added in Go 1.26)#

This was a feature added in Go 1.26, allowing type constraints like the following:

// A Lattice is a type of weakly ordered values with a least value named Bottom, and a unique
// least upper bound for any two value.
type Lattice[T Lattice[T]] interface {
  Less(other T) bool
  LeastUpperBound(other T) T
  Bottom() T
}

func WeakTopologicalOrder[T Lattice[T]](elems []T) seq.Iter { ... }

var _ Lattice[LatticeImpl] = LatticeImpl{}

This lets us use method chaining in functions that operate on this type:

func NAryLeastUpperBound[T Lattice[T]](elems T[]) T {
  var result T
  result = result.Bottom()
  for _, l := range elems {
    result = result.LeastUpperBound(l)
  }
  return result
}

In other languages, using a type parameter in its own type constraint is called a curiously recurring template pattern. It has some additional uses in languages that allow template metaprogramming, but the main value in Golang is to define an interface for types with methods that accept or return the same time being implemented.

This strongly resembles the “self-type constraint” feature from my previous article, with the caveat that it’s technically possible to provide a different type for the type parameter from the type that’s implementing the interface. For instance, You could have LatticeImpl implement Lattice[SomeUnrelatedLatticeImpl], although you probably shouldn’t.

This looks really cool… but it’s not actually accomplishing as much as you might think. Prior to Go 1.26, the above interface definition wouldn’t be allowed, but we could write one that looks like this instead:

type Lattice[T any] interface {
  Less(other T) bool
  LeastUpperBound(other T) T
  Bottom() T
}

And our generic function above would still be just as correct. The main benefit of the recursive type constraint is that it more clearly documents intent. It’s more obvious at a glance that the generic interface is meant to be specialized with the same type that’s implementing it, and it rejects attempts to specialize it with a type that’s completely unrelated.

There’s no code in Dolt that uses this feature, but there’s some code that could be updated to use it, such as the SequencedRelation generic interface. This in an interface type that represents database objects that produce an incrementing sequence of values, such as MySQL’s AUTO_INCREMENT columns. Implementations of this interface have a method that take a state for sequence’s state machine and return a new database object whose state is set to the provided value. Since this is a type that can return itself, it has a self-referential type parameter named Self:

// an abridged version of the SequencedRelation generic interface
type SequencedRelation[Self any, StateType any] interface {
	// GetSequenceState returns the current SequenceState of the object.
	GetSequenceState(ctx context.Context) (StateType, error)
	// HasSequenceState returns whether the relation wraps a sequence.
	// (This may be false, for instance, for tables that do not have an AUTO INCREMENT column)
	HasSequenceState(ctx context.Context) (bool, error)
	// SetSequenceState unconditionally sets the SequenceState for the object.
	SetSequenceState(ctx context.Context, val StateType) (Self, error)
}

Note how the type of this constraint is any. With Go 1.26, we could use a more specific type for this constraint:

// This version is more self-documenting:
// It's more clear what the type parameter is for and harder to misuse.
type SequencedRelation[Self SequencedRelation[Self, StateType], StateType any] interface {
	// GetSequenceState returns the current SequenceState of the object.
	GetSequenceState(ctx context.Context) (StateType, error)
	// HasSequenceState returns whether the relation wraps a sequence.
	// (This may be false, for instance, for tables that do not have an AUTO INCREMENT column)
	HasSequenceState(ctx context.Context) (bool, error)
	// SetSequenceState unconditionally sets the SequenceState for the object.
	SetSequenceState(ctx context.Context, val StateType) (Self, error)
}

Generic Methods (Added in Go 1.27)#

Prior to Go 1.27, while function definitions could take generic type parameters, methods could not. This was because Go is a structurally typed language: the set of methods implemented by a type determines what interfaces it implements. If a type defines generic methods, it becomes difficult for the compiler to reason about which interfaces it implements, and even more for the compiler to determine which of the infinite number of possible specializations of the method will be needed at runtime.

This meant that it wasn’t possible to write generic methods, even if the method wasn’t intended to be part of an interface. For instance, if you have a function that’s tightly coupled with a type, you might want to make that function a method to have it exist in the function’s namespace. But if that function was generic, you couldn’t do that.

type Tree[T any] struct {
  node T
  children []Tree[T]
}

// Prior to Go 1.27, this was not allowed
func (t Tree[T]) Map[U any](f func(T) U) {
  result := Tree[U] { node: f(t.node)}
  for _, child := range children {
    result.children = append(result.children, f(child))
  }
}

Instead, you would have needed to write the almost-identical function below:

func MapTree[T any, U any](input Tree[T]) Tree[U] {
  result := Tree[U] { node: f(t.node)}
  for _, child := range children {
    result.children = append(result.children, f(child))
  }
}

With Go 1.27, types will finally be able to implement generic methods, with the condition that these methods do not participate in satisfying interface constraints. These methods won’t change the set of interfaces that the type implements but can still be used to add functions to the namespace of the type.

We have functions like the above in Dolt. But none of them have been migrated to use generic methods yet, because Go 1.27 isn’t out yet. But when it releases later this month, I’ll expect we’ll find ourselves writing generic methods when it is natural to do so.

Overall Impact#

Currently, Dolt doesn’t use any of the above features, although that likely won’t be true for long. I’ve already identified places where we could incorporate recursive type constraints for a little bit of extra type strictness, and we’ll definitely be writing generic methods once we’re able to. It’s possible that there are places that would benefit from generic type aliases, and we just haven’t identified them or done the necessary refactors yet.

So while none of these features have made an impact on Dolt, although I’m still glad they all exist.

Next time we’ll dive more into how Dolt expresses relationships between generic types in a clean, readable way. In the meantime, I know you all have strong opinions about Golang. Feel free to join our Discord and tell me all the ways I’m wrong about the language.

Doltgres is as Fast as MySQL is Slow

James Cor — Thu, 13 Aug 2026 00:00:00 GMT

It’s official! Doltgres v1.0 is here! Alongside various features and correctness improvements, this release comes with some large performance gains. Over the course of a few months, we’ve managed to reduce Doltgres from 4.4x to 2.6x Postgres on sysbench, which is a 1.8x improvement! Fun fact, MySQL’s average multiplier when compared against Postgres on these same benchmarks is also 2.6x. This means that Doltgres is as fast as MySQL is slow.

Overview#

There were a wide variety of optimizations over various parts of the codebase, including improvements to wire format serialization, collections, query analysis, and index costing. In summary, here are the latency numbers from Doltgres v0.56.3 to v1.0.0 compared against Postgres 15.5:

benchmark	doltgres v0.56.3	doltgres v1.0.0	postgres
covering_index_scan	6.55	2.48	18.28
groupby_scan	155.80	74.46	40.37
index_join	6.67	2.22	1.82
index_join_scan	6.21	1.61	0.69
index_scan	1235.62	484.44	183.21
oltp_point_select	0.55	0.37	0.15
oltp_read_only	11.45	6.55	2.66
select_random_points	0.97	0.73	0.22
select_random_ranges	1.20	1.04	0.42
table_scan	1235.62	484.44	183.21
types_table_scan	2778.39	1235.62	434.83
oltp_delete_insert	7.43	6.79	2.22
oltp_insert	4.10	3.43	1.10
oltp_read_write	20.00	13.46	4.41
oltp_update_index	4.10	3.62	1.14
oltp_update_non_index	3.82	3.30	1.14
oltp_write_only	8.28	6.91	1.82
types_delete_insert	7.98	7.17	2.30

Here’s a graph of the multipliers against Postgres:

The rest of this blog will go over every performance-related change since v0.56.3.

Wire Format Serialization Improvements#

When comparing the flamegraphs against Dolt, the code paths surrounding wire format serialization and sending packets had the largest CPU usage discrepancy.

Buffered Flush#

Perhaps the largest performance improvement we saw was with this 9 line change. The Doltgres server needs to send result rows back the client using the Postgres protocol, which we do through the pgproto3 package. Typically, these results are buffered and flushed out in large batches. However, we were sending a packet for every individual row (including the initial row descriptor), wasting a ton of CPU cycles. After adjusting the send logic to call Flush() every row_batch_size = 128, we saw drastic performance improvements practically across the board.

Benchmarks that returned multiple rows saw throughput improvements of over 200%, with some as high as 247%. You can view the full results here.

Spooling Concurrency#

Another improvement around sending rows back to the client is one we’ve already done before in Dolt. The server handler is in charge of reading results from RowIters, converting them into the wire format, and sending these packets to the client. Similar to the old Dolt code, we put two goroutines in charge of these steps: one to read the rows and another to convert and send the results. The fix here is to break these steps up into three goroutines: (1) read the rows from RowIter, (2) convert each row into wire format through SQL() method, and (3) spool results to client. The resulting optimization gave us over 50% improvement in throughput for index_scan, table_scan, and types_table_scan; these are all benchmarks that return large result sets.

You can view the full results here.

Output Function Cache#

The serialization format functions are fully customizable by users. While this can be pretty useful, it requires additional complexity to be efficient. Namely, we should not be reloading the output function every time we serialize a field, especially since it doesn’t change within a query. So, the solution is to just cache it somewhere.

This change got us ~13% improvement in output heavy benchmarks like index_scan, table_scan, and types_table_scan.

You can view the full results here.

Wire Format Improvements#

These next optimizations all involve improving the wire format serialization itself. Specifically, we made improvements to the TimeOfDay, bpchar, and Date types.

fmt.Sprintf() is handy but slow. Since TimeOfDay.String() produces is a small string with a strict format and known max length, we can just create a []byte and append to it. Additionally, we can safely use the unsafe package, to convert that []byte to a string.

func (t TimeOfDay) String() string {
	dest := make([]byte, 0, 15) // longest possible result is len("12:34:56.123456") = 15
	h, m, s, ms := t.Hour(), t.Minute(), t.Second(), t.Microsecond()
	dest = append(dest,
		'0'+byte(h/10), '0'+byte(h%10), ':',
		'0'+byte(m/10), '0'+byte(m%10), ':',
		'0'+byte(s/10), '0'+byte(s%10))
	if ms > 0 {
		dest = append(dest, '.')
		cmp := 100_000
		for cmp > 0 {
			dest = append(dest, '0'+byte(ms/cmp))
			ms %= cmp
			cmp /= 10
		}
		// trim trailing 0s
		for i := len(dest) - 1; i >= 0; i-- {
			if dest[i] != '0' {
				dest = dest[:i+1]
				break
			}
		}
	}
	return unsafe.String(unsafe.SliceData(dest), len(dest))

Next, we made an improvement to truncateString() for bpchar by again writing our own implementation. The old implementation used the utf8 package to get the rune length and decode each rune.

func truncateString(val string, runeLimit int32) (string, int32) {
	runeLength := int32(utf8.RuneCountInString(val))
	if runeLength > runeLimit {
		startString := val
		for i := int32(0); i < runeLimit; i++ {
			_, size := utf8.DecodeRuneInString(val)
			val = val[size:]
		}
		return startString[:len(startString)-len(val)], runeLength
	}
	return val, runeLength

Here’s a Golang fun fact: len(string) returns the number of bytes, while for pos := range string returns start indexes of each rune. Using this, we can rewrite the same logic like so:

func truncateString(val string, runeLimit int32) (string, int32) {
	var n int32
	for pos := range val {
		if n >= runeLimit {
			return val[:pos], n
		}
		n++
	}
	return val, n

This avoids iterating over the string twice and avoids extra string slicing logic.

You can view the full results here.

Doltgres allows users to change the format of the date output through session variables. So during the wire formatting stage, we must call GetDateStyleOutputFormat(), which acquires a mutex and does a bunch of string operations. The DATE style shouldn’t change within a query, so it makes no sense to do all these steps for each row and each DATE field. Caching the format in the context, netted us 10%-14% improvement on the index_scan, table_scan, and types_table_scan benchmarks.

You can view the full results here.

Lastly, we made the *_scan benchmarks a faster by adjusting this single line.

-return sqltypes.MakeTrusted(sqltypes.Text, types.AppendAndSliceString(dest, value)), nil
+return sqltypes.MakeTrusted(sqltypes.Text, encodings.StringToBytes(value)), nil

This was a relic from copying over code from Dolt, where the SQL() methods are able to share a large byte buffer to reduce memory allocations. This isn’t possible in Doltgres, so appending value to dest here is just wasting a copy operation as we can just use value directly. As a result, index_scan, table_scan and types_table_scan saw a 8%-13% improvement.

You can view the full results here.

Collections#

Doltgres implements Collections which hold both built-in and user-defined functions, views, procedures, types, etc. However, we were being very inefficient by loading these collections every query…sometimes multiple times! On our first pass, we cached Collections per query, reducing the number of loads. This gave us a decent performance bump across all the benchmarks (around 5%-12%).

Later on, we improved this further by simplifying Collections storage. This resulted in another decent bump across the board, so around 5%-15% improvement.

You can view the full results here.

Analyzer Improvements#

The analyzer is an essential component to improving the query performance in Doltgres, and ours could use a lot of improving. Here is some of the work we did to analysis and costing that has led to better latency in Doltgres (and Dolt).

Fix Covering Indexes#

This performance optimization is actually bug fix and the first Doltgres performance improvement I made chronologically. Dolt was missing a case for sql.ExtendedType, which Doltgres explicitly uses, so indexes weren’t getting used properly. Afterwards, we received a nice 21.5% bump in throughput for covering_index_scan and 11.5% for select_random_ranges.

You can view the full results here.

No Index GroupBy#

After some investigation, it appears that sometimes it is better to perform a full table scan rather than lookups through a secondary index. This is because non-covering secondary indexes perform two lookups, making them expensive for filters with low selectivity. We adjusted our coster to include a full table scan option when assigning indexes and added some heuristics.

As a result, median latency on the groupby_scan benchmark saw a 43.80% improvement. You can view the full results here.

We have previously discussed this optimization in greater detailed in this blog.

Conclusion#

For fun, here are all the latency benchmarks we have compared against Postgres:

test	dolt	doltgres	mysql	postgres	dolt vs postgres	doltgres vs postgres	mysql vs postgres
covering_index_scan	2.35	2.48	17.32	18.28	0.13	0.14	0.95
groupby_scan	63.32	74.46	134.90	40.37	1.57	1.84	3.34
index_join	1.93	2.22	3.43	1.82	1.06	1.22	1.88
index_join_scan	1.32	1.61	4.25	0.69	1.91	2.33	6.16
index_scan	196.89	484.44	344.08	183.21	1.07	2.64	1.88
oltp_point_select	0.25	0.37	0.19	0.15	1.67	2.47	1.27
oltp_read_only	5.00	6.55	3.62	2.66	1.88	2.46	1.36
select_random_points	0.52	0.73	0.35	0.22	2.36	3.32	1.59
select_random_ranges	0.64	1.04	0.38	0.42	1.52	2.48	0.90
table_scan	196.89	484.44	344.08	183.21	1.07	2.64	1.88
types_table_scan	442.73	1235.62	746.32	434.83	1.02	2.84	1.72
oltp_delete_insert	6.21	6.79	7.70	2.22	2.80	3.06	3.47
oltp_insert	3.13	3.43	4.03	1.10	2.85	3.12	3.66
oltp_read_write	11.24	13.46	8.90	4.41	2.55	3.05	2.02
oltp_update_index	3.30	3.62	4.33	1.14	2.89	3.18	3.80
oltp_update_non_index	3.02	3.30	4.10	1.14	2.65	2.89	3.60
oltp_write_only	6.21	6.91	5.18	1.82	3.41	3.80	2.85
types_delete_insert	6.79	7.17	8.28	2.30	2.95	3.12	3.60
avg_mult					1.92	2.59	2.55

Using some old tricks and writing some new ones, we’ve trimmed a lot of fat from Doltgres; in fact, we’re about as lean as MySQL (which is apparently not that lean standing next to Postgres). We are still 2.6x slower than Postgres, so we have a long ways to go. Dolt stands at 1.92x, so the theoretical best Doltgres can do (as far as we know) is under 2x. Feel free to chat with us on Discord or file a Github issue.

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 augments 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 really 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 effectiveness 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 occasional 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 install 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.

DoltHub Blog - Latest Posts

Home and Pricing Page Redesign

Homepage#

Pricing#

Conclusion#

Postgres follows the SQL standard for UPDATE statements, unlike MySQL

UPDATE with column values from the same row#

Introducing engine overrides#

Conclusion#

Implementing Type Contracts via Mutually Referencing Type Parameters

The Problem#

What Doesn’t Work: Interfaces#

The Bad Idea: A Single Generic Interface#

Almost A Solution: Generic Interfaces#

The Correct Idea: Mutually Referential Type Parameters#

The Blind Spot#

any Type Constraints#

Ambiguity in documentation#

Conclusion#

Footnotes#

Introducing the Hosted Dolt REST API

Motivation#

Built on the DoltHub API v2#

What it covers#

Getting a token#

Creating a deployment#

1. See what you can create#

2. Create it#

3. Wait for it to start#

Inspecting a deployment#

Disabling a deployment#

Documentation#

Future work#

Conclusion#

What's New With Golang Generics

Generic Type Aliases (Added in Go 1.24)#

Recursive Type Constraints (Added in Go 1.26)#

Generic Methods (Added in Go 1.27)#

Overall Impact#

Doltgres is as Fast as MySQL is Slow

Overview#

Wire Format Serialization Improvements#

Buffered Flush#

Spooling Concurrency#

Output Function Cache#

Wire Format Improvements#

Collections#

Analyzer Improvements#

Fix Covering Indexes#

No Index GroupBy#

Conclusion#

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).#

`any` Type Constraints#

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#