We're continuing to make progress on DoltgreSQL, which is a version of Dolt built to be a drop-in replacement for PostgreSQL. Dolt is a MySQL compatible database that is built from the ground up with Git-influenced version control features. This means that you can use branch, merge, diff, and more with your data and schema. On our road to being a complete drop-in replacement for Postgres, we started work on supporting native extensions in Doltgres. Today, we're announcing alpha support for using extensions in Doltgres!

What are native extensions?

Last month, I wrote a blog post that dove into native extensions. To summarize it, Doltgres is a bespoke database implementation, built on top of Prolly Trees and implemented in Go. Postgres is implemented in C, and exposes a C API that extension developers target. Rather than requiring extensions to be rewritten to work with an API that we provide, we've chosen to write a bridge that allows our database engine to talk to extensions using the same symbols that they expect from Postgres' C API.

This will eventually give us full compatibility with all past and present extensions that are compiled against Postgres, meaning any user that wants to adopt Doltgres will be able to keep all of their existing extensions. In the meantime, our API coverage is relatively small, so there will be a number of extensions that do not work yet. We're actively working on extending the API support, so please reach out on Discord or file an issue stating which extensions you rely on so we can prioritize support.

Adding Extensions

Adding extensions in Doltgres works the same way that it does in Postgres, so let's go through a quick example. I'll assume that you've started a fresh Doltgres server, and logged in with the default postgres user with a default password of 'password' (which you should absolutely change for a public-facing server). Once you've connected using your favorite Postgres client (we are wire-compatible after all), you can run the following:

postgres=> CREATE TABLE example(v1 UUID);
CREATE TABLE
postgres=> CREATE EXTENSION "uuid-ossp";
CREATE EXTENSION
postgres=> INSERT INTO example VALUES (uuid_generate_v1()), (uuid_generate_v4());
INSERT 0 2
postgres=> SELECT * FROM example;
                  v1
--------------------------------------
 b2151538-6106-11f0-ab15-f7be66bb0b2a
 31ca1552-a456-427e-b2d4-4d4e868ef085
(2 rows)

As long as you have a Postgres installation on your machine, then Doltgres will automatically find the extension files and make the appropriate links to any referenced shared libraries. Doltgres officially supports Windows, Linux, and MacOS, and extensions have only been tested on these platforms.

Current Deficiencies

Besides the growing API support, there are a few more deficiencies with the current alpha release.

• DROP EXTENSION is not yet supported, thus we only allow adding extensions for now.
• Extensions should not be updated once installed, as we pin the version to the artifacts that are created internally in the engine.
• If extensions are used, then all cloned instances of the repository must use the same platform and extension version due to pinning.
• Some extension options are ignored (such as specifying a target schema).
• Extensions that do not have a file in Postgres' extension directory cannot be added.

We have plans on how to address all of these, but we must weigh the tradeoffs considering we must interact with extensions in a unique way compared to Postgres. For example: in Postgres, if a user uses an extension that introduces a new data type, and then updates the extension which changes the underlying serialized data, then the extension migration script will convert all of the data seamlessly. In Doltgres, this would work just fine as long as you're always in the current working set, but as soon as you need to query historical data (say via a commit or branch), then that historical data will still be in the old format, rendering that data unreadable. There are solutions to these kinds of problems, but we're still working through the implications of each decision.

Get In Touch

Once again, we would greatly appreciate hearing what your favorite extensions are! We're expanding the API, but with such a large surface area, it would be beneficial to prioritize the sections that coincide with the most popular extensions from existing and potential users. You can reach out to us on Twitter/X, chat with us on Discord, or file an issue on GitHub! Thank you for reading the blog post!