search() is the heart of retrieval. It runs a hybrid query (a full-text search over text and a vector search over the embedded content) and merges the two with an RRF reranker (Reciprocal Rank Fusion). You get keyword precision and semantic recall in one ranked list, typed against your metadata.
Basic search
Pass a query string. The query is embedded with the table’s embedding model and matched against stored vectors and the full-text index at once.
Each result is a full record ({ id, text, metadata }) ordered by relevance.
Options
Selecting columns
select limits which columns come back. Use your metadata field names (they resolve to the underlying columns automatically) alongside id and text. id is always included even if you omit it.
Filtering results
filter narrows results to matching rows before ranking. Conditions compose with AND, OR, and NOT.
See Filtering for the full operator set.
Tuning recall and speed
The vector half of the search uses an IVF-PQ index, which trades exactness for speed. Three knobs let you tune that trade-off.
nprobes sets how many index partitions to scan. More partitions find more true neighbors (higher recall) but take longer, so raise it when results miss relevant rows. refineFactor controls how many extra candidates are re-ranked with full-precision vectors before returning; higher values sharpen the ranking at some cost. fastSearch defaults to true, in which case only indexed data is searched. If you have just added rows and want them included before the index catches up, set it to false.
Start with the defaults. Increase nprobes first if results feel incomplete, then add a small refineFactor (e.g. 10) if the ordering needs sharpening. Measure on your own data, since the right values depend on table size and embedding model.
Inspecting query plans
When a query is slower than expected, inspect its plan to see which indexes are used and where time goes. Both methods accept limit and filter like search().
explainPlan()
Returns the resolved query plan as a string without executing the query. Useful for confirming an index is being used.
analyzePlan()
Executes the query and returns a physical plan annotated with runtime metrics: rows scanned, time per stage, and so on. Use it to find the actual bottleneck.
analyzePlan() runs the query for real to collect metrics, while explainPlan() only resolves the plan. Reach for explainPlan() first; use analyzePlan() when you need measured timings.