Semantic search answers "what sounds similar." Relational retrieval answers "what is actually true."
Semantic search finds text that means something similar to a query. Relational retrieval narrows results by facts that must hold exactly — a tenant ID, a status, a date range, a relationship. Most real retrieval needs both at once, not one followed by the other in application code.
Semantic and relational retrieval is a query pattern that combines meaning-based similarity ranking with exact structural filters and relationship traversal in a single request, so results are both relevant and factually scoped.
What this guide covers
The practical decision points.
Two different questions
Semantic search asks what text is similar in meaning. Relational retrieval asks what records satisfy exact conditions and connections.
Usually needed together
A support ticket search needs both: semantically similar issues, scoped to the right tenant and status.
One query beats two systems
Running both in one query avoids the application-side join between a vector store’s results and a separate database’s filtered rows.
Architecture sketch
One request, two constraints
A single SearchQuery-shaped request applies semantic ranking and exact where-filters together, so the returned Records satisfy both at once instead of being reconciled after two separate calls.
Implementation example
Rank by meaning, constrain by fact
The where clause applies exact conditions in the same call as the semantic query — there is no second query to reconcile against.
from rushdb import RushDB
db = RushDB("RUSHDB_API_KEY")
results = db.ai.search({
"labels": ["TICKET"],
"propertyName": "body",
"query": "customer cannot reset their password",
"where": {
"tenant_id": "acme",
"status": "open",
"createdAt": {"$gte": "2026-06-01"},
},
"limit": 10,
})
print(results.data)When exact filters matter as much as meaning
Multi-tenant apps, permissioned data, and workflow-state-scoped search all need exact filters to be non-negotiable — a semantically perfect match from the wrong tenant is a bug, not a good result. Relational retrieval makes those constraints part of the query, not a post-filter on the client.
Tenant or account scoping in multi-tenant products
Status and workflow-state constraints (only "approved" or "open" records)
Date ranges and numeric thresholds that must hold exactly
Permission scoping so semantic recall never crosses an access boundary
Adding relationships to the same query
Once results are ranked and filtered, SearchQuery can also traverse relationships from those Records — following ownership, citations, or workflow links without a separate call.
Decision table
Two-system retrieval vs one-query retrieval
The alternative to combining both in one query is running them separately and joining in application code. The cost of that split is mostly invisible until scale or consistency becomes a problem.
One call to the vector store for similarity, one call to the primary database for exact filters, joined in application code.
One SearchQuery-shaped call applies semantic ranking and exact where-filters together.
The two stores can drift — a record deleted in one system may still rank in the other until the next sync.
Filters and ranking both run against the same live Records.
Requires a third lookup against whatever stores relationship data.
Relationship traversal is part of the same SearchQuery contract.
Two systems to provision, monitor, and keep schema-aligned.
One backend for records, vectors, relationships, and filters.
Related RushDB docs
Read the primitives behind the guide.
These docs links are the implementation references for the concepts explained on this page.