Vector RAG, graph RAG, SQL and full-text search compared

Retrieval-augmented generation (RAG) gives a model information to use when it answers. Vector RAG retrieves similar passages. Graph RAG retrieves connected facts and paths. Each is useful for different questions. little big brain runs both, over one copy of your data.

This page compares the approaches on one agent question. Which database does Auth Service write to, and who owns it? The agent must find the service, check two relationships and explain its answer.

What each approach gives an agent

Approach	What it does well	Work left to the agent or application
Vector database	Find text with similar meaning, even in other words	Check which facts are relevant, how they connect and what the search missed.
Full-text search	Find documents with names, codes or phrases	Check whether the matching text answers the question.
Hybrid search	Combine word matching and search by meaning	Connect and verify facts from the returned documents.
Relational database	Query records, join tables and calculate totals	Choose the right tables and joins, and understand what the fields mean.
little big brain	Find records by meaning, then follow their stored links, check rules and read past commits	Declare the types and links, and load the facts and evidence.

What vector search leaves to the agent

Vector search turns text into lists of numbers called embeddings. It compares those numbers to find text with similar meaning. This helps when a question and a document use different words for the same idea.

Filters can narrow a search by stored fields, such as the source or the date. For an example, see Pinecone’s vector search and filtering API.

Take Auth Service. A plan to change its database looks similar to a report of its current setup. The search can return both. It can also leave out the document that names the service’s owner.

The agent must read the passages and search again for the missing facts. More text means more reading, and it does not guarantee that the needed facts are present.

little big brain also runs vector search. An agent can find Auth Service from a vague question.

The next step is different. The database, its owner and the links between them are records. The agent follows the links and gets the exact answer, with no passages to reconcile.

What full-text search leaves to the agent

Best Matching 25 (BM25) ranks documents by the words in a search. It considers how often words appear, how rare they are and how long the document is.

BM25 works well for names, error codes and specific terms. It is also Elasticsearch’s default text similarity. Elasticsearch also supports filters, counts and hybrid search, which combines word matching with vector search.

The agent still has to connect the results. A document can mention Auth Service and User Database. It may not say that one writes to the other.

The owner can appear in another document under another service name. Better search results help the agent find the text. The agent must still check the connections.

In little big brain, the relationships are stored once and reused across questions. An agent follows the links from Auth Service to its database and owner. It can also read the evidence you recorded for each link.

What a relational database leaves to the agent

Relational databases use Structured Query Language (SQL) to query tables. Joins connect records across tables, and recursive queries can follow a chain of records. SQL answers the service question exactly when the agent picks the right tables and joins.

The hard part is the schema, the structure of those tables. Is the owner stored in services, teams or a linking table? Does a status field describe the current state or an old one?

Could a join repeat rows and inflate a count? A query can run without errors and still answer the wrong question.

little big brain gives the agent a schema it can read. The schema lists the types, the links and the fields of each type.

The agent still has to use the right names. The links give it one direct way to connect a service, its database and its owner.

How little big brain helps an agent check its answer

The service question also needs an explanation. What supports the answer, and which data version was used? little big brain gives the agent a tool for each step:

• Find the starting record. Search by meaning finds Auth Service from the words the user chose.
• Read the data model. MCP tools let an agent read the types, links and fields.
• Query the connections. A query matches the service, its database and its owner by their links.
• Apply your rules. Reasoning applies the type hierarchy you declare. For example, an authentication service can count as a service.
• Read the evidence. A link can carry its source, so the agent can cite it.
• Repeat the query on the same data. Each response names its commit. Query that commit again while it is retained.

The database checks links and applies rules. The agent chooses the queries and explains the facts they return. Answer quality depends on the facts, evidence and rules you provide.

If you use a relational database

Records in little big brain are grouped by type, and links connect them. You can write records as JSON. The query language is SPARQL, the standard for graph queries. Build with JSON records shows the whole flow.

You know	In little big brain	What changes
Table	A type	A record can have more than one type.
Row	A record	A record has no fixed row shape. Fields can be missing.
Primary key	The record’s type plus its key	Each record also gets a global name, an IRI. Use the same key across sources for the same thing.
Foreign key and join	A link, and a shared query variable	Links are stored as data. A variable used twice joins the matching facts.
Recursive query	A property path, such as dr:depends_on+	+ follows one or more links of the same kind.
WHERE, GROUP BY, aggregates	SPARQL FILTER, GROUP BY and aggregates	The same ideas, over patterns instead of tables.
Constraints	Declared fields and SHACL shapes	Unknown fields are refused. Shapes add rules across fields and links.
Database	A graph	A graph holds the records and links you query together.

A join, expressed as a link

Suppose a service writes to a database. In SQL, a writes_to table connects two rows. In little big brain, one link connects the two records. The examples ask the same question: which database does Auth Service write to?

SQL

-- services(id, name), databases(id, name), writes_to(service_id, database_id)
SELECT d.name AS database
FROM services s
JOIN writes_to w ON w.service_id = s.id
JOIN databases d ON d.id = w.database_id
WHERE s.name = 'Auth Service';

JSON records

{
  "triplets": [
    {
      "source": { "type": "Service", "key": "auth-service", "name": "Auth Service" },
      "relation": "WRITES_TO",
      "target": { "type": "Database", "key": "user-db", "name": "User Database" }
    }
  ]
}

SPARQL

PREFIX dr: <https://littlebigbrain.com/r/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>

SELECT ?database WHERE {
  ?service rdfs:label "Auth Service" ;
           dr:writes_to ?db .
  ?db rdfs:label ?database .
}

The result is User Database. Variables begin with ?, and a variable used twice must match the same value. A ; starts the next pattern about the same record. The prefix lines shorten long names; see core concepts.

Choose your next step

• Quickstart: search by meaning, then follow a path, in ten minutes.
• Build with JSON records: declare types, validate writes and replay a decision.
• Use cases: six agent decisions and the query behind each one.
• Core concepts: the model, mapped from vector stores and graph databases.