Knowledge graph vs vector database: relationships or similarity

Neo4j defines a knowledge graph as an organised representation of real-world entities and their relationships. Nodes hold details about entities such as people, places, objects or institutions, relationships link two nodes and say how they are related, and both can carry properties. An organising principle, a schema or framework, arranges the nodes and relationships; Neo4j calls an ontology one type of organising principle.

Pinecone says a vector database indexes and stores vector embeddings for fast retrieval and similarity search, with create, read, update and delete operations, metadata filtering and horizontal scaling. Weaviate describes it as a data system that stores, indexes and queries vector embeddings and returns the objects whose vectors are closest to a query vector.

The two terms are not the same kind of thing. A knowledge graph is a way of modelling knowledge; a vector database is a category of database product. A knowledge graph usually lives in a graph database, which Weaviate describes as built for querying connections and patterns in data.

A graph query starts from one or more nodes and follows typed relationships, filtering on properties as it goes: start at this supplier, follow OWNED_BY to its parent, then find other suppliers with the same parent. Given the data, the answer is exact, and the path itself explains why each result is there.

A vector query turns the question into an embedding with the same model used for the stored content. Pinecone describes three stages: the database indexes vectors with an algorithm such as PQ, LSH or HNSW, compares the query vector with the indexed vectors to find nearest neighbours, then post-processes and re-ranks. Similarity is measured by cosine similarity, Euclidean distance or dot product, and results can be filtered by metadata.

Vector search is approximate by design. Neo4j’s documentation for its own vector indexes says the k nearest neighbours returned may not be the exact k nearest, only close within the same wider neighbourhood.

A procurement team holds supplier contracts as PDFs and supplier records in a purchasing system. The first question is "Which contracts mention penalties for late delivery?" The contracts word this in many ways, such as liquidated damages for delay or a service credit for a missed date. A vector search over contract chunks finds passages by meaning, where a keyword search would miss most of them.

The second question is "Which suppliers share a parent company with a supplier that failed an audit last year?" The answer depends on links, not wording: supplier to parent, parent to sibling supplier, sibling to audit result. A knowledge graph answers it with one traversal and shows the path. A vector search would return contracts that read similarly, which is not the same as being related.

The third question combines both: penalty clauses, but only in contracts with suppliers connected to that failed audit. The graph narrows the set of suppliers, and vector search ranks the clauses inside their contracts.

The boundary is less sharp in products than in definitions. Neo4j offers vector indexes inside its graph database: they use an HNSW structure, support cosine and Euclidean similarity, and can be combined with full-text search for hybrid search. Neo4j also describes GraphRAG, a technique that grounds language models with knowledge graphs.

Weaviate, a vector database, offers hybrid search that runs dense vector search and sparse BM25F keyword search in parallel and merges the results. So the practical question is often which structure is primary for your data, and which you add alongside it.

Start from the questions people will ask, not from the technology. Write down twenty real questions and mark whether each turns on meaning or on connections.

• Pick a vector database when content is mostly unstructured text or media and the question is "find things like this".
• Pick a knowledge graph when questions follow relationships, need exact answers, or must show how an answer was reached.
• Graph failure: building and keeping the schema and the relationships current is ongoing work, and a missing or stale edge gives a wrong answer without any warning.
• Vector failure: results are approximate and can be similar but wrong, embeddings handle exact identifiers such as part numbers poorly, and the index has no notion of how items relate.

Swfte does not sell a graph database or a vector database. Cortex’s on-device knowledge bases embed your files and store them locally so that Cortex can answer from them, which is the vector side of this page used inside a product rather than sold as a database.

The company brain (Swfte Enterprise Intelligence) is a customer-hosted appliance that holds a time-aware graph of the organisation: people, groups and reporting lines synced read-only from your directory. Search over documents in that appliance, which combines keyword and vector search, is in progress and not yet exposed.

• Swfte Cortex: knowledge bases on the device
• The company brain: what is built today
• Data on the Swfte platform

Facts about other vendors and about the terms on this page were read on the pages below on 7 October 2026. Vendor plans, names and menus change, so check the vendor’s page before you rely on a detail.