Vector Databases and Graph Databases Explained, and Who Actually Sells Them

A vector database finds information by meaning rather than by keyword. A graph database finds information by relationship rather than by table. Both have existed for years as specialist tools, and both have suddenly become mainstream purchases because AI agents need them — one to ground answers in your own documents, the other to follow the connections between facts. If a vendor has recently pitched you "RAG", "GraphRAG" or "agent memory", they were selling one or both of these things. This guide explains what each database actually does, why agents changed the market, who the vendors are, and — the question most pitches skip — whether the database you already run does enough.

Every vendor detail below was checked against the vendor's own site on 6 August 2026, and every price is in US dollars as published. None of the vendors named here publishes sterling pricing.

What a vector database actually does

A vector database stores the meaning of your content as coordinates, so that a search can find things that mean the same as the query even when they share no words with it. The mechanism is the embedding. An embedding model — a small sibling of the large language models everyone now uses — reads a passage of text and converts it into a long list of numbers, typically several hundred to a few thousand of them. That list is a point in a high-dimensional space, and the model is trained so that passages with similar meaning land near each other. "The courier turned up two days late" and "customers angry about delivery delays" share no significant words, but their embeddings sit close together, because the model has learned that they are about the same thing.

Store an embedding for every paragraph of every document you care about and searching becomes geometry. Embed the question, then find the stored points nearest to it. That nearest-neighbour search is what a vector database is built to do quickly at scale — millions or billions of points, answers in milliseconds — usually alongside conventional filters ("only documents from the HR folder, only from 2025").

One concrete example carries the whole idea. A mid-market insurer has 40,000 policy documents, claim notes and complaint letters. An employee asks the company chatbot "can we pay out on a trampoline injury at a rented property?". Keyword search finds documents containing "trampoline", most of them irrelevant. A vector search finds the passages about liability for injuries sustained on equipment at tenanted premises — including ones that never use the word trampoline — because those passages sit near the question in meaning-space.

That retrieval step is what makes retrieval-augmented generation, or RAG, work. A language model on its own answers from its training data, which does not include your policies, your contracts or your prices, and it will fill gaps fluently and wrongly. RAG bolts a retrieval step on the front: embed the question, fetch the most relevant passages from your own content, hand those passages to the model, and instruct it to answer only from them, citing what it used. The model stops being an oracle and becomes a well-read assistant with your filing cabinet open in front of it. The retrieval layer also inherits your access-control problem — a chatbot that retrieves from everything will happily surface documents the asker should never see, the same failure mode we covered for Copilot surfacing confidential files in a Microsoft 365 tenant.

What a graph database actually does

A graph database stores entities and the relationships between them as first-class records, so that questions about connection — what links X to Y, what depends on what, who controls whom — can be answered by walking the connections directly. In a relational database, relationships are implicit: they exist only when a query joins one table to another through matching keys. In a graph database, the relationship is itself a stored object with a type and properties. "Company A supplies Component B", "Company A is owned by Holding C", "Director D sits on the board of Company A" are edges you can traverse, not joins you must reconstruct.

The difference shows up the moment a question spans more than a hop or two. Take a supply-chain question a procurement director might actually ask: "which of our products contain a component from any supplier ultimately owned by a sanctioned entity?" In SQL that is a join from products to components to suppliers to ownership records — and because "ultimately owned" can be two, three or six layers of holding company deep, the query needs recursive joins of unknown depth, which is exactly what SQL is worst at. Each additional hop multiplies the work. In a graph database the same question is a traversal: start at the sanctioned entity, walk ownership edges downward, walk supply edges to components, walk into products. The database follows pointers rather than scanning and matching tables, so query time grows with the size of the answer, not the size of the data. Fraud-ring detection, corporate ownership mapping, network dependency analysis and customer-360 views are all this same shape of question, which is why they have long been the classic graph workloads.

Graph databases have their own query languages built around patterns rather than joins — Cypher, popularised by Neo4j and now an ISO standard influence via GQL, is the most widely used — and the good ones make a three-hop traversal a single readable line.

Why AI agents took both from niche to mainstream

