Automatic embeddings

Vector embeddings enable powerful semantic search capabilities in Postgres, but managing them alongside your content has traditionally been complex. This guide demonstrates how to automate embedding generation and updates using Supabase Edge Functions, pgmq, pg_net, and pg_cron.

Understanding the challenge#

When implementing semantic search with pgvector, developers typically need to:

1. Generate embeddings via an external API (like OpenAI)
2. Store these embeddings alongside the content
3. Keep embeddings in sync when content changes
4. Handle failures and retries in the embedding generation process

While Postgres full-text search can handle this internally through synchronous calls to to_tsvector and triggers, semantic search requires asynchronous API calls to a provider like OpenAI to generate vector embeddings. This guide demonstrates how to use triggers, queues, and Supabase Edge Functions to bridge this gap.

Understanding the architecture#

We'll leverage the following Postgres and Supabase features to create the automated embedding system:

1. pgvector: Stores and queries vector embeddings
2. pgmq: Queues embedding generation requests for processing and retries
3. pg_net: Handles asynchronous HTTP requests to Edge Functions directly from Postgres
4. pg_cron: Automatically processes and retries embedding generations
5. Triggers: Detects content changes and enqueues embedding generation requests
6. Edge Functions: Generates embeddings via an API like OpenAI (customizable)

We'll design the system to:

1. Be generic, so that it can be used with any table and content. This allows you to configure embeddings in multiple places, each with the ability to customize the input used for embedding generation. These will all use the same queue infrastructure and Edge Function to generate the embeddings.

2. Handle failures gracefully, by retrying failed jobs and providing detailed information about the status of each job.

Implementation#

We'll start by setting up the infrastructure needed to queue and process embedding generation requests. Then we'll create an example table with triggers to enqueue these embedding requests whenever content is inserted or updated.

Step 1: Enable extensions#

First, let's enable the required extensions:

Step 2: Create utility functions#

Before we set up our embedding logic, we need to create some utility functions:

Here we create:

• A schema util to store utility functions.
• A function to retrieve the Supabase project URL from Vault. We'll add this secret next.
• A generic function to invoke any Edge Function with a given name and request body.
• A generic trigger function to clear a column on update. This function accepts the column name as an argument and sets it to NULL in the NEW record. We'll explain how to use this function later.

Every project has a unique API URL that is required to invoke Edge Functions. Let's go ahead and add the project URL secret to Vault depending on your environment.

When working with a local Supabase stack, add the following to your supabase/seed.sql file:

When deploying to the cloud platform, open the SQL editor and run the following, replacing <project-url> with your project's API URL:

Step 3: Create queue and triggers#

Our goal is to automatically generate embeddings whenever content is inserted or updated within a table. We can use triggers and queues to achieve this. Our approach is to automatically queue embedding jobs whenever records are inserted or updated in a table, then process them asynchronously using a cron job. If a job fails, it will remain in the queue and be retried in the next scheduled task.

First we create a pgmq queue for processing embedding requests:

Next we create a trigger function to queue embedding jobs. We'll use this function to handle both insert and update events:

Our util.queue_embeddings trigger function is generic and can be used with any table and content function. It accepts two arguments:

1. content_function: The name of a function that returns the text content to be embedded. The function should accept a single row as input and return text (see the embedding_input example).

   This allows you to customize the text input passed to the embedding model - for example, you could concatenate multiple columns together like title and content and use the result as input.

2. embedding_column: The name of the destination column where the embedding will be stored.

Note that the util.queue_embeddings trigger function requires a for each row clause to work correctly. See Usage for an example of how to use this trigger function with your table.

Next we'll create a function to process the embedding jobs. This function will read jobs from the queue, group them into batches, and invoke the Edge Function to generate embeddings. We'll use pg_cron to schedule this function to run every 10 seconds.

Let's discuss some common questions about this approach:

Why not generate all embeddings in a single Edge Function request?#

While this is possible, it can lead to long processing times and potential timeouts. Batching allows us to process multiple embeddings concurrently and handle failures more effectively.

Why not one request per row?#

This approach can lead to API rate limiting and performance issues. Batching provides a balance between efficiency and reliability.

Why queue requests instead of processing them immediately?#

Queuing allows us to handle failures gracefully, retry requests, and manage concurrency more effectively. Specifically we are using pgmq's visibility timeouts to ensure that failed requests are retried.

How do visibility timeouts work?#

Every time we read a message from the queue, we set a visibility timeout which tells pgmq to hide the message from other readers for a certain period. If the Edge Function fails to process the message within this period, the message becomes visible again and will be retried by the next scheduled task.

How do we handle retries?#

We use pg_cron to schedule a task that reads messages from the queue and processes them. If the Edge Function fails to process a message, it becomes visible again after a timeout and can be retried by the next scheduled task.

Is 10 seconds a good interval for processing?#

This interval is a good starting point, but you may need to adjust it based on your workload and the time it takes to generate embeddings. You can adjust the batch_size, max_requests, and timeout_milliseconds parameters to optimize performance.

Step 4: Create the Edge Function#

Finally we'll create the Edge Function to generate embeddings. We'll use OpenAI's API in this example, but you can replace it with any other embedding generation service.

Use the Supabase CLI to create a new Edge Function:

This will create a new directory supabase/functions/embed with an index.ts file. Replace the contents of this file with the following:

supabase/functions/embed/index.ts:

The Edge Function listens for incoming HTTP requests from pg_net and processes each embedding job. It is a generic worker that can handle embedding jobs for any table and column. It uses OpenAI's API to generate embeddings and updates the corresponding row in the database. It also deletes the job from the queue once it has been processed.

