How can an app answer questions from the right documents?
Find passages the signed-in reader is allowed to see, verify that the source is current and show which passage supports the answer.
When is an ordinary filter enough?
Use a regular filter when you know the field and value, such as “show approved policies for this account.” Try keyword search for a policy title or code. Similarity search helps when people describe the same idea in different words.
Someone asking “Can I back out of a reservation?” might need the cancellation policy even though their words differ from its title. Similarity search ranks likely passages. Keep exact filters for status and language, and enforce permissions from the signed-in account.
How does retrieval help an app answer from its own documents?
Retrieval-augmented generation, or RAG, gives an answer-writing model selected passages from your documents. Start with the passages themselves so you can see whether the search found the right evidence before asking a model to write the answer.
Before making documents searchable, confirm you have permission to use them for search and to send any text to an outside service that turns it into numbers or writes answers. Give the answer-writing model only passages that the signed-in reader is allowed to see. If a question asks for the deadline, open the original and check the deadline, date and any exception. Keep the document and passage IDs next to the stored vectors so the app can cite the source. If the evidence is missing, the app should say it could not find the answer.
Compare tools
Scroll the table sideways to read every column.
| Tool | Where the vectors liveSee what needs to run alongside your app. | How you scope resultsCheck how the app enforces who may see the source. | What affects costSeparate the search store from the cost of creating vectors. | What to keep for recoveryIdentify what a database move leaves outside the export. |
|---|---|---|---|---|
| Supabase | In the PostgreSQL database of your Supabase project when the vector extension is enabled. | Use configured database row rules with the reader’s real access context. | Hosted Free lists 500 MB per project and can pause after a week of low activity. | Keep original documents and the rules linking them to passages. Verify the destination supports the extension. |
| pgvector | In PostgreSQL through the open-source vector extension. | Use PostgreSQL access rules. Compare exact and approximate search with the same filters. | The extension has no software subscription. PostgreSQL and embedding compute still cost resources. | Keep documents and model information. Check extension support and test the restore. |
| Qdrant | In a separate Qdrant collection. Use Cloud or run it yourself. | Store filter fields with vectors. Enforce the reader’s allowed scope and keep privileged keys private. | Cloud Free lists 1 GB RAM and 4 GB disk. Check its inactivity limits. | Collection snapshots exclude aliases and have version constraints. Keep source documents and access rules separately. |
| Pinecone | Vectors live in a managed index with named namespaces. | Check access before choosing a namespace or applying metadata filters. | Check storage, read/write units and any separate model usage. | Keep source documents, access labels and vector settings. Check backup plan. |
| Chroma | Use a local development collection, a server or Chroma Cloud. | Authorize the reader first. Use collection selection and metadata filters. | Compare Cloud usage with your own hosting and vector creation costs. | Keep original records, metadata and rebuild settings. |
| LlamaIndex | The framework connects to the vector store you select. | Enforce the reader’s access before retrieval and verify source labels. | MIT framework. Separately check model, storage and managed service costs. | Keep documents, indexing settings and provider-held data separately. |
| LangChain | The framework connects to an app-selected store. | Check permissions before retrieval and verify the specific store’s filter behavior. | MIT framework with separate connected services and hosting costs. | Keep original documents, retrieval settings, and tests for result and access scope. |
| Unstructured | It prepares document pieces. Vectors live in the store you choose. | Apply access labels to the pieces before indexing them. | Compare self-managed compute and hosted per-page processing. | Keep originals, parsed pieces, source locations and settings. |
| Docling | It converts files before a separate search store receives them. | Check local and remote processing settings. Keep source access with the output. | MIT code. Check compute, model terms and any remote service. | Keep the original, JSON or Markdown output and conversion settings. |
| Tesseract | It reads text from images before vectors are created elsewhere. | Check local processing and keep the source’s permissions with its text. | Apache 2.0 engine. Budget for compute, cleanup and review. | Keep the scan, selected language data, settings and text output. |
How can you check what a reader is allowed to see?
Write three fictional policies on paper. Give one workspace a current and a retired cancellation policy. Give another workspace a similar current policy with a different notice period.
Ask the same question as each fictional reader. The result should contain only their workspace’s current passage. Try a question where they have no authorized answer and check that no other workspace’s text, title or link appears.
Stay on paper unless you can confirm the database or collection is private and disposable, the app uses test-only access, and every document, identity and model input is fictional. In any later test, use the app’s ordinary user access. Remove a fictional document and check its passages stop appearing, including any saved results the app might reuse.
When should vectors live with your app data?
If your app is already on PostgreSQL, see whether you can keep vectors near the records that control access. A separate store can be useful when you need to operate search on its own, but you must keep both stores in sync.
Before comparing prices, count passages instead of files. One long document can produce many entries. Account for the database or cluster, the work of generating and refreshing embeddings, and any source documents stored elsewhere.