Three things happened between 2023 and 2026, and each one turned a specialist database category into a line item on ordinary IT budgets.

RAG became the default way to make AI useful on private data. Fine-tuning a model on your documents is expensive, slow to update and hard to audit. Retrieval is cheap, current and citable. So almost every serious "chat with our documents" or internal-copilot project now embeds the corpus and stores the result in something that can do vector search — which instantly created demand for that something. The NCSC's guidance on feeding sensitive business data to AI tools is a sensible companion read before any corpus gets embedded, because an embedded copy of a document is still a copy of the document.

Agents need memory, and memory is a retrieval problem. A chatbot can be stateless; an agent that works for you across days and sessions cannot. It has to remember what it was told in March when it acts in August — user preferences, decisions taken, work completed, facts corrected. The context window of a model is not memory: it is expensive, it is finite, and it empties. So agent memory is implemented as storage plus retrieval — write down what mattered, fetch what is relevant right now — and the store underneath is a vector database, a graph database, or increasingly both. Amazon's own positioning for S3 Vectors leads with exactly this use case, describing low-cost vector storage as the way agents retain context "so agents won't be forced to forget valuable context" (AWS, S3 Vectors product page, checked 6 August 2026).

GraphRAG made the graph relevant to retrieval. Plain RAG has a known failure mode: similarity search finds passages that sound like the question, not passages connected to the answer. Ask "what would losing supplier X mean for our top product line?" and no single paragraph in the corpus resembles that question — the answer lives in the relationships between a dozen documents. Graph-based retrieval fixes this by extracting entities and relationships from the corpus first, then answering by traversing them. Microsoft Research open-sourced its GraphRAG project on 2 July 2024, describing it as a modular graph-based RAG system that uses a language model to build a knowledge graph from a corpus and then answers broad, multi-document questions that defeat similarity search alone (Microsoft Research blog, July 2024; the GitHub repository remains active as of August 2026). The idea spread fast. Neo4j now ships a first-party neo4j-graphrag Python package with a long-term maintenance commitment (Neo4j documentation, checked 6 August 2026), and AWS offers managed GraphRAG through Amazon Bedrock Knowledge Bases backed by Neptune Analytics (AWS Neptune pages, checked 6 August 2026). The one-sentence version worth remembering in vendor meetings: similarity search finds things that sound like the question; graph traversal finds things connected to the answer.

The dedicated vector database vendors

Five names dominate the dedicated category. All five are real, independent and active as of 6 August 2026; the market's reputation for monthly upheaval is deserved, so treat region lists and prices as current-at-time-of-writing.

Pinecone is the name most buyers hear first. It is proprietary and cloud-only (with a bring-your-own-cloud option for regulated environments), and its pricing is usage-based above a monthly minimum: the Standard plan carries a $50 monthly minimum with storage at $0.33 per GB per month and reads and writes metered per million units, while the newer Builder tier is a flat $20 a month (Pinecone pricing page, 6 August 2026). Pinecone opened its AWS Frankfurt region on 5 May 2026, joining Ireland as its second European location — the same announcement introduced its Nexus "knowledge engine" and claimed more than 9,000 customers (Pinecone press release, May 2026). There is no UK region on its list.

Weaviate is open source under a BSD-3 licence with a managed Weaviate Cloud offering: a free tier capped at 100,000 objects, a pay-as-you-go Flex plan from $45 a month, and a prepaid Premium plan from $400 a month with dedicated deployment on AWS, Google Cloud and Azure (Weaviate pricing page, 6 August 2026).

Qdrant is open source under Apache 2.0, written in Rust, with a managed cloud offering a permanent free 1 GB cluster and usage-based paid tiers. Its most distinctive option for UK buyers with residency requirements is Hybrid Cloud, where Qdrant manages clusters that run on your own infrastructure, so the data never leaves your network (Qdrant documentation, 6 August 2026).

Milvus is the open-source heavyweight of the category — an Apache 2.0 project hosted by the LF AI & Data Foundation with Zilliz as its major contributor (Milvus GitHub, 6 August 2026). Zilliz Cloud is the managed offering: a free tier with 5 GB of storage, serverless plans in AWS Frankfurt and Ireland within Europe, and dedicated clusters — from $197 a month on the Enterprise plan — available in AWS London (Zilliz pricing and region documentation, 6 August 2026). That makes Zilliz one of the few dedicated vector vendors with an actual UK region.

