Skip to main content
LanceDB provides support for Full-Text Search via Lance, allowing you to incorporate keyword-based search (based on BM25) in your retrieval solutions.

Basic Usage

Consider that we have a LanceDB table named my_table, whose string column text we want to index and query via keyword search, the FTS index must be created before you can search via keywords.

Table Setup

First, open or create the table you want to search:

Construct FTS Index

Create a full-text search index on your text column:
In Python, this page shows the synchronous create_fts_index(...) form. For the asynchronous equivalent (await table.create_index("text", config=FTS(...))), see FTS index.
Perform full-text search and retrieve results:
The search is conducted on all indexed columns by default, so it’s useful when there are multiple indexed columns. If you want to specify which columns to search use fts_columns="text"
LanceDB automatically searches on the existing FTS index if the input to the search is of type str. If you provide a vector as input, LanceDB will search the ANN index instead.
If a table has more than one FTS index, specify the indexed text column in the query. In Python you can use fts_columns or the query builder’s nearest_to_text(..., columns=...); in TypeScript, use query().nearestToText(..., columns). The newer Lance-native FTS does not accept legacy Tantivy-only index parameters.

Keeping the index up to date

Rows you add after building an FTS index aren’t part of the index until you optimize the table. Until then, queries fall back to a flat scan over the unindexed fragments to keep results complete, which slows them down as the unindexed tail grows. Call table.optimize() to fold new rows into the existing index — it’s the same operation used for vector indexes:
A useful rule of thumb is to call optimize() after roughly 100,000 row changes or 20 data-modification operations, whichever comes first. For tables with continuous ingest, schedule it on a cadence that keeps num_unindexed_rows (from table.index_stats(...)) close to zero. If you want to skip the flat scan over unindexed rows entirely — for example, on a hot read path where stale results are acceptable — call .fast_search() on the query so the search returns only indexed results.

Advanced Usage

Tokenize Table Data

By default, the text is tokenized by splitting on punctuation and whitespaces, and would filter out words that are longer than 40 characters. All words are converted to lowercase. Stemming is useful for improving search results by reducing words to their root form, e.g. “running” to “run”. LanceDB supports stemming for Arabic, Danish, Dutch, English, Finnish, French, German, Greek, Hungarian, Italian, Norwegian, Portuguese, Romanian, Russian, Spanish, Swedish, Tamil, and Turkish. You should set the base_tokenizer parameter rather than tokenizer_name because you cannot customize the tokenizer if tokenizer_name is specified. Tokenization and language filters are separate settings. base_tokenizer controls how text is split into searchable tokens. language controls stemming and stop-word removal when stem=True or remove_stop_words=True; choose the tokenizer for CJK or mixed-language segmentation. For example, to enable stemming for English:
The tokenizer is customizable, you can specify how the tokenizer splits the text, and how it filters out words, etc. Default index parameters:
  • base_tokenizer: "simple"
  • language: English
  • with_position: false
  • max_token_length: 40
  • lower_case: true
  • stem: true
  • remove_stop_words: true
  • ascii_folding: true
  • custom_stop_words: None — pass a list[str] to drop additional words beyond the language defaults. Requires remove_stop_words=True.
For multilingual use cases, use base_tokenizer="icu" for unicode-aware word segmentation on mixed-language text. ICU stands for International Components for Unicode. The ICU tokenizer uses bundled ICU4X segmenter data, so it does not require external tokenizer model files. It is a good default when documents mix languages or include scripts where the simple tokenizer would keep an unspaced span as one large token. The Python API also supports tokenizer implementations that load language model files. Use base_tokenizer="jieba/default" for Jieba tokenization, which segments Chinese text into searchable word tokens when the text is written without spaces between words. Use Lindera-backed tokenizers for dictionary-based East Asian morphological segmentation, such as base_tokenizer="lindera/ipadic" for Japanese or base_tokenizer="lindera/ko-dic" for Korean when you have installed and compiled that Lindera model. These are language-specific tokenizers; ICU is the broader mixed-language option.
Model-backed tokenizers require tokenizer model files in Lance’s language model home. Lance looks under the default platform data directory for lance/language_models, or you can set LANCE_LANGUAGE_MODEL_HOME to point to a different model root:
For example, jieba/default is resolved under <model-home>/jieba/default/..., lindera/ipadic under <model-home>/lindera/ipadic/..., and lindera/ko-dic under <model-home>/lindera/ko-dic/....
Built-in stop-word removal supports Danish, Dutch, English, Finnish, French, German, Hungarian, Italian, Norwegian, Portuguese, Russian, Spanish, and Swedish. If you use another stemming language, such as Arabic, Greek, Romanian, Tamil, or Turkish, set remove_stop_words=False or pass custom_stop_words.
For example, for language with accents, you can specify the tokenizer to use ascii_folding to remove accents, e.g. ‘é’ to ‘e’:

Filtering Options

LanceDB full text search supports to filter the search results by a condition, both pre-filtering and post-filtering are supported. This can be invoked via the familiar where syntax. With pre-filtering:
With post-filtering:

Phrase vs. Terms Queries

Lance-based FTS doesn’t support queries using boolean operators OR, AND in the search string.
For full-text search you can specify either a phrase query like "the old man and the sea", or a terms search query like old man sea. To search for a phrase, the index must be created with with_position=True and remove_stop_words=False:
This will allow you to search for phrases, but it will also significantly increase the index size and indexing time. Fuzzy search allows you to find matches even when the search terms contain typos or slight variations. LanceDB uses the classic Levenshtein distance to find similar terms within a specified edit distance. For a complete walkthrough that creates a sample table and demonstrates fuzzy search and relevance boosting, see the fuzzy search example.

Search for Substring

LanceDB supports searching for substrings in the text column, you can set the base_tokenizer parameter to "ngram" to enable this feature, and use the parameters ngram_min_length and ngram_max_length to control the length of the substrings:

More Examples

For complete worked examples of fuzzy search, prefix matching, phrase matching, boosting, boolean queries, and substring search — including sample data generation and index setup — see Full-Text Search Examples.

Full-Text Search on Array Fields

LanceDB supports full-text search on string array columns, enabling efficient keyword-based search across multiple values within a single field (e.g., tags, keywords).

Setting Up the Connection

Connect to your LanceDB instance:

Defining the Schema

Create a schema that includes an array field for tags:

Creating Sample Data

Generate sample data with array fields containing tags:

Creating the Table and Adding Data

Create the table and populate it with the sample data:

Building the Full-Text Search Index

Create an FTS index on the tags column to enable efficient text search:
Search for terms with typos using fuzzy matching:
Search for exact phrases within the array fields: