Where it is: Settings → Knowledge & Sync → Supabase Vector Database (optional).
By default, similarity search runs in your own WordPress database, which is simple, works on any hosting, and is fast enough for most sites. Past a few hundred entries it starts to show, because comparing vectors in PHP is not what MySQL is for. Supabase is a hosted Postgres service with the pgvector extension and a free tier; the plugin can mirror your knowledge base into it and search there instead.
Do this
- Create a project at supabase.com.
- Open its SQL editor and run the setup SQL printed at the bottom of the Knowledge & Sync tab. Copy it from there rather than from anywhere else — it always matches your version.
- In Supabase, open Project Settings → API and copy the project URL and the service role key. Not the anon key: the anon key cannot write.
- Paste both into the plugin, tick Use Supabase, and save.
- Press Test Connection, then Sync to Supabase to copy the existing knowledge base across.
What the SQL creates
- The
vectorextension, and adocumentstable holding an id, title, content and embedding. - An index for fast similarity search.
- A
match_documentsfunction, which is what the plugin calls to find the closest passages.
Checking it is on
The Search status row reads either Supabase Active, with the document count on both sides, or MySQL Mode with the reason. The two counts should match after a sync; if Supabase is behind, run the sync again.
If you change embedding provider afterwards
Embeddings from different providers are different sizes — 1536 numbers from OpenAI, 1024 from Voyage — and Postgres will not convert one into the other. Switching provider therefore means clearing the old vectors, altering the column, recreating match_documents at the new size, and re-embedding. The plugin prints that exact SQL beside the warning when you change the setting. Recreating the function is the step people skip, and skipping it makes every vector search fail quietly and fall back to keywords alone.