Chroma built its following as the developer-friendly open-source library (Apache 2.0) that ships inside countless RAG tutorials, and now sells Chroma Cloud with purely usage-based pricing: $2.50 per GiB written, $0.33 per GiB per month stored, with a $0-plus-usage Starter plan and a $250-a-month Team plan (Chroma pricing page, 6 August 2026). Its pricing page publishes no region information, which for a UK buyer is itself a data point to raise in any evaluation.

Vector search inside the databases you already run

The most consequential fact in this market is that vector search stopped being a product and became a feature. Every mainstream database has added it, which means many organisations already own a vector database without knowing it.

pgvector is the open-source extension that adds vector types and similarity search to PostgreSQL 13 and later. Its own README states the case that has made it the default answer for moderate workloads: your vectors live "with the rest of your data", with ACID transactions, point-in-time recovery and JOINs included, and it comes preinstalled with many hosted Postgres providers (pgvector GitHub, 6 August 2026). If your estate already includes Postgres — and most estates do — pgvector is a migration of zero new systems.

MongoDB offers Vector Search across its platform, and as of its current release notes the capability is generally available in Enterprise Advanced and the free Community Edition as well as in Atlas, whose cloud regions include AWS London (MongoDB product pages and Atlas region list, 6 August 2026). Elastic builds dense and sparse vector search plus hybrid ranking into Elasticsearch, and Elastic Cloud runs in AWS London and Google Cloud London among its regions (Elastic documentation, 6 August 2026). Redis includes vector search in its query engine; Redis 8 returned the core project to an open-source licence, AGPLv3, in May 2025 (Redis blog, May 2025), and Redis Cloud is available in AWS London and Google Cloud London (Redis Cloud region list, 6 August 2026).

The hyperscalers all sell a managed option. Azure AI Search — Microsoft's retrieval service combining keyword, vector and semantic ranking — is available in UK South (Microsoft region support documentation, 6 August 2026). Vertex AI Vector Search is available in Google Cloud's London region, europe-west2 (Google Cloud locations documentation, 6 August 2026). The newest and most price-disruptive entry is Amazon S3 Vectors, which AWS describes as the first cloud object store with native vector support. It reached general availability in December 2025 in 14 regions including London, holds up to 2 billion vectors per index and 10,000 indexes per bucket, serves warm queries at around 100 milliseconds, and — the claim doing the commercial damage — cuts the total cost of uploading, storing and querying vectors by up to 90 per cent compared with conventional approaches (AWS announcement and product page, December 2025, checked 6 August 2026). AWS is explicit that S3 Vectors targets large, infrequently queried vector sets while OpenSearch remains its answer for high-throughput low-latency search.

The strategic point for buyers is what this does to managed RAG entry costs. Amazon Bedrock Knowledge Bases — AWS's managed RAG service — lets you choose your vector store from S3 Vectors, OpenSearch Serverless, Aurora PostgreSQL with pgvector, Pinecone, Redis, MongoDB Atlas, or Neptune Analytics for GraphRAG (AWS documentation, checked 6 August 2026). When the cheapest slot in that list is object storage priced like object storage, the floor price of "RAG done properly" drops for everyone, and the dedicated vendors feel it.

The graph database vendors

Neo4j remains the category's reference point. The Community Edition is open source under GPLv3; the Enterprise Edition is commercial (Neo4j GitHub, 6 August 2026). Its managed service, AuraDB, prices by memory: a free tier, Professional at $65 per GB per month from a 1 GB instance, and Business Critical at $146 per GB per month with a 99.95 per cent uptime SLA, all deployable in AWS London among other regions (Neo4j pricing and Aura region documentation, 6 August 2026). On the AI side Neo4j maintains the first-party neo4j-graphrag Python package as its supported route for building GraphRAG pipelines against the database (Neo4j documentation, 6 August 2026).

