Retrieval-Augmented Generation is the job of embedding, indexing, and retrieving private content so a language model can answer from it. The catalog scopes it to 20 providers across 432 APIs.
| Band | Providers |
|---|---|
| exemplar | 5 |
| strong | 5 |
| developing | 5 |
| thin | 1 |
| emerging | 3 |
| minimal | 1 |
Then you look at who the five exemplars are, and the shape of the problem changes.
The top of the list is not vector databases
| Provider | APIs | Composite | Band |
|---|---|---|---|
| Confluence | 66 | 79.3 | exemplar |
| Airbyte | 44 | 75.7 | exemplar |
| Merge | 118 | 73.4 | exemplar |
| OpenAI | 51 | 69.0 | exemplar |
| Microsoft Copilot | 7 | 66.8 | exemplar |
| Wikidata | 9 | 62.7 | strong |
| Weaviate | 22 | 61.5 | strong |
| Vespa | 8 | 60.4 | strong |
| Chroma | 8 | 60.3 | strong |
| AIMLAPI | 10 | 56.3 | strong |
Confluence, Airbyte, and Merge occupy three of the five exemplar slots. A wiki, a data-integration pipeline, and a unified-API provider — sitting above every vector database in the cohort.
Weaviate, Vespa, and Chroma — the actual retrieval engines — cluster at 60 to 61.5.
The hard part was never the vector store
That ordering is the most useful thing on this page, and it matches how RAG projects actually fail.
The demo is easy. Embed a folder of PDFs, store the vectors, retrieve on cosine similarity, stuff the context window. It works in an afternoon.
What kills the project is everything upstream. The content lives in Confluence, in Google Drive, in Notion, in a ticketing system, in six SaaS tools nobody catalogued. It has permissions — and if retrieval ignores them, you have built a machine that reads a colleague’s salary review aloud. It changes constantly, so an index built once is wrong within a week. And it needs incremental sync, because re-embedding everything nightly is neither affordable nor fast enough.
Every one of those is a source system and pipeline problem. Confluence at 79.3 is at the top because it is where the knowledge already is and it describes its content, spaces, and permissions model properly. Airbyte at 75.7 and Merge at 118 APIs, 73.4 are there because moving content out of many systems on a schedule, incrementally, is the actual engineering.
A build path
- Inventory the sources. Confluence, ticketing, drive, CRM. Whatever is not in the inventory will not be in the answers.
- Move it with a pipeline, not a script. Airbyte or Merge. You need incremental sync and change detection on day one, not after the first stale-answer complaint.
- Carry permissions through. The single most common serious failure in production RAG. Retrieval must filter by the asking user’s access, which means the source system’s permission model has to survive the trip into the index.
- Pick a retrieval engine. Weaviate, Vespa, or Chroma. They score within a point of each other for a reason — this layer is closer to commoditised than any other part of the stack.
- Choose the model last. OpenAI, Copilot, AIMLAPI. Swapping the model is a config change. Swapping your ingestion architecture is a quarter.
Takeaway
20 providers, 432 APIs, and three of the five exemplars are a wiki and two data pipelines. RAG is an ingestion and permissions problem wearing a retrieval costume — the vector database is the interchangeable part, and the catalog’s score distribution says so plainly.
Browse the use case at apis.io/use-cases/rag-knowledge/.