Platforms

Extension binaries are distributed for several platforms (see below). For platforms where packages for certain extensions are not available, users can build them from source and install the resulting binaries manually.

All official extensions are distributed for the following platforms.

For some Linux ARM distributions (e.g., Python), two different binaries are distributed. These target either the linux_arm64 or linux_arm64_gcc4 platforms. Note that extension binaries are distributed for the first, but not the second. Effectively that means that on these platforms your glibc version needs to be 2.28 or higher to use the distributed extension binaries.

Some extensions are distributed for the following platforms:

• windows_amd64_mingw
• wasm_eh and wasm_mvp (see DuckDB-Wasm's extensions)

For platforms outside the ones listed above, we do not officially distribute extensions (e.g., linux_arm64_android, linux_arm64_gcc4).

Extensions Signing

Signed Extensions

Extensions can be signed with a cryptographic key. By default, DuckDB uses its built-in public keys to verify the integrity of extension before loading them. All core and community extensions are signed by the DuckDB team.

Signing the extension simplifies their distribution, this is why they can be distributed over HTTP without the need for HTTPS, which is itself is supported through an extension (httpfs).

Unsigned Extensions

Warning Only load unsigned extensions from sources you trust. Avoid loading unsigned extensions over HTTP. Consult the Securing DuckDB page for guidelines on how set up DuckDB in a secure manner.

If you wish to load your own extensions or extensions from third-parties you will need to enable the allow_unsigned_extensions flag. To load unsigned extensions using the CLI client, pass the -unsigned flag to it on startup:

duckdb -unsigned

Now any extension can be loaded, signed or not:

LOAD './some/local/ext.duckdb_extension';

For client APIs, the allow_unsigned_extensions database configuration options needs to be set, see the respective Client API docs. For example, for the Python client, see the Loading and Installing Extensions section in the Python API documentation.

Binary Compatibility

To avoid binary compatibility issues, the binary extensions distributed by DuckDB are tied both to a specific DuckDB version and a platform. This means that DuckDB can automatically detect binary compatibility between it and a loadable extension. When trying to load an extension that was compiled for a different version or platform, DuckDB will throw an error and refuse to load the extension.

Creating a Custom Repository

You can create custom DuckDB extension repository. A DuckDB repository is an HTTP, HTTPS, S3, or local file based directory that serves the extensions files in a specific structure. This structure is described in the “Downloading Extensions Directly from S3” section, and is the same for local paths and remote servers, for example:

base_repository_path_or_url
└── v1.0.0
    └── osx_arm64
        ├── autocomplete.duckdb_extension
        ├── httpfs.duckdb_extension
        ├── icu.duckdb_extension
        ├── inet.duckdb_extension
        ├── json.duckdb_extension
        ├── parquet.duckdb_extension
        ├── tpcds.duckdb_extension
        ├── tpcds.duckdb_extension
        └── tpch.duckdb_extension

See the extension-template repository for all necessary code and scripts to set up a repository.

When installing an extension from a custom repository, DuckDB will search for both a gzipped and non-gzipped version. For example:

INSTALL icu FROM '⟨custom repository⟩';

The execution of this statement will first look icu.duckdb_extension.gz, then icu.duckdb_extension in the repository's directory structure.

If the custom repository is served over HTTPS or S3, the httpfs extension is required. DuckDB will attempt to autoload the httpfs extension when an installation over HTTPS or S3 is attempted.