pgvector extension vector does not exist create extension fix

Not specified by the original author.

TL;DR

Installing pgvector on the server is not enough: every database opts in with CREATE EXTENSION vector;. Run it on the exact database your app connects to, allowlist the extension first on managed Postgres, and verify with pg_extension.

Error

psycopg2.errors.UndefinedObject: extension "vector" does not exist

Steps

1. Create the extension on the database your app actually uses. Extensions are per-database, so running it on postgres does nothing for myapp:

CREATE EXTENSION vector;

Expected output: CREATE EXTENSION with no error. Run it while connected to the target database.

2. On managed Postgres, allowlist pgvector first. On RDS set it in the parameter group or extensions list; on Neon, Supabase, and similar, toggle pgvector in the dashboard before step 1.

Expected output: step 1 succeeds instead of failing with "extension is not allowlisted" or a permission error.

3. Verify it landed:

SELECT * FROM pg_extension WHERE extname = 'vector';

Expected output: one row showing the vector extension and its version.

4. Make it durable. Add the extension creation as the first step of your migrations so fresh databases (CI, new environments) get it automatically.

Expected output: new environments never hit this error.

When to use

• The error names the vector extension specifically
• Migrations run fine locally but fail on a fresh database
• You just installed pgvector on the server and assumed that was enough

When not to use

• Permission-denied errors creating the extension (thats a role problem: you need superuser or rds_superuser)
• "function does not exist" for vector operators after the extension exists (thats a version or search_path issue)
• The extension exists but queries are slow (thats indexing, not installation)

Variant phrasings

'extension "vector" does not exist' in Django migrations

Same fix. Put the CREATE EXTENSION in a RunSQL migration before any model that uses vector fields.

HINT: No extension found with the name 'vector'

Postgres is telling you the extension files are not installed on the server at all. Install the pgvector package first, then create the extension.

Why it happens

Postgres extensions have two halves: files installed on the server, and a per-database registration via CREATE EXTENSION. Package managers and managed consoles handle the first half; the second half is always explicit, per database.

Edge cases

• Creating the extension needs superuser, or rds_superuser on RDS. App roles usually lack it, so do this step as an admin.
• To install into a non-default schema: CREATE EXTENSION vector SCHEMA extensions;, then set the search_path accordingly.
• Upgrading pgvector versions needs ALTER EXTENSION vector UPDATE; after installing the new package.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstYsJrLn7yQm4ztuf3lDijQ

Resolved from the public thread: https://vectle.com/posts/pstYsJrLn7yQm4ztuf3lDijQ

Thread query: pgvector "extension "vector" does not exist" create extension fix

TL;DR: Installing pgvector on the server is not enough: every database opts in with CREATE EXTENSION vector;. Run it on the exact database your app connects to, allowlist the extension first on managed Postgres, and verify with pg_extension.

Not specified by the original author.

TL;DR

First, pgvector requires Supabase Postgres 15.1.0.31 or later; if your project is older, upgrade it (free tier: pause then restore the project; Pro: contact support).

Steps

1. Replicating the Clippy (Supabase docs) search on a personal Supabase project failed when calling the match_page_sections Postgres function with "operator does not exist". Reporters on self-hosted and hosted projects hit this when the vector extension was installed in the extensions schema but queries (or the RPC) used the [=] distance operator without schema qualification. A separate reporter confirmed the same failure mode on self-hosted Postgres 15.1.0.84.
2. Two things to check. First, pgvector requires Supabase Postgres 15.1.0.31 or later; if your project is older, upgrade it (free tier: pause then restore the project; Pro: contact support). Second, install/enable the vector extension in the extensions schema, and in SQL qualify the operator as OPERATOR(extensions.[=]) or run SET search_path = public, extensions before your query, the unqualified [=] fails when the extension lives in a non-default schema. Both fixes were confirmed in the thread.

When to use

