Vector databases.

Where Vector databases fits on a long engagement.

The first question is usually whether a dedicated vector database is needed at all. Postgres with pgvector handles millions of vectors comfortably, and keeping vectors beside the relational data removes a system, a synchronisation path and a consistency problem. Dedicated databases earn their place at larger scale or under specific latency requirements.

Metadata filtering is where implementations differ most and where requirements are usually discovered late. Restricting a similarity search to one tenant, one date range or one document type is a common need, and systems handle it with very different efficiency — pre-filtering, post-filtering and hybrid approaches all have sharply different performance profiles.

What an assigned team does with Vector databases.

Pure vector search is frequently worse than a hybrid of vector and keyword search. Exact terms — product codes, names, identifiers — are precisely what embeddings handle poorly, and they are often what users search for.

Combining both is usually the largest single improvement available to a retrieval system, and it is the kind of judgement scoped under managed ai services.

What we use Vector databases for.

• Starting in the database you already run pgvector where volumes allow, avoiding a second system and its sync path.
• Filtered similarity search Tenant and date restrictions applied efficiently rather than bolted on after retrieval.
• Hybrid keyword and vector retrieval Exact terms handled by keyword search, which embeddings are poor at.

How Vector databases capacity is assigned.

Retrieval infrastructure is assigned inside AI capacity, starting from whether an additional system is genuinely required.