Vector Database

Classical databases find exact values ("all invoices from supplier X"). Vector databases find similarity ("all text passages that match this question in meaning") — a fundamentally different search operation, optimized for the geometry of embedding number spaces.

In practice, both work together: Structured data (customers, orders, amounts) stays in the classical database; unstructured knowledge (documents, emails, notes) additionally becomes embeddings in the vector database, so AI systems can search it by meaning.

Vector databases exist as cloud services and as self-hosted open-source solutions — the latter appeals to data-sensitive companies because all company knowledge stays within their own infrastructure. Access controls matter here too: not every employee should be able to find everything through the AI assistant.

The market ranges from lightweight open-source solutions to managed cloud services; even established databases (PostgreSQL with vector extensions, for example) now handle vector search. Selection depends on: data volume and search speed, hosting options (EU/on-premise), document-level permission management, and whether existing database expertise can be reused in-house.

For most mid-market projects: the vector database is rarely the critical decision — simple solutions handle millions of document sections without trouble today. What matters more is the ingestion pipeline and synchronisation with source systems, because that's where quality problems happen in practice.

A common misstep is making the tool decision the main project question: weeks evaluating different vector databases while the real success factors — clean document chunking, permission architecture, ongoing synchronisation — go unaddressed. The pragmatic sequence is reversed: start with a solid standard solution, build the pipeline properly, and only switch databases when measurable limits appear — which rarely happens at mid-market volumes.

Alongside pure semantic search, one often-overlooked detail determines quality: the metadata stored with each text segment. This includes source document, department, validity date, confidentiality level, language, or document type. With this information, search can be narrowed purposefully — for example, only in current documents, only in areas a person has access to, or only in a specific category.

This filter-before-search approach solves multiple real-world problems at once. Access control becomes concrete: an employee finds through the assistant only what they have access to anyway, because confidentiality levels constrain the search. Timeliness improves because expired versions can be excluded by date filtering. And precision rises because the system searches the relevant subset, not the entire stock. When setting up a vector database, plan the metadata structure from the start — retrofitting it means reprocessing the entire collection.