Does pgvector generate the embeddings?

No. It stores vectors and finds the nearest ones. You compute the vectors yourself with a model or an external service, both for the elements and for each query.

Does pgvector do hybrid search?

Not on its own. Its documentation states that it is used together with Postgres full-text search, and the results are merged in your query or in your application.

Can I start with XEYE and move to pgvector later?

Yes. What you load into XEYE are texts with a description and some parameters, which you still have at your source. You would have to compute the embeddings again with the model you choose.

XEYE vs pgvector: which one to choose

pgvector is a PostgreSQL extension that stores vectors and finds the nearest ones. It does not generate embeddings or combine signals: you code that yourself. If your data is already in Postgres and you have a developer to write that pipeline, pgvector is probably a better option than any external API. XEYE fits when there is no Postgres, or when you do not want to build or maintain that piece.

Updated on October 5, 2026By Joan Martorell

How do they differ?

	XEYE	pgvector
What it is	Hosted hybrid search API.	PostgreSQL extension for vector similarity search.
Embeddings	XEYE computes them when the list is trained and on every query.	You generate them yourself, with the model or service you choose, for each element and for each query.
Hybrid search	On every query, with nothing to configure.	You write it yourself, combining pgvector with Postgres text search or with `pg_trgm`.
Indexes	Managed by the service.	HNSW and IVFFlat, plus exact search without an index.
Where the data lives	In the service. It is loaded from the console.	In your database: no syncing, with transactions, joins and SQL filters.
Filters	No.	Yes, with SQL.
Price	€0.001 per search, no monthly fee.	Free and open source. You pay for your database and for generating the embeddings.
Operations	None.	Whatever your Postgres needs. It is available on Supabase, Neon, Amazon RDS, Cloud SQL and Azure.

pgvector data checked in its repository on 5 October 2026.

When is pgvector the better choice?

You already use PostgreSQL and the data lives there: there is nothing to sync.
You want full control of the model, the ranking and where the data lives.
You have a developer who is comfortable writing the embedding pipeline and the hybrid query in SQL.
You do not want a per-search cost or to depend on another provider.

When does XEYE fit?

You have no Postgres, or no backend developer: a no-code shop, a static site or an FAQ section.
You do not want to choose a model, recompute embeddings when an element changes or tune the mix of fuzzy and semantic matching.
The volume is small enough for pay per use to cost less than the engineering time.

What do I have to build with pgvector?

The search itself is a short query. This one returns the ten elements nearest to a vector:

sql

-- The ten elements closest in meaning to the query.
-- $1 is the query embedding: you compute it with the same model as the catalogue.
SELECT id, text, 1 - (embedding <=> $1) AS similarity
FROM elements
ORDER BY embedding <=> $1
LIMIT 10;

What surrounds that query is the real work:

Choose an embedding model and where to run it: a pay-per-use service or your own model.
Compute the vector of each element and recompute it when its text changes.
Compute the vector of each query with the same model, before running the SQL.
Add the text part: full-text search or pg_trgm for typos, and a way to merge the two results.
Tune and monitor the indexes as the data grows.

None of these steps is hard for an experienced team, and the result is yours. For a team without that experience, it is one more piece to maintain.

What is XEYE missing?

Your data has to be copied to the service and kept up to date by hand. There are no filters or joins with the rest of your tables, you do not choose the ranking formula and there is no service level agreement. If your data is already in Postgres, that copy is exactly what pgvector saves you.

Sources

pgvector repository: types, indexes, operators and hybrid search.
pg_trgm module, in the PostgreSQL documentation.

Frequently asked questions

Does pgvector generate the embeddings?: No. It stores vectors and finds the nearest ones. You compute the vectors yourself with a model or an external service, both for the elements and for each query.
Does pgvector do hybrid search?: Not on its own. Its documentation states that it is used together with Postgres full-text search, and the results are merged in your query or in your application.
Can I start with XEYE and move to pgvector later?: Yes. What you load into XEYE are texts with a description and some parameters, which you still have at your source. You would have to compute the embeddings again with the model you choose.

Try it with your own data

Create an account, upload a list and run your first search in about five minutes. You start with €5 of credit, no card required.

Create a free account Read the documentation