Anyone building semantic search, recommendations or retrieval-augmented generation needs a place for embeddings — numeric vectors that capture the meaning of text or images. The choice usually comes down to two paths: the pgvector extension in an existing PostgreSQL database, or a specialised service built only for vectors. For many SaaS products the right answer is less spectacular than marketing material suggests.
What pgvector is
pgvector adds a vector data type to PostgreSQL along with operators for similarity search, such as cosine distance. Vectors live in the same table as the rest of a record's data. For fast search over larger data sets the extension offers approximate indexes, including HNSW, which balances search speed and result quality well. Platforms such as Supabase provide pgvector without additional infrastructure.
The biggest advantage: everything in one place
In a SaaS product, vector search is almost never pure similarity search. It has to be filtered: only this tenant's documents, only content the signed-in user may see, only entries of a certain category or period. In PostgreSQL that is an ordinary query with conditions, and row-level security applies to vectors exactly as it does to all other data. The tenant isolation you already built automatically protects semantic search too.
Then there is consistency. When a document is deleted or changed, its vector disappears or changes in the same transaction. With a separate vector database this synchronisation has to be built and monitored — and a missed deletion means deleted content keeps appearing in search results or AI answers. For GDPR access and erasure requests that is not a detail.
Where pgvector reaches its limits
Approximate indexes need memory, and building them takes time on large data sets. Very large vector collections with high query load compete with the rest of the database for resources. Combining strict filters with an approximate index can reduce result quality when the index searches by similarity first and the filter then discards many hits; newer versions of the extension improve this, but it remains something to test.
Dedicated vector databases are built for exactly these loads: distributed indexes, filters integrated into the search, and scaling independent of the main database. They pay off when vector search is the core of the product, when data volumes go far beyond what a single database instance handles well, or when search load noticeably affects other operations.
The questions that decide
First: how many vectors will there realistically be in two years — not in the most optimistic scenario? Second: how strict and varied are the filters? Third: how important is consistency with the rest of the data, for deletions and permissions? Fourth: who operates the system, and how much additional infrastructure can the team take responsibility for? For most B2B SaaS products with tenant-specific document collections, the answers point to PostgreSQL.
Working with pgvector in practice
A few points make the difference. Vector dimensions depend on the embedding model and should not be mixed with old vectors after a model change; a column for the model version makes migration easier. The HNSW index has parameters that trade search speed against result quality, and they should be tuned with real queries and a small evaluation set rather than by feel. For very selective filters, such as the documents of a single small tenant, an exact search without an index is sometimes faster and more precise.
Hybrid search also helps: vector search combined with the full-text search PostgreSQL already provides. Especially with German texts containing compound words, product names or article numbers, full-text search finds matches that pure semantic search misses.
Keeping migration open
Starting with pgvector is not a lifelong commitment. If the search logic sits behind a clear interface in your own code, a dedicated vector database can be added later without rebuilding the product. The reverse path is possible too, but rarely needed when planning was realistic from the start.
Our recommendation
For SaaS products whose vector search covers documents, tickets or knowledge bases of individual tenants, pgvector in PostgreSQL is usually the better choice: less infrastructure, permissions and consistency without extra effort, and a main database the team already knows. A dedicated vector database is right when measurements show that load or data volume genuinely overwhelms the database. Innopulse runs Supabase with pgvector in its own products and helps teams make this decision based on measurements rather than assumptions.