Qdrant
Hybrid retrieval and filtering can be a strong fit when search is the central job. Compare relevance, filtering and source-update behavior, not just vector-query speed.
Read the vendor documentation ↗Knowledge & discovery / Connected models
Find the answer. Keep the evidence.
Connect relevant passages to their sources, relationships and context.
For teams building search, research assistants and knowledge discovery.
See the 8DB example ↓INPUT
→Manuals, service records and asset identifiers
USEFUL RESULT
Relevant passages with source references and applicability context
8DB example / Stored knowledge changes retrieval
A search for “car” can find “automobile”. The connection stays inspectable.
The documented native-search regression stores a lexical relationship and indexes an entity containing “automobile”. Enabling stored synonym expansion changes which query finds that entity. The application calls the database’s native search function, with no HTTP request required for this path.
01 / QUERYcar
The term the application asks for.
02 / STORED RELATIONSHIPcar ↔ automobile
Present in the store; expansion is disabled for this query.
03 / INDEXED ENTITYautomobile
No exact-token match for “car”.
Expected fixture resultNo match
The indexed token is “automobile”. The stored relationship is not used while expansion is off.
Browser illustration of the documented native-search regression at 7daa7908. This control does not execute 8DB or generate an answer. A stored synonym connection is distinct from embedding similarity; input parsing, permissions and answer generation require their own qualification.
Download the example and evaluation checklist ↓The connection has a stored basis that can be inspected and maintained. That gives an application a concrete way to explain why a result appeared and to distinguish missing knowledge from a failed read.
Evidence status
Documented native regression
A Rust API example and local qualification record exist for stored keyword search with optional lexical expansion. This is a scoped implementation example, not the complete maintenance-assistant workflow below.
Scope for your evaluation
Confirm the evaluated build before adoption. The reviewed search records retain open integration and broader authorization, SDK and platform gates. General evidence retrieval and answer generation require additional composition.
Inspect the API example and evidence scope
unified_search_with_store(
request,
AgentGovernanceContext::PUBLIC,
PersistentSearchBindings { store, braid: None },
)Excerpt from the existing fixture helper. request and store require the fixture setup; this is not a standalone quickstart. PUBLIC is the fixture’s numeric context, not an authentication mechanism.
Native search engineering guide, developer example 1; fixture native_search_lexical_scope.rs at 7daa790852901152b2fb74aad605baaa11b560af. Later integration status reviewed separately on 18 September 2026. No new engine test was run for this page.
01 / From input to value
Which maintenance guidance applies to this asset—and what supports it?
One question spans several representations. Each contributes a different part of the answer.
- 01
Keep the source
Retain the original record, revision and passage identity so a result can lead back to the evidence.
Explore documents → - 02
Find candidates
Use semantic similarity to find relevant material. Include embedding generation and refresh in the application workload.
Explore vectors → - 03
Check the context
Connect passages to the relevant asset, component or policy. A close match is not necessarily an applicable answer.
Explore graphs → - 04
Return usable evidence
Assemble a result with source, revision and applicability fields that the application can inspect and present.
Explore tables →
Conceptual composition. Individual modality guides describe their operations and evidence; combining the models here is not a claim that this complete application is already qualified.
02 / Why bring these together?
Keep the context.
Reduce the reconstruction.
A retrieval system is more useful when the evidence survives the journey from source to result. The 8DB approach brings several representations into one engine; evaluate whether that reduces the identities, copies and update paths your application must reconcile.
03 / Compare the complete job
Where 8DB fits your decision.
Evaluate 8DB when stored knowledge, source relationships and embedded execution need to work together. A dedicated retrieval engine may fit better when the job is limited to search and its existing integrations already meet your requirements.
SurrealDB
An integrated alternative already combines multiple models. Compare the actual operations, relationship semantics and deployment requirements of this workload.
Read the vendor documentation ↗An integrated alternative may cover several stages. Do not assume a separate database is required for every model, or count an architecture diagram as proof of savings.
04 / Prove the useful result
Test what your application needs.
- Update a source and check whether stale passages remain retrievable.
- Apply the same authorization policy to candidates, context and returned evidence.
- Measure useful-result latency at matched relevance, including embedding and refresh costs.
01Relevance & source coverage
02Update-to-searchable time
03Complete-job p95 latency
04Memory & stored bytes
This guide describes evidence retrieval, not a qualified answer-generation service. Extraction, embeddings, authorization and any language-model response need an explicit implementation and evaluation boundary.
Compare identical output quality, freshness, durability and protection. Include parsing, derived representations, persistence, authorization, network setup and result delivery where the application needs them. Report database-stage and complete-job measurements separately.
Start with one useful test.
Bring one query that should match, one that should not, and the source relationship that explains the difference.
Discuss this workload →Explore build options →05 / Go deeper
Follow the evidence.
Architecture context: why source identity and provenance matter; read the article’s stated evidence boundaries.
Research reviewed 18 September 2026. Industry guidance and other organizations’ experiences inform the workload; they are not evidence of 8DB certification or customer deployment.