Supported Data Types
Range indexes support the following data types:- String: Text values for exact matching and range queries
- Numeric: Integer and floating-point numbers for range comparisons
- Geospatial: Point data types for location-based queries
- Arrays: Single-property arrays containing scalar values (integers, floats, strings)
Creating an index for a node label
For a node label, the index creation syntax is::employer(name), for example, will dramatically benefit the query:
Employer nodes within 5 kilometers of Scranton are:
< and <= filters; matching nodes outside the given radius are matched using conventional traversal.
Creating an index for a relationship type
For a relationship type, the index creation syntax is:Deleting an index for a node label
For a node label, the index deletion syntax is:Deleting an index for a relationship type
For a relationship type, the index deletion syntax is:Array Indices
FalkorDB supports indexing on array properties containing scalar values (e.g., integers, floats, strings), enabling efficient lookups for elements within such arrays. Note: Complex types like nested arrays, maps, or vectors are not supported for indexing. The following example demonstrates how to index and search an array property:Verifying Index Usage
To verify that an index is being used by your query, useGRAPH.EXPLAIN before and after creating the index:
Index Management
Listing Existing Indexes
To view all indexes in your graph, use thedb.indexes() procedure:
Performance Tradeoffs and Best Practices
When to Use Range Indexes
Range indexes are ideal for:- Filtering by specific values: Queries with equality filters (e.g.,
WHERE p.name = 'Alice') - Range queries: Numeric or string comparisons (e.g.,
WHERE p.age > 30,WHERE p.name >= 'A' AND p.name < 'B') - Geospatial queries: Finding entities within a certain distance
- Array membership: Checking if a value exists in an array property
Performance Considerations
Benefits:- Dramatically improves query performance for filtered searches
- Reduces the number of nodes/relationships that need to be scanned
- Enables efficient range scans and point lookups
- Write overhead: Every insert or update to an indexed property requires updating the index
- Storage: Indexes consume additional memory and disk space
- Maintenance: Index structures need to be maintained during graph modifications
- Index properties that are frequently used in
WHEREclauses - Avoid indexing properties that are rarely queried or have high write frequency
- For properties with very few distinct values (low cardinality), indexes may not provide significant benefits
- Monitor query performance with
GRAPH.PROFILEto validate index effectiveness
Example: Profiling Index Performance
Frequently Asked Questions
What data types can be range-indexed?
What data types can be range-indexed?
Range indexes support string, numeric, and geospatial (point) data types. They handle equality checks, comparisons (<, >, <=, >=), and string prefix operations.
Are range indexes used automatically?
Are range indexes used automatically?
Yes. When a WHERE clause filters on an indexed label-property pair, FalkorDB automatically introduces an index scan. Use
GRAPH.EXPLAIN or GRAPH.PROFILE to verify index usage.Can I have multiple range indexes on the same label?
Can I have multiple range indexes on the same label?
Yes. You can create separate range indexes on different properties of the same label. Each index covers a single property.
Do range indexes support not-equal (\< >) filters?
Do range indexes support not-equal (\< >) filters?
No. The current range index implementation does not optimize
<> (not-equal) filters. These queries will still perform a full label scan.What is the performance tradeoff of range indexes?
What is the performance tradeoff of range indexes?
Range indexes speed up read queries with filters but add overhead on writes (inserts and updates to indexed properties) and consume additional memory. Index properties that are frequently filtered in WHERE clauses.