Skip to main content
Supabase is an open-source Firebase alternative that provides a PostgreSQL database with pgvector extension for vector similarity search. It offers a powerful and scalable solution for storing and querying vector embeddings. Create a Supabase account and project, then get your connection string from Project Settings > Database. See the docs for details.

Usage

SQL Migrations for TypeScript Implementation

The following SQL migrations are required to enable the vector extension and create the memories table:
Go to Supabase and run the above SQL migrations in the SQL Editor.

Row Level Security

Tables created through the Supabase dashboard have Row Level Security (RLS) enabled by default with no policies attached. With RLS on and no policies, the TypeScript SDK’s queries return zero rows with an HTTP 200 (no error is raised), which looks like an empty memory store rather than a permissions problem. If you use the SQL migrations above (via the SQL Editor), RLS is left in its default off state and this does not apply. If your table has RLS enabled, add policies for the key your app uses (the example below grants full access to the service_role key; scope it down for anon/authenticated keys as needed):

PostgREST Row Limits

Supabase’s PostgREST layer caps the number of rows returned by a single request at db-max-rows (1000 by default), for both .select() queries and RPC function calls like match_vectors. Requesting a topK above this limit for search() or list() will not raise an error, results are capped at db-max-rows instead. The TypeScript list() method paginates internally to work around this, but search() cannot since match_vectors has no offset parameter; it logs a warning when it detects a truncated result. Raise db-max-rows in your Supabase project settings if you need more than 1000 results per search.

Config

Here are the parameters available for configuring Supabase:

Index Methods

The following index methods are supported:
  • auto: Automatically selects the best available index method
  • hnsw: Hierarchical Navigable Small World graph index (faster search, more memory usage)
  • ivfflat: Inverted File Flat index (good balance of speed and memory)

Distance Measures

Available distance measures for similarity search:
  • cosine_distance: Cosine similarity (recommended for most embedding models)
  • l2_distance: Euclidean distance
  • l1_distance: Manhattan distance
  • max_inner_product: Maximum inner product similarity

Best Practices

  1. Index Method Selection:
    • Use hnsw for fastest search performance when memory is not a constraint
    • Use ivfflat for a good balance of search speed and memory usage
    • Use auto if unsure, it will select the best method based on your data
  2. Distance Measure Selection:
    • Use cosine_distance for most embedding models (OpenAI, Hugging Face, etc.)
    • Use max_inner_product if your vectors are normalized
    • Use l2_distance or l1_distance if working with raw feature vectors
  3. Connection String:
    • Always use environment variables for sensitive information in the connection string
    • Format: postgresql://user:password@host:port/database