Similarly to other package management systems, DuckDB's Community Extensions repository contain community-contributed code, therefore, there are no guarantees regarding the content of extensions. The DuckDB Foundation and DuckDB Labs do not vet the code within community extensions and, therefore, cannot guarantee that DuckDB community extensions are safe to use.

For details on securing your DuckDB setup, please refer to the Securing Extensions page.

The loading of community extensions can be explicitly disabled with the following one-way configuration option:

SET allow_community_extensions = false;

For details on securing your DuckDB setup, please refer to the Securing Extensions page.

Writing a DuckDB extension as a collection of SQL macro is already done be a few extensions. The pivot_table and chsql extensions for example follow this pattern.

Currently some C++ wrapper code is required, but this is possibly the simplest way to build a community extension and the best way to package a set of utility macros to be safely distributed.

Writing a DuckDB extension in Rust is possible and several extensions exist already, providing various examples to draw inspiration from.

Currently, writing a Rust-based DuckDB extension requires writing glue code in C++ and will force you to build through DuckDB's CMake & C++ based extension template. We understand that this is not ideal and acknowledge the fact that Rust developers prefer to work on pure Rust codebases. For this (and many other) reason(s), a C Extension API is in development that will allow DuckDB extensions written in pure Rust. As the C Extension API matures, a pure-Rust extension template will be made available.

We are working on adding Go support for extensions.

DuckDB's Extension Template is based on the DuckDB C++ API and uses DuckDB's CMake-based build system. The DuckDB team will currently only provide support for extensions written using this framework. However, note that CMake is pretty flexible: for example, several Rust-based examples already exist.

Additionally, a new C Extension API is available since DuckDB v1.1.

Currently, DuckDB extensions must have a uniquely name. For this reason, PRs that introduce naming collisions will not be accepted and will require a rename. To resolve this, manual namespacing would be the solution, for example by prefixing your vendor name to the extension name: ⟨vendor⟩_⟨extname⟩.

Note that in general the DuckDB team reserves the right to refuse extension names, or force an extension rename. For example, when an extension is no longer actively maintained, the DuckDB team may decide to rename or even remove the extension to make the name available for another extension. Don't worry though, we will always contact the extension maintainers before taking such drastic actions.

The toolchain used to compile DuckDB extensions may not contain all build-time dependencies required to build your extension. If this is the case, please just open a PR adding toolchain components as optional extras.

Alternatively, you can try adding the installation of the required dependencies through the Makefile in your extension repository. However, you should be warned that this could potentially lead to a more fragile build system with a corresponding increased maintainance load as DuckDB and its toolchain is updated.