Postgres extensions

Extensions add features to Postgres: vector search, geographic types, fuzzy text matching, scheduling and more. On SupaHost, the extensions you can use are the ones that ship in the Supabase Postgres image your instance runs, supabase/postgres 17 (release 2026.11.02 uses 17.6.1.136). There's no separate list to request from; if the image has it, you can enable it.

Each project is its own database, so extensions are enabled per project. Turning on vector in one project doesn't affect the others.

See what's available

In Studio's SQL editor (or any SQL session):

select name, default_version, installed_version, comment
from pg_available_extensions
order by name;

installed_version is filled in for extensions already enabled in this project.

Other ways to see the same list:

• Studio: Database → Extensions, with a toggle per extension.
• MCP: the list_extensions tool returns each extension with its installed and default versions and schema. Handy when an AI agent needs to know whether vector or postgis is enabled before writing a migration.

Enable an extension

Create extensions in the extensions schema:

create extension if not exists vector with schema extensions;
create extension if not exists pg_trgm with schema extensions;

Why extensions rather than public:

• It keeps public (which the Data API exposes) free of dozens of helper functions and types.
• The Data API already adds extensions to its search path, so types like vector and functions like similarity() still resolve in API requests and in your own functions.

When you write functions with set search_path = '', refer to extension objects with the schema, for example extensions.vector(1536) or extensions.similarity(a, b).

Put the create extension line in a migration so a branch or a new project gets the same setup. See SQL migrations.

Example: fuzzy search on recipe titles

create extension if not exists pg_trgm with schema extensions;

create index recipes_title_trgm
  on public.recipes using gin (title extensions.gin_trgm_ops);

select title, extensions.similarity(title, 'chiken curry') as score
from public.recipes
where title operator(extensions.%) 'chiken curry'
order by score desc
limit 5;

Remove an extension

drop extension if exists pg_trgm;

If tables, columns or indexes depend on the extension, Postgres refuses and lists them. drop extension ... cascade removes those objects too, including columns that use the extension's types, so read the list before you add cascade.

Special cases on SupaHost

pg_cron is built in: don't create it

Scheduling works in every project without enabling anything. Call cron.schedule() directly:

select cron.schedule('nightly-cleanup', '0 3 * * *', $$
  delete from public.sessions_log where created_at < now() - interval '30 days'
$$);

Do not run create extension pg_cron. pg_cron can only be installed in one database per Postgres server, and on SupaHost that's the instance's own postgres database. Each project gets a cron schema that forwards to it, so cron.schedule, cron.unschedule, cron.job and cron.job_run_details work as usual. Running create extension pg_cron in a project fails. The MCP server's execute_sql and apply_migration skip that statement and explain why, and list_extensions shows pg_cron with a note that it's built in. See Scheduled jobs with pg_cron and ERROR: can only create extension in database postgres.

pg_net is already installed

pg_net (asynchronous HTTP from SQL) and the supabase_functions schema used by database webhooks are set up when the project is created. See Database webhooks and HTTP requests with pg_net.

Leave dblink in place

dblink is installed in the extensions schema of every project because the cron shim uses it to reach pg_cron. Dropping it breaks cron.schedule() in that project.

Queues: use the dashboard

To use pgmq, click Enable Queues on the project's Queues tab instead of creating the extension yourself. That also creates the pgmq_public functions the Data API exposes. See Queues with pgmq.

pg_graphql has no HTTP endpoint

The graphql_public schema exists, but there's no /graphql/v1 route on SupaHost, so GraphQL over HTTP isn't available. Use the REST Data API.

Extensions people often look for

Check the list in your project for exact names and versions. These are typical of the Supabase image:

Supabase deprecated a few extensions for Postgres 17, including plv8, timescaledb and pgjwt. If an app you're moving relies on one of them, check pg_available_extensions first. When you import a project from Supabase Cloud, extensions that aren't available here are skipped with a warning.

Some extensions need to be preloaded when the server starts. Those only work if the image already preloads them; server-level settings aren't something you change on SupaHost.

Updating an extension

A newer Postgres image can ship newer extension versions. In Postgres, an enabled extension stays at its installed version until someone runs alter extension ... update, so compare the two:

select name, installed_version, default_version
from pg_available_extensions
where installed_version is not null and installed_version <> default_version;

alter extension vector update;

Related

• Postgres on SupaHost
• Supabase features on SupaHost