D1

DoltgreSQL

Azure Databases 1 variation

DoltgreSQL, a database that speaks PostgreSQL and versions your data like source code: commit, branch, diff, merge and time travel over your tables.

Base
Hardened build
minimal ports, security patches applied at build time
Access
Unique credentials
generated on first boot, readable only by root
Verified
Boots working
services pass a health gate before release
Support
24/7, 365 days
by email and live chat, 24 hour response SLA

Variations

This product is available in the build below. Open it for the operating system, cloud and version detail, or read its deployment guide.

ProductCloudOperating systemVersion
DoltgreSQL 1.3 Version Controlled Database on Ubuntu 24.04 LTS Azure Ubuntu 24.04 1.3 View · Guide

Overview

DoltgreSQL is a database that speaks the PostgreSQL wire protocol, so ordinary PostgreSQL clients and drivers connect to it unchanged, and stores its tables in a Dolt repository, so the data itself is version controlled. You commit a set of rows, branch the database, change the branch without touching the trunk, see a row by row diff between the two, merge one into the other, and read the table as it stood at any earlier commit. All of it is driven from SQL, so there is nothing new to install on the client side and nothing to learn beyond a handful of functions.

That combination is unusual. Point in time recovery restores a whole database to a moment; audit tables record what changed but not how two versions differ; a plain dump is a file, not a history you can branch from. DoltgreSQL treats the contents of your tables the way version control treats source code, which suits data that is curated and reviewed rather than merely accumulated: reference and master data, configuration and rules, machine learning training sets, and any dataset where somebody needs to answer what changed, who changed it and what it looked like before.

Why the cloudimg image

DoltgreSQL starts with a documented default superuser password, and it only lets that password be chosen at the moment its data directory is first created, so an image that ships a ready made database ships one known credential to every customer who launches it. cloudimg ships no database at all. The image carries the binary and its configuration and nothing else, and the first boot of every instance creates its own data directory with its own generated password, handed to the server on standard input so it never appears in a command line, a log or a file other than one only root can read. The instance then checks that the published default really is refused before it finishes booting, and the database service is held shut until that is done, so there is no moment when a known password is live. Every instance also gets its own commit history and its own server identity rather than a copy of the build machine's. The database listens only on the loopback interface, the sole port reachable from the network is SSH, and the paired guide walks through reaching it over an SSH tunnel. The base is fully patched with unattended security updates left enabled, and every instance is backed by 24/7 cloudimg support.

Common uses

  • Version reference, master or configuration data with branches, diffs and merges
  • Review and approve data changes before they reach the trunk, the way code is reviewed
  • Reproduce an earlier state of a dataset for audit, debugging or model training