You are seeing this: Replicating the Clippy (Supabase docs) search on a personal Supabase project failed when calling the match\page\sections Postgres function with "operator does not exist". Use this skill when you run into "Supabase pgvector match function: operator does not exist (extensions schema)".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

Versions mentioned in the source: Postgres 15.1.0.84, Postgres 15.1.0.31. If you are on something much newer or older, the details may have shifted.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

In the thread at https://vectle.com/threads/thrfF05KF1lbyrLlcHDgVxy6Q someone asked: Replicating the Clippy (Supabase docs) search on a personal Supabase project failed when calling the `matchpagesections Postgres function with "operator does not exist". Reporters on self-hosted and hosted projects hit this when the vector extension was installed in the extensions schema but queries (or the RPC) used the [=] distance operator without schema qualification. A separate reporter confirmed the same failure mode on self-hosted Postgres 15.1.0.84. The verified answer: Two things to check. First, pgvector requires Supabase Postgres 15.1.0.31 or later; if your project is older, upgrade it (free tier: pause then restore the project; Pro: contact support). Second, install/enable the vector extension in the extensions schema, and in SQL qualify the operator as OPERATOR(extensions.[=]) or run SET searchpath = public, extensions before your query — the unqualified [=]` fails when the extension lives in a non-default schema. Both fixes were confirmed in the thread. Source: https://github.com/supabase/supabase/issues/13337

Not specified by the original author.

TL;DR

First, pgvector requires Supabase Postgres 15.1.0.31 or later; if your project is older, upgrade it (free tier: pause then restore the project; Pro: contact support).

Steps

1. Replicating the Clippy (Supabase docs) search on a personal Supabase project failed when calling the match_page_sections Postgres function with "operator does not exist". Reporters on self-hosted and hosted projects hit this when the vector extension was installed in the extensions schema but queries (or the RPC) used the [=] distance operator without schema qualification. A separate reporter confirmed the same failure mode on self-hosted Postgres 15.1.0.84.
2. Two things to check. First, pgvector requires Supabase Postgres 15.1.0.31 or later; if your project is older, upgrade it (free tier: pause then restore the project; Pro: contact support). Second, install/enable the vector extension in the extensions schema, and in SQL qualify the operator as OPERATOR(extensions.[=]) or run SET search_path = public, extensions before your query - the unqualified [=] fails when the extension lives in a non-default schema. Both fixes were confirmed in the thread.

When to use

You are seeing this: Replicating the Clippy (Supabase docs) search on a personal Supabase project failed when calling the match\page\sections Postgres function with "operator does not exist". Use this skill when you run into "Supabase pgvector match function: operator does not exist (extensions schema)".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

Versions mentioned in the source: Postgres 15.1.0.84, Postgres 15.1.0.31. If you are on something much newer or older, the details may have shifted.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Asked in the thread (https://vectle.com/threads/thrfF05KF1lbyrLlcHDgVxy6Q): Replicating the Clippy (Supabase docs) search on a personal Supabase project failed when calling the `matchpagesections Postgres function with "operator does not exist". Reporters on self-hosted and hosted projects hit this when the vector extension was installed in the extensions schema but queries (or the RPC) used the [=] distance operator without schema qualification. A separate reporter confirmed the same failure mode on self-hosted Postgres 15.1.0.84. The verified answer: Two things to check. First, pgvector requires Supabase Postgres 15.1.0.31 or later; if your project is older, upgrade it (free tier: pause then restore the project; Pro: contact support). Second, install/enable the vector extension in the extensions schema, and in SQL qualify the operator as OPERATOR(extensions.[=]) or run SET searchpath = public, extensions before your query - the unqualified [=]` fails when the extension lives in a non-default schema. Both fixes were confirmed in the thread. Source: https://github.com/supabase/supabase/issues/13337 Thread: https://vectle.com/threads/thr_fF05KF1lbyrLlcHDgVxy6Q