DoltgreSQL: a version-controlled PostgreSQL you branch and merge in SQL
DoltgreSQL - Version Controlled PostgreSQL. We use these same Sysbench tests to benchmark DoltgreSQL and compare the results to PostgreSQL.
At a glance
- What is it?
- DoltgreSQL (Doltgres) puts Git-style commits, branches and merges on top of a Postgres wire protocol server. It is Beta, the version control surface is SQL only, and the README lists several gaps worth knowing before you point an application at it.
- Who is it for?
- Adopt DoltgreSQL when you need an auditable history of table changes and you can reach it through the Postgres wire protocol with a SQL client, and when a custom remote (filesystem or S3) is enough for sharing. Do not adopt it if your application depends on Postgres extensions, GSSAPI authentication, or push and pull against DoltHub or DoltLab, because the README lists all of those as unavailable or unfinished, and backup and replication are described as a work in progress.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 19, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What DoltgreSQL adds on top of a Postgres server
DoltgreSQL, shortened to Doltgres in the README, is the Postgres-flavored version of Dolt. The README describes it as a SQL database you can branch and merge, fork and clone, push and pull, and says version control is exposed in SQL through system tables, functions and procedures rather than through a command line. The framing sentence in the README is blunt about the model: Git versions files, Doltgres versions tables.
The audience follows from that. If your team already keeps schema migrations and data fixtures in Git and wishes the database itself carried the same history, Doltgres is aimed at you. The README also points at a migration path: import an existing Postgres database with pg_dump and psql. That is a statement about intended workflow, not a guarantee of fidelity, and the same README warns that some Postgres syntax, types, functions and features are not yet implemented.
It is worth being precise about what is being versioned. The examples in the README operate on tables in a database, with dolt_add staging tables and dolt.status reporting them as new table. This is table-level version control, not row-level audit logging, and the mental model of a commit containing a set of table changes is the one the documentation asks you to hold.
How the version control mechanism is wired into SQL
The mechanism visible in the README is a set of system tables and functions that live alongside your own tables. dolt.status is a system table you select from; dolt_add is a function you call with table names; dolt.log is a system table listing commits. There is no separate client process to learn for the basic flow, which is the main architectural difference from Dolt, whose Git-style CLI the README explicitly says does not exist here.
The commit log example shows two rows: one with the message Initialize data repository, and one with Created initial schema. Each row carries a commit_hash, a committer, an email and a date. So the history is materialized as queryable rows, which means you can join it, filter it, or expose it through your own application code the same way you would expose any other table.
Server side, the repository layout is a Go program. The top-level entries include cmd/, core/, server/, servercfg/ and postgres/, and go.mod declares the module github.com/dolthub/doltgresql with a dependency on github.com/dolthub/dolt/go and github.com/dolthub/go-mysql-server. That last dependency is a reminder that the storage and SQL layers are shared with Dolt rather than written from scratch for Postgres. The README's performance section says DoltgreSQL is benchmarked with the same Sysbench tests used for Dolt and compared against PostgreSQL, and it presents median latency figures for version 0.50.0. Those numbers are old relative to the current release line, and the README does not restate them for later versions, so treat the table as historical rather than as a claim about the build you install today.
Installing DoltgreSQL and making your first Dolt commit
The README gives a one-line installer for Linux and Mac systems. It downloads the latest release and places the binary in /usr/local/bin, which the README notes is probably already on your PATH.
sudo bash -c 'curl -L https://github.com/dolthub/doltgresql/releases/latest/download/install.sh | bash'On Windows the README directs you to the latest .msi file in the releases page. There is also an official Docker image, dolthub/doltgresql, published on every release. The README shows this invocation, which sets the password through an environment variable and maps the default port.
docker run -e DOLTGRES_PASSWORD=myPassword -p 5432:5432 dolthub/doltgresql:latestIf you build from source instead, the README says to run ./scripts/build.sh to produce a binary.
Running doltgres with no arguments creates a postgres user and a postgres database in the current directory, with the default password password. The README notes you can point it elsewhere with a config.yaml file or the DOLTGRES_DATA_DIR environment variable, and that DOLTGRES_USER and DOLTGRES_PASSWORD change the superuser before the first run. You need a Postgres client to talk to it; the README uses psql and connects like this.
PGPASSWORD=password psql -h localhost -U postgresOnce connected, create a database and a table, then stage and inspect. The README's getting-started flow creates a getting_started database and an employees table, then runs these two statements.
select dolt_add('teams', 'employees', 'employees_teams');
select * from dolt.status;The first call returns 0, and the status table then shows the staged flag as t for the tables you added, where it was f before. From there, select * from dolt.log lists the commits. The README ends the walkthrough by pointing readers at the Dolt getting-started guide for more versioning functionality.
Where DoltgreSQL is the wrong choice
The README's limitations list is unusually direct, and it should be read before any evaluation. There is no Git-style CLI for version control, only a SQL interface. That is a real constraint if your team's habits, CI scripts or tooling assume commands like dolt commit or dolt checkout. Everything goes through a database connection.
Second, you cannot push to DoltHub or DoltLab. Only custom remotes, such as on the file system or to S3, are supported. If your plan for collaboration was to publish branches to a hosted remote the way Dolt users do, that plan does not work here yet.
Third, backup and replication are described as a work in progress. For a database advertised as ready for production use cases, that is the item to weigh most heavily, because it is the one that determines what happens when a disk fails. The README does not document a supported backup procedure, so you cannot infer one from the documentation.
Fourth, there is no GSSAPI support and no extension support yet. Extensions are a common reason teams pick Postgres in the first place, so a schema that depends on an extension is a blocker rather than an inconvenience.
Finally, the README states that some Postgres syntax, types, functions and features are not yet implemented, and asks you to file an issue for anything missing that your application needs. The project describes itself as Beta quality, ready for production use cases with bugs and missing features expected, and claims it can fix most reported problems within 24 hours. That is a commitment about response time, not about correctness.
How it differs from Dolt and from plain PostgreSQL
The closest alternative is Dolt itself, from the same creators. Dolt is the MySQL-flavored product and the README points to its CLI reference for version control commands. The difference in approach is not cosmetic: Dolt gives you a command line for branch and merge operations, while Doltgres deliberately exposes the same concepts as SQL system tables, functions and procedures. If your existing application and drivers are Postgres, Doltgres is the one that speaks your protocol; if your team wants a CLI-driven workflow and does not care about the Postgres wire protocol, Dolt is the more complete surface.
The other comparison is against an ordinary PostgreSQL server. A stock Postgres instance gives you extensions, GSSAPI, mature backup and replication, and the full syntax surface. What it does not give you is branch, merge, fork, clone, push and pull as first-class database operations. The honest framing is that Doltgres trades Postgres completeness for version control. The README's own limitations list is the price tag on that trade, and it is a longer list than a marketing page would print.
Licence, releases and the cost of keeping up
DoltgreSQL is licensed under Apache-2.0, and the repository carries a LICENSE file at the top level along with a licenses/ directory. Apache-2.0 is a permissive licence that permits commercial use and modification, but this is a description of the licence identifier, not legal advice; if you redistribute the binary or embed the code, read the licence text and your own obligations.
The release cadence visible in the repository is fast. Three releases landed in August 2026: v1.1.0 on 2026-08-12, v1.2.0 on 2026-08-18, and v1.3.0 on 2026-08-28. The last push to the default branch was on 2026-08-28, so the repository has recent activity, though nothing describes a support window or a long-term release branch. The README says the Docker image is published on every release, and the Dockerfile resolves the latest version by querying the GitHub releases API, which means an image tagged latest will move under you. For anything you intend to keep running, pin an explicit version rather than tracking latest.
The upgrade cost is hard to estimate. There is no migration guide in the README, and no statement about on-disk format compatibility between releases. Since the data directory is created in the current working directory by default, or wherever DOLTGRES_DATA_DIR points, the practical question to answer before upgrading in place is whether a newer binary will open a data directory written by an older one. The README does not say.
Editorial conclusion
Adopt DoltgreSQL when you need an auditable history of table changes and you can reach it through the Postgres wire protocol with a SQL client, and when a custom remote (filesystem or S3) is enough for sharing. Do not adopt it if your application depends on Postgres extensions, GSSAPI authentication, or push and pull against DoltHub or DoltLab, because the README lists all of those as unavailable or unfinished, and backup and replication are described as a work in progress. Before committing, verify the specific Postgres syntax, types and functions your schema uses against the documentation, since the README states that some are not yet implemented, and confirm how you will take backups given that the README does not document a supported backup procedure.
Frequently asked questions
What is DoltgreSQL and why use it?
DoltgreSQL is the Postgres-flavored version of Dolt, a SQL database whose tables can be branched, merged, forked, cloned, pushed and pulled. You would use it when you want a history of table changes that behaves like a Git repository while still connecting with an ordinary Postgres client.
What is the difference between SQL and DoltgreSQL?
SQL is the query language; DoltgreSQL is a database server that accepts Postgres-flavored SQL over the Postgres wire protocol and adds version control on top. The README describes the extra layer as system tables, functions and procedures, such as dolt.status, dolt_add and dolt.log.
Is DoltgreSQL the same as MySQL?
No. DoltgreSQL speaks the Postgres protocol and the README recommends connecting with psql. The MySQL-flavored product from the same creators is Dolt, which the README distinguishes by noting that DoltgreSQL has no Git-style CLI and instead exposes version control through SQL.
Is DoltgreSQL difficult to learn?
The basic flow in the README is short: run doltgres, connect with psql, create tables, then call dolt_add and query dolt.status and dolt.log. The difficulty is less in the versioning commands and more in checking whether the Postgres syntax, types and functions your schema uses are implemented yet.
Community notes