# Vector RAG, graph RAG, SQL and full-text search compared Source: https://docs.littlebigbrain.com/start/database-comparison/ 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](https://sdk.pinecone.io/python/reference/sync-index.html). 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](https://www.elastic.co/docs/reference/elasticsearch/index-settings/similarity). Elasticsearch also supports filters, counts and [hybrid search](https://www.elastic.co/docs/solutions/search/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](https://www.postgresql.org/docs/17/queries-with.html) 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](https://docs.littlebigbrain.com/guides/search-by-meaning/) finds Auth Service from the words the user chose. - **Read the data model.** [MCP tools](https://docs.littlebigbrain.com/sdks/mcp/) 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](https://docs.littlebigbrain.com/guides/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](https://docs.littlebigbrain.com/guides/time-travel-audit/). 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](https://docs.littlebigbrain.com/guides/without-rdf/) 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 ```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 ```json { "triplets": [ { "source": { "type": "Service", "key": "auth-service", "name": "Auth Service" }, "relation": "WRITES_TO", "target": { "type": "Database", "key": "user-db", "name": "User Database" } } ] } ``` ### SPARQL ```sparql PREFIX dr: PREFIX rdfs: 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](https://docs.littlebigbrain.com/start/concepts/#graph-queries-with-sparql). ## Choose your next step - [Quickstart](https://docs.littlebigbrain.com/start/quickstart/): search by meaning, then follow a path, in ten minutes. - [Build with JSON records](https://docs.littlebigbrain.com/guides/without-rdf/): declare types, validate writes and replay a decision. - [Use cases](https://docs.littlebigbrain.com/start/use-cases/): six agent decisions and the query behind each one. - [Core concepts](https://docs.littlebigbrain.com/start/concepts/): the model, mapped from vector stores and graph databases.