Doltgres adds multidimensional arrays as it fills PostgreSQL compatibility gaps
The September 24th release handles nested arrays and their PostgreSQL functions, extending the product's post-1.0 push to behave like the database it aims to complement.
By RuntimeWire Staff · Published
Primary source: DoltHub Newsroom
Why it matters
Doltgres sells PostgreSQL compatibility alongside Git-like version control for data. Array support narrows one migration gap, while DoltHub's recent data-loss post-mortem shows that correctness also depends on safe upgrades and backups.
DoltHub's Doltgres release adds support for PostgreSQL-style multidimensional arrays, closing another compatibility gap in the version-controlled database that co-founder Tim Sehn has spent years steering toward production use. The update, published September 24th, is a small feature with a demanding job: make Doltgres behave like PostgreSQL closely enough that developers can bring existing applications over without rewriting their SQL.
Sehn's starting point was a broader idea about data access. In his account of DoltHub's history, he traced the idea to a 2013 Amazon Web Services offsite, where he wondered why customers could rent computing and databases but not the data inside them. He and co-founders Aaron Son and Brian Hendriks initially set out to build a data-sharing startup. In 2018, after Hendriks added a Git-style command line to the Noms data system, the founders decided they had a product: Dolt, a SQL database with Git-like operations for data.
That origin still shapes the technical bet. DoltHub built version control into a database; Doltgres brings those capabilities to PostgreSQL's dialect and client ecosystem. DoltHub has said customers wanted a Postgres-compatible version, and Doltgres 1.0 arrived on August 6th, 2026, after nearly three years of development. Array support is the less visible work required to make that proposition credible: applications depend on the small behavioral details of a database, not only on its headline features.
The compatibility work behind the feature
PostgreSQL arrays can hold one-dimensional lists, matrices, and arrays with more dimensions. A column declared as integer[] can contain values of different dimensional shapes; the dimensions describe the stored value rather than a separate array type. DoltHub's example shows a two-row, three-column array and updates one element with the familiar repeated-subscript syntax: nums[2][3] = 60. The result is {{1,2,3},{4,5,60}}.
The release also covers functions and operators that developers use to inspect, modify, combine, and expand arrays, including array_ndims, array_replace, concatenation, and unnest. One PostgreSQL quirk is that unnest flattens a multidimensional array into individual values rather than returning each nested sub-array. Ragged arrays, whose sub-arrays have different lengths, remain invalid; individual NULL elements are allowed, while a NULL cannot stand in for an entire sub-array.
These details matter for migration because an application can rely on behavior that looks incidental until another database handles it differently. DoltHub says the examples in the release post work in the latest Doltgres release. It does not identify the release number in the post, and the examples are DoltHub's own demonstrations rather than an independent compatibility evaluation.
Doltgres 1.0, announced on August 6th, 2026, gives more context for how DoltHub measures compatibility: DoltHub reported a score above 99% on a 5.6-million-query SQL Logic Test suite checked against PostgreSQL and official support for more than 20 client libraries. Those figures describe DoltHub's test results and supported integrations, not every feature or edge case in PostgreSQL. The array update adds a specific set of behaviors to that ongoing work; it does not complete DoltHub's stated goal of full compatibility.
A production claim with a recent caveat
The timing follows Doltgres 1.0, which DoltHub described as ready for production use. That milestone established a commitment to stable storage and version-control interfaces, while DoltHub acknowledged remaining compatibility and performance work. The September array update is one example of the post-1.0 effort to close those gaps.
A separate September 4th post-mortem shows why database readiness is tested in more than compatibility suites. DoltHub said a customer experienced unrecoverable data loss during an August upgrade from an early Doltgres beta version. DoltHub traced the failure to missing references for some stored values during backup and garbage collection, and said the issue was fixed in Doltgres 1.3.0. DoltHub also described safeguards added after the incident, including a startup integrity check for affected databases in 1.3.0 and later.
The incident puts the 1.0 production claim in a concrete context: SQL compatibility is one part of earning confidence in a database, while upgrades, backups, and data integrity are another. DoltHub's own timeline records a long path from the original data-sharing idea to an operational database, including earlier work on storage performance and production reliability.
For Sehn's original thesis, multidimensional arrays are mundane in exactly the useful way. Developers should not have to give up standard PostgreSQL behavior to get version history, branching, and merging for their data. Each compatibility addition makes that tradeoff easier to consider, while the recent incident underscores that the database's production case also rests on reliably preserving the data developers entrust to it.