PostgreSQL extensions in Azure Database for PostgreSQL - Single Server

PostgreSQL provides the ability to extend the functionality of your database using extensions. Extensions bundle multiple related SQL objects together in a single package that can be loaded or removed from your database with a single command. After being loaded in the database, extensions function like built-in features.

How to use PostgreSQL extensions

PostgreSQL extensions must be installed in your database before you can use them. To install a particular extension, run the CREATE EXTENSION command from psql tool to load the packaged objects into your database.

Azure Database for PostgreSQL supports a subset of key extensions as listed below. This information is also available by running SELECT * FROM pg_available_extensions;. Extensions beyond the ones listed are not supported. You cannot create your own extension in Azure Database for PostgreSQL.

Postgres 11 extensions

The following extensions are available in Azure Database for PostgreSQL servers which have Postgres version 11.

Postgres 10 extensions

The following extensions are available in Azure Database for PostgreSQL servers which have Postgres version 10.

Postgres 9.6 extensions

The following extensions are available in Azure Database for PostgreSQL servers which have Postgres version 9.6.

Postgres 9.5 extensions

The following extensions are available in Azure Database for PostgreSQL servers which have Postgres version 9.5.

pg_stat_statements

The pg_stat_statements extension is preloaded on every Azure Database for PostgreSQL server to provide you a means of tracking execution statistics of SQL statements. The setting pg_stat_statements.track, which controls what statements are counted by the extension, defaults to top, meaning all statements issued directly by clients are tracked. The two other tracking levels are none and all. This setting is configurable as a server parameter through the Azure portal or the Azure CLI.

There is a tradeoff between the query execution information pg_stat_statements provides and the impact on server performance as it logs each SQL statement. If you are not actively using the pg_stat_statements extension, we recommend that you set pg_stat_statements.track to none. Note that some third party monitoring services may rely on pg_stat_statements to deliver query performance insights, so confirm whether this is the case for you or not.

dblink and postgres_fdw

dblink and postgres_fdw allow you to connect from one PostgreSQL server to another, or to another database in the same server. The receiving server needs to allow connections from the sending server through its firewall. When using these extensions to connect between Azure Database for PostgreSQL servers, this can be done by setting "Allow access to Azure services" to ON. This is also needed if you want to use the extensions to loop back to the same server. The "Allow access to Azure services" setting can be found in the Azure portal page for the Postgres server, under Connection Security. Turning "Allow access to Azure services" ON puts all Azure IPs on the allow list.

Currently, outbound connections from Azure Database for PostgreSQL are not supported, except for connections to other Azure Database for PostgreSQL servers in the same region.

If you are planning to use uuid_generate_v4() from the uuid-ossp extension, consider comparing with gen_random_uuid() from the pgcrypto extension for performance benefits.

pgAudit

The pgAudit extension provides session and object audit logging. To learn how to use this extension in Azure Database for PostgreSQL, visit the auditing concepts article.

pg_prewarm

The pg_prewarm extension loads relational data into cache. Prewarming your caches means that your queries have better response times on their first run after a restart. In Postgres 10 and below, prewarming is done manually using the prewarm function.

In Postgres 11 and above, you can configure prewarming to happen automatically. You need to include pg_prewarm in your shared_preload_libraries parameter's list and restart the server to apply the change. Parameters can be set from the Azure portal, CLI, REST API, or ARM template.

TimescaleDB

TimescaleDB is a time-series database that is packaged as an extension for PostgreSQL. TimescaleDB provides time-oriented analytical functions, optimizations, and scales Postgres for time-series workloads.

Learn more about TimescaleDB, a registered trademark of Timescale, Inc.. Azure Database for PostgreSQL provides the TimescaleDB Apache-2 edition.

Installing TimescaleDB

To install TimescaleDB, you need to include it in the server's shared preload libraries. A change to Postgres's shared_preload_libraries parameter requires a server restart to take effect. You can change parameters using the Azure portal or the Azure CLI.

Using the Azure portal:

1. Select your Azure Database for PostgreSQL server.

2. On the sidebar, select Server Parameters.

3. Search for the shared_preload_libraries parameter.

4. Select TimescaleDB.

5. Select Save to preserve your changes. You get a notification once the change is saved.

6. After the notification, restart the server to apply these changes. To learn how to restart a server, see Restart an Azure Database for PostgreSQL server.

You can now enable TimescaleDB in your Postgres database. Connect to the database and issue the following command:

CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;

You can now create a TimescaleDB hypertable from scratch or migrate existing time-series data in PostgreSQL.

Restoring a Timescale database

To restore a Timescale database using pg_dump and pg_restore, you need to run two helper procedures in the destination database: timescaledb_pre_restore() and timescaledb_post restore().

First prepare the destination database:

--create the new database where you'll perform the restore
CREATE DATABASE tutorial;
\c tutorial --connect to the database 
CREATE EXTENSION timescaledb;

SELECT timescaledb_pre_restore();

Now you can run pg_dump on the original database and then do pg_restore. After the restore, be sure to run the following command in the restored database:

SELECT timescaledb_post_restore();

Next steps

If you don't see an extension that you'd like to use, let us know. Vote for existing requests or create new feedback requests in our feedback forum.