Skip to main content
FalkorDB leverages the indexing capabilities of RediSearch to provide full-text indices through procedure calls and DDL syntax.

Creating a full-text index for a node label

Using procedure syntax

To construct a full-text index on the title property of all nodes with label Movie, use the syntax:
More properties can be added to this index by adding their names to the above set of arguments, or using this syntax again with the additional names.
Index configuration options:
  1. Language - Define which language to use for stemming text, which is adding the base form of a word to the index. This allows the query for “going” to also return results for “go” and “gone”, for example.
  2. Stopwords - These are words that are usually so common that they do not add much information to search, but take up a lot of space and CPU time in the index.
To construct a full-text index on the title property using German language and using custom stopwords of all nodes with label Movie, use the syntax:
Additional field configuration options:
  1. Weight - The importance of the text in the field
  2. Nostem - Skip stemming when indexing text
  3. Phonetic - Enable phonetic search on the text
To construct a full-text index on the title property with phonetic search of all nodes with label Movie, use the syntax:

Using DDL syntax

Full-text indexes for node labels can also be created using DDL syntax:
An OPTIONS block can be provided to specify additional configuration such as language and stopwords:

Query Syntax and Features

FalkorDB uses RediSearch query syntax which provides powerful search capabilities including fuzzy matching, prefix matching, and tokenization.

Tokenization

When text is indexed, it is automatically tokenized (split into words). By default, text is split on whitespace and punctuation. This allows you to search for individual words within larger text fields. For example, if you index a title property containing “The Lord of the Rings”, you can search for any of the individual words like “Lord” or “Rings”.

Prefix Matching

Prefix matching allows you to search for words that start with a specific prefix using the * wildcard. This is useful for autocomplete functionality or when you want to match word variations.
Note: Prefix matching only works at the end of a word (e.g., Jun*). The wildcard must appear at the end of the search term.

Fuzzy Matching

Fuzzy matching allows you to find words that are similar to your search term, accounting for typos and spelling variations. Use the % symbol followed by the Levenshtein distance (number of character changes allowed).
Fuzzy matching syntax: %term%distance where:
  • term is the word to match
  • distance is the maximum Levenshtein distance (1-3, default is 1 if not specified)
Note: Fuzzy matching is computationally more expensive than exact or prefix matching, so use it judiciously on large datasets.

Combining Query Features

You can combine multiple search terms using boolean operators:
  • AND (or space): All terms must match
  • OR (|): At least one term must match
  • NOT (-): Term must not be present
For more advanced query syntax features, see the RediSearch query syntax documentation.

Utilizing a full-text index for a node label

An index can be invoked to match any whole words contained within:
This CALL clause can be interleaved with other Cypher clauses to perform more elaborate manipulations:
In addition to yielding matching nodes, full-text index scans will return the score of each node. This is the TF-IDF score of the node, which is informed by how many times the search terms appear in the node and how closely grouped they are. This can be observed in the example:

Deleting a full-text index for a node label

Using procedure syntax

For a node label, the procedure syntax drops all full-text indexed properties for the given label:

Using DDL syntax

Full-text indexes for node labels can also be dropped using DDL syntax. Unlike the procedure syntax above, the DDL form drops only the specific property index:

Creating Full-Text indexing for Relation Labels

To create a full-text index on the name property of all relations with the label Manager and enable phonetic search, use the following syntax:

Querying with a Full-Text Index

To search for specific words within the indexed relations, use:

Deleting a Full-Text Index

To delete the full-text index for a specific relation label, use:

Index Management

Listing Full-text Indexes

To view all indexes (including full-text) in your graph, use:
This returns information about all indexes, with full-text indexes marked with type FULLTEXT.

Performance Tradeoffs and Best Practices

When to Use Full-text Indexes

Full-text indexes are ideal for:
  • Text-heavy search: Searching within large text fields like descriptions, articles, or comments
  • Partial word matching: When users might not know the exact text
  • Fuzzy search: Handling typos and spelling variations
  • Multi-word queries: Searching for multiple terms with boolean logic

When NOT to Use Full-text Indexes

Full-text indexes are not optimal for:
  • Exact numeric filtering: Use range indexes instead for numeric comparisons
  • Exact-match queries: Range indexes are more efficient for exact property matches
  • Small or structured data: For short, well-defined strings, range indexes may be sufficient

Performance Considerations

Benefits:
  • Enables sophisticated text search capabilities (fuzzy, prefix, phonetic)
  • Supports stemming and language-specific optimizations
  • Returns relevance scores (TF-IDF) for ranking results
Costs:
  • Write overhead: Text must be tokenized and indexed on write
  • Storage: Requires more space than range indexes due to tokenization and inverted indices
  • Configuration complexity: Language, stopwords, and stemming settings affect results
  • Query performance: Fuzzy matching is more expensive than exact matching
Recommendations:
  • Choose the correct language setting for proper stemming
  • Configure appropriate stopwords for your use case
  • Use prefix matching (*) for autocomplete rather than full fuzzy search when possible
  • Test query performance with realistic data volumes
  • Consider the tradeoff between index configurability and query performance

Configuration Best Practices

Language Selection:
  • Wrong language settings can produce poor stemming results
  • Example: Searching “running” with English stemming finds “run”, but German stemming won’t
Stopwords:
  • Default stopwords are optimized for general text
  • Customize stopwords for domain-specific applications (e.g., legal, medical, technical documents)
  • Too many stopwords can hurt precision; too few increase index size
Phonetic Search:
  • Useful for name searches and when spelling variations are common
  • Increases index size and query time
  • Double Metaphone (dm:en) is recommended for English

Verifying Full-text Index Usage

Use GRAPH.EXPLAIN to verify that full-text queries use the index:

Frequently Asked Questions

Use the procedure CALL db.idx.fulltext.createNodeIndex('Label', 'property1', 'property2'). You can index one or more properties on a given label.
Use CALL db.idx.fulltext.queryNodes('Label', 'search term') YIELD node, score. The score reflects TF-IDF relevance ranking.
Yes. Full-text indexes leverage RediSearch which supports stemming, stopwords, and phonetic matching for more flexible text search.
Yes. Use db.idx.fulltext.queryRelationships('RelType', 'search term') to search relationships. Create the index on a relationship type similarly to node indexes.
Use CALL db.idx.fulltext.drop('Label') to remove the full-text index associated with a given label.