Customer-owned face search with Supabase pgvector
Use this pattern when you want scalable face search, but you do not want deepface.dev to host your face database. The flow is:- Send an image to
POST /represent. - Store the returned embedding in your own Supabase
pgvectortable. - For a new query image, call
POST /representagain. - Search your own Supabase table for the closest embeddings.
How this relates to DeepFace register and search
Open-Source DeepFace now includes database-backedregister, search, and
build_index functions for stateless face recognition pipelines. In that model,
register stores embeddings in a backend database and search queries that
database.
deepface.dev does not expose hosted /register or /search endpoints today.
Instead, use POST /represent for the compute step and keep registration,
storage, indexing, and search in your own database.
References:
- Sefik’s write-up on DeepFace register, search, and build_index
- Open-Source DeepFace database-backed search in the README
Create the Supabase table
This example usesFacenet, which returns 128-dimensional embeddings. If you
choose another model, confirm its embedding length and change vector(128) to
match.
Query nearest faces
Use cosine distance (<=>) to match deepface.dev’s default cosine comparison
metric. Smaller distances are closer matches.
Create a database function so Postgres can order by vector distance directly:
JavaScript example
Install the Supabase client in your backend project:When to use this pattern
Use customer-owned search when you need:- face search across many enrolled identities;
- control over where biometric data and metadata are stored;
- your own RLS, audit, retention, and deletion rules;
- database-level ANN search as your dataset grows.
POST /compare can still compare one image
or vector against vectors you include in the request. For larger datasets, keep
the database search in Supabase and use deepface.dev only for embedding
generation.