Amazon Neptune is AWS's managed graph database, with a serverless option that scales capacity automatically and is billed per second. Neptune Database runs in AWS London, and Neptune Analytics — the in-memory engine that adds graph algorithms and vector search for exactly the GraphRAG workload — has been available in the London region since 14 March 2024, with a further seven regions added in early 2026 (AWS documentation and announcements, checked 6 August 2026). Neptune's headline AI feature is fully managed GraphRAG through Bedrock Knowledge Bases: AWS builds the graph and runs the retrieval, which is the lowest-effort route into graph-based retrieval for an organisation already on AWS.

Memgraph is an in-memory, Cypher-compatible graph database pitched squarely at AI context: its homepage leads with GraphRAG, agent memory and agent reasoning, and its free Community Edition now includes vector search alongside the graph engine, so one system can do both retrieval styles. Enterprise pricing scales with memory capacity, and Memgraph Cloud offers managed instances from 1 GB to 32 GB of RAM across six AWS regions (Memgraph pricing page, 6 August 2026).

ArangoDB — in the middle of rebranding as Arango, on the arango.ai domain, around what it calls its Contextual Data Platform 4.0 — is the multi-model option: documents and graphs in one engine with one query language. Licensing changed with version 3.12: the source moved from Apache 2.0 to the source-available BSL 1.1, converting to Apache 2.0 after four years, a change the company says targets rival managed services rather than ordinary production users (Arango licensing blog, updated March 2025). Its managed service, ArangoGraph, is sold directly and through the AWS Marketplace (checked 6 August 2026).

TigerGraph is proprietary and has repositioned around "relationship intelligence" for enterprise AI — fraud, anti-money-laundering, entity resolution and explainable agent decisions in regulated environments — with claims of multi-hop queries across billions of relationships in under 100 milliseconds (TigerGraph site, 6 August 2026). Its managed cloud service is TigerGraph Savanna, documented on AWS (TigerGraph documentation, 6 August 2026).

FalkorDB is the successor lineage of RedisGraph: a graph database that speaks the Redis protocol, licensed under SSPLv1 — source-available rather than OSI-approved open source, a distinction its own licence FAQ addresses (FalkorDB documentation, 6 August 2026). It markets itself directly at GraphRAG and agent memory, with multi-tenancy for thousands of graphs as its differentiator, and offers both a managed cloud and self-hosting.

Agent memory, the layer forming on top

A new product category is condensing one level above the databases: agent memory as a service. Rather than selling you a store, these products sell the whole remembering pipeline — deciding what an agent should retain from each interaction, writing it down, updating it when facts change, and assembling the relevant slice into context when the agent next acts. Three names are verifiably real and active as of 6 August 2026. Zep sells managed "agent memory at enterprise scale" built on Graphiti, its open-source engine for temporal knowledge graphs — graphs whose facts carry validity windows, so the system knows not just that a customer changed plans but when, and what was true before (Zep site and Graphiti GitHub, 6 August 2026). Mem0 offers a drop-in memory API for agents, claims 90,000 developers building on it, and holds SOC 2 Type 1 and HIPAA attestations for its managed platform alongside an open-source core (Mem0 site, 6 August 2026). Letta grew out of the MemGPT research from UC Berkeley — the October 2023 paper that framed a language model's context as an operating system's memory to be paged in and out — and now describes itself as a research lab shipping a self-improving agent whose memory persists and evolves (Letta site, 6 August 2026).

The honest read on the category: it is young, the interfaces are unstandardised, and every product on this list is small relative to the databases underneath it. It is worth knowing the names because they signal where the market is going — memory as infrastructure — not because any of them is yet a default choice.

Do you actually need a dedicated vector database?

This is a live, genuinely contested question, and a buyer should hear both sides as positions rather than facts.

The case against buying one: vector search is now a feature of the database you already run, and for moderate scale that is enough. pgvector's argument — vectors beside your operational data, transactions, joins, one backup regime, no synchronisation between systems (pgvector project documentation) — is echoed by every general-purpose vendor that has added the capability, and MongoDB's marketing makes the same "avoid the synchronisation tax" argument almost word for word (MongoDB Vector Search page, 6 August 2026). For a corpus in the tens or hundreds of thousands of documents — which describes most mid-market RAG projects — Postgres with pgvector on infrastructure you already operate is frequently the honest answer, and it is the answer several of AWS's own Bedrock vector-store options quietly endorse.

