Here at DoltHub we're hard at work on Doltgres, our Postgres-flavored version of Dolt. Dolt is the world's first version controlled database but it's MySQL-flavored. After years of customer feedback requesting a Postgres version, we caved and started building Doltgres in mid-2023.

We're rapidly approaching Doltgres Beta which we defined as:

1. sqllogictest Correctness above 99%
2. sysbench Latency under 5X Postgres
3. pgdump compatibility
4. Workbench Compatibility
5. Users and Grants
6. Replicas
7. Hosted Doltgres

Of these, we're still working on (1) sqllogictest correctness and (3) pgdump compatibility. We're in the long tail of syntax bugs. The rest are pretty much good to go. This article is a plea for help on pgdump compatibility.

Almost there...

We're almost at Doltgres Beta.

All of the Dolt version control functionality works in Doltgres. Dolt procedures have become Doltgres functions because in Postgres, procedures cannot return values and functions can modify database state. Dolt system tables remain unchanged in Doltgres.

There has been a lot of progress on compatibility. Information schema is mostly implemented. History independence on OIDs was a challenge. Doltgres contains most types. We have CREATE DOMAIN and CREATE FUNCTION support. We implemented COPY FROM syntax which is often used in migrations, imports, and dumps. We launched users and grants support. The Dolt Workbench works with Doltgres. All of this work culminated in the launch of Hosted Doltgres a couple weeks ago.

The missing piece has been a large collection of pgdumps. We know from our experience launching Dolt that the first thing users do is import a dump of their current database. If that doesn't work, prospective users are likely to churn out. We need to get Doltgres pgdump compatibility as good as possible for Beta launch.

Example Dumps

To illustrate Doltgres pgdump compatibility and how additional dumps help make Doltgres Beta ready I will work through a couple example dumps.

While not technically a dump, we used to run the database that backs the DoltHub website on Postgres. As part of our Dolt 1.0 extravaganza, we moved that database to Dolt. We had all the Postgres migration SQL still available in Git so we grabbed it and tried to run them against Doltgres.

The first error we encountered was with this SQL.

CREATE TABLE delivery_attempt_headers (
  delivery_attempt_id_fk varchar not null references delivery_attempts(id) on de
lete cascade,
  is_response boolean,
  ordinal int,
  "key" varchar,
  "value" varchar,

  primary key (delivery_attempt_id_fk, is_response, "key")
);
alter table delivery_attempt_headers drop constraint delivery_attempt_headers_pkey;

This SQL when attempted in Doltgres, fails with:

ERROR:  Constraint "delivery_attempt_headers_pkey" does not exist (errno 1105) (sqlstate HY000)

It looks like we need to match the way Postgres names constraints, especially primary key constraints. There are other errors in these SQL files that we need to work through. So, as you can see, the SQL files provide a real-world example of a set of SQL Doltgres must support.

The second example I worked through was AdventureWorks which is an open source SQL database schema and data I found through some searching.

After commenting out the extensions, which Doltgres does not support yet, the first error we encountered was with this SQL.

  CREATE TABLE BusinessEntity(
    BusinessEntityID SERIAL, --  NOT FOR REPLICATION
    rowguid uuid NOT NULL CONSTRAINT "DF_BusinessEntity_rowguid" DEFAULT (uuid_generate_v1()), -- ROWGUIDCOL
    ModifiedDate TIMESTAMP NOT NULL CONSTRAINT "DF_BusinessEntity_ModifiedDate" DEFAULT (NOW())
  )
  CREATE TABLE Person(
    BusinessEntityID INT NOT NULL,
    PersonType char(2) NOT NULL,
    NameStyle "NameStyle" NOT NULL CONSTRAINT "DF_Person_NameStyle" DEFAULT (false),
    Title varchar(8) NULL,
    FirstName "Name" NOT NULL,
    MiddleName "Name" NULL,
    LastName "Name" NOT NULL,
    Suffix varchar(10) NULL,
    EmailPromotion INT NOT NULL CONSTRAINT "DF_Person_EmailPromotion" DEFAULT (0),
    AdditionalContactInfo XML NULL, -- XML("AdditionalContactInfoSchemaCollection"),
    Demographics XML NULL, -- XML("IndividualSurveySchemaCollection"),
    rowguid uuid NOT NULL CONSTRAINT "DF_Person_rowguid" DEFAULT (uuid_generate_v1()), -- ROWGUIDCOL
    ModifiedDate TIMESTAMP NOT NULL CONSTRAINT "DF_Person_ModifiedDate" DEFAULT (NOW()),
    CONSTRAINT "CK_Person_EmailPromotion" CHECK (EmailPromotion BETWEEN 0 AND 2),
    CONSTRAINT "CK_Person_PersonType" CHECK (PersonType IS NULL OR UPPER(PersonType) IN ('SC', 'VC', 'IN', 'EM', 'SP', 'GC'))
  )

This SQL when attempted in Doltgres, fails with:

ERROR:  at or near "null": syntax error: unimplemented: this syntax

Looks like Doltgres does not like Title varchar(8) NULL. Specifying the default value of a column as NULL in this way is weird, so weird in fact, Google couldn't help me answer if it was valid syntax. I had to ask ChatGPT if it is valid syntax. The LLM wouldn't lie to me and it said it is valid but not necessary. It looks like Doltgres has to support this weird form of column definition as well.

Again, as you can see, real-world SQL files define a good set of SQL Doltgres must support.

Please Help

If you're reading this, we need your help. pgdump your database for us. Schema only dumps are great. No data necessary. You can even obfuscate the column names if you are worried about privacy. Have a pgdump that can help us? Stop by our Discord and let us know.