The function is designed to process multiple jobs independently. If one job fails, it will not affect the processing of other jobs. The function returns a 200 OK response with a list of completed and failed jobs. We can use this information to diagnose failed jobs. See Troubleshooting for more details.

You will need to set the OPENAI_API_KEY environment variable to authenticate with OpenAI. When running the Edge Function locally, you can add it to a .env file:

.env:

When you're ready to deploy the Edge Function, set can set the environment variable using the Supabase CLI:

or

Alternatively, you can replace the generateEmbedding function with your own embedding generation logic.

See Deploy to Production for more information on how to deploy the Edge Function.

Usage#

Now that the infrastructure is in place, let's go through an example of how to use this system to automatically generate embeddings for a table of documents. You can use this approach with multiple tables and customize the input for each embedding generation as needed.

1. Create table to store documents with embeddings#

We'll set up a new documents table that will store our content and embeddings:

Our documents table stores the title and content of each document along with its vector embedding. We use a halfvec column to store the embeddings, which is a pgvector data type that stores float values in half precision (16 bits) to save space.

We use an HNSW index on the vector column. Note that we are choosing halfvec_cosine_ops as the index method, which means our future queries will need to use cosine distance (<=>) to find similar embeddings. Also note that HNSW indexes support a maximum of 4000 dimensions for halfvec vectors, so keep this in mind when choosing an embedding model. If your model generates embeddings with more than 4000 dimensions, you will need to reduce the dimensionality before indexing them. See Matryoshka embeddings for a potential solution to shortening dimensions.

Also note that the table must have a primary key column named id for our triggers to work correctly with the util.queue_embeddings function and for our Edge Function to update the correct row.

2. Create triggers to enqueue embedding jobs#

Now we'll set up the triggers to enqueue embedding jobs whenever content is inserted or updated:

We create 2 triggers:

1. embed_documents_on_insert: Enqueues embedding jobs whenever new rows are inserted into the documents table.

2. embed_documents_on_update: Enqueues embedding jobs whenever the title or content columns are updated in the documents table.

Both of these triggers use the same util.queue_embeddings function that will queue the embedding jobs for processing. They accept 2 arguments:

1. embedding_input: The name of the function that generates the input for embedding generation. This function allows you to customize the text input passed to the embedding model (e.g. concatenating the title and content). The function should accept a single row as input and return text.

2. embedding: The name of the destination column where the embedding will be stored.

Note that the update trigger only fires when the title or content columns are updated. This is to avoid unnecessary updates to the embedding column when other columns are updated. Make sure that these columns match the columns used in the embedding_input function.

(Optional) Clearing embeddings on update#

Note that our trigger will enqueue new embedding jobs when content is updated, but it will not clear any existing embeddings. This means that an embedding can be temporarily out of sync with the content until the new embedding is generated and updated.

If it is more important to have accurate embeddings than any embedding, you can add another trigger to clear the existing embedding until the new one is generated:

util.clear_column is a generic trigger function we created earlier that can be used to clear any column in a table.

• It accepts the column name as an argument. This column must be nullable.
• It requires a before trigger with a for each row clause.
• It requires the hstore extension we created earlier.

This example will clear the embedding column whenever the title or content columns are updated (note the of title, content clause). This ensures that the embedding is always in sync with the title and content, but it will result in temporary gaps in search results until the new embedding is generated.

We intentionally use a before trigger because it allows us to modify the record before it's written to disk, avoiding an extra update statement that would be needed with an after trigger.

3. Insert and update documents#

Let's insert a new document and update its content to see the embedding generation in action:

You should observe that the embedding column is initially null after inserting the document. This is because the embedding generation is asynchronous and will be processed by the Edge Function in the next scheduled task.

Wait up to 10 seconds for the next task to run, then check the embedding column again:

You should see the generated embedding for the document.

Next let's update the content of the document:

You should observe that the embedding column is reset to null after updating the content. This is because of the trigger we added to clear existing embeddings whenever the content is updated. The embedding will be regenerated by the Edge Function in the next scheduled task.

Wait up to 10 seconds for the next task to run, then check the embedding column again:

You should see the updated embedding for the document.

Finally we'll update the title of the document:

You should observe that the embedding column is once again reset to null after updating the title. This is because the trigger we added to clear existing embeddings fires when either the content or title columns are updated. The embedding will be regenerated by the Edge Function in the next scheduled task.

Wait up to 10 seconds for the next task to run, then check the embedding column again:

You should see the updated embedding for the document.

Troubleshooting#

The embed Edge Function processes a batch of embedding jobs and returns a 200 OK response with a list of completed and failed jobs in the body. For example:

It also returns the number of completed and failed jobs in the response headers. For example:

You can also use the X-Deno-Execution-Id header to trace the execution of the Edge Function within the dashboard logs.

Each failed job includes an error field with a description of the failure. Reasons for a job failing could include:

• An error generating the embedding via external API
• An error connecting to the database
• The edge function being terminated (e.g. due to a wall clock limit)
• Any other error thrown during processing

pg_net stores HTTP responses in the net._http_response table, which can be queried to diagnose issues with the embedding generation process.

Conclusion#

Automating embedding generation and updates in Postgres allow you to build powerful semantic search capabilities without the complexity of managing embeddings manually.

By combining Postgres features like triggers, queues, and other extensions with Supabase Edge Functions, we can create a robust system that handles embedding generation asynchronously and retries failed jobs automatically.

This system can be customized to work with any content and embedding generation service, providing a flexible and scalable solution for semantic search in Postgres.

See also#

• What are embeddings?
• Semantic search
• Vector indexes
• Supabase Edge Functions