The case for buying one: at genuinely large scale — hundreds of millions to billions of vectors, high query rates, low latency targets — purpose-built engines have the architectural headroom, and the dedicated vendors compete on exactly that: Pinecone on its serverless scale and enterprise features, Milvus and Zilliz on open-source scale-out, Qdrant on performance-per-pound of its Rust engine. Those claims are vendor claims, but the workloads they describe are real.

Cost is where buyers should press hardest, because the dedicated tier's usage-based pricing has a documented unpredictability problem. Actian — a database vendor with its own competing product, so read it as a disclosed rival's analysis — published a detailed critique in February 2026 arguing that vector database bills surprise teams for structural reasons: minimum-spend floors introduced across the market during 2025 turned tiny steady workloads into step-change costs, ancillary fees for embedding, re-indexing, backups and egress can roughly double a production bill, and per-query costs scale with index size, so the same search costs more every month as data grows (Actian blog, 13 February 2026). Its estimate that self-hosting becomes 50 to 75 per cent cheaper at 60 to 100 million queries a month is its own modelling, but the underlying pattern — usage-priced retrieval infrastructure resists forecasting — matches the minimums now visible on the vendors' own pricing pages quoted above. If your finance director requires a predictable number, that is an argument for memory-priced services such as AuraDB, for flat tiers, for self-hosted open-source deployment, or for the database you already pay for.

The questions that decide it

No verdicts — the right choice is set by your requirements, and four questions surface them.

What scale do you honestly need? Count the documents you will actually embed, multiply by chunks per document, and compare the result with what you already run. A million vectors is comfortable pgvector territory; a billion is not. Buy for the corpus you have plus a realistic growth rate, not for the vendor's benchmark.

What latency do you honestly need? An internal knowledge assistant that answers in two seconds does not need the infrastructure of a consumer product answering in fifty milliseconds. Latency targets drive cost more than any other requirement; set them from the user experience backwards.

Where must the data live? An embedded corpus is personal data if the source documents were, and your Article 30 records need to say where it is. UK hosting is available today from Zilliz (dedicated), Neo4j Aura, Neptune and Neptune Analytics, S3 Vectors, Azure AI Search, Vertex AI Vector Search, MongoDB Atlas, Elastic Cloud and Redis Cloud; Pinecone offers EU regions but no UK one, and Qdrant's answer for strict residency is running its managed clusters on your own infrastructure. Given that two-thirds of UK IT leaders say they would switch providers to regain sovereignty, asking the region question first saves an awkward retrofit, and the general rules for where cloud-held data may lawfully live apply to vectors exactly as they do to files.

Does the database you already run do enough? Prove that it does not before buying anything. A one-week spike on pgvector, or on the vector features of whatever you already licence, is the cheapest procurement filter in this market — and if it fails, you will have learned the scale and latency numbers that make the vendor conversations concrete. Whatever you choose, write the retrieval layer into your AI governance policy, because it decides what your agents can see, remember and repeat.

Sources

This article draws on vendor documentation and pricing pages checked on 6 August 2026, including those of Pinecone, Weaviate, Qdrant, Milvus and Zilliz, Chroma, Neo4j, Memgraph, Arango, TigerGraph, FalkorDB, Zep, Mem0 and Letta; AWS announcements and documentation for S3 Vectors, Amazon Neptune, Neptune Analytics and Bedrock Knowledge Bases; Microsoft documentation for Azure AI Search region support and the Microsoft Research announcement of the GraphRAG open-source release (July 2024); Google Cloud location documentation for Vertex AI Vector Search; the pgvector, Milvus, Chroma, Weaviate, Qdrant, Graphiti and Microsoft GraphRAG open-source repositories; the Redis licensing announcement of May 2025; the Arango licensing statements of 2023 to 2025; and an attributed February 2026 pricing analysis published by Actian, a competing database vendor.