Vector database

Relational databases are designed for equality and range queries, not for "the five records nearest this vector". Running that query on a SQL table means computing a distance against every row, which stops being practical as record counts grow.

Vector databases specialise in exactly this query type. Using approximate nearest-neighbour indexes they return results far faster without scanning every record, at an acceptable loss in precision. KobiGPT uses Qdrant for this layer.

In KobiGPT the vector database does not work alone. Relational data — users, companies, document metadata, authorisation — lives in PostgreSQL; Qdrant holds only vectors and the minimum metadata search requires.

That split is deliberate. Authorisation decisions are made on the relational side and search results are filtered accordingly; a vector database is not an access control system. Mixing the two layers weakens isolation guarantees.

A separate collection is created per company. Isolation is therefore enforced at the collection level rather than through a query filter; one company's vectors are never present in another company's search space.

That is a stronger guarantee than filter-based isolation: a filter can be forgotten, a collection boundary cannot. In multi-tenant systems this design choice structurally lowers the risk of data leakage.

A useful way to evaluate vector-database is to follow one real question from the source document to the final answer. Record which file was selected, what context reached the model, and what a reviewer would need to verify. This turns a definition into an operational check and makes the result comparable across teams.

The same check should include ownership and change management. Decide who updates the relevant documents, how an outdated result is reported, and which access boundary applies. KobiGPT can provide the assistant and the cited document context, but the organisation still owns the source material, permissions, and the decision made from the answer.