Skip to main content
Range indexes in FalkorDB allow the query planner to efficiently locate nodes and relationships by scanning only the entries that satisfy a filter, rather than performing a full label or type scan. They support equality, range, and geospatial predicates on string, numeric, geospatial, and scalar-array properties for both node labels and relationship types.

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)
Note: Complex types like nested arrays, maps, or vectors are not supported for range indexing.

Creating an index for a node label

For a node label, the index creation syntax is:
An old syntax is also supported:
After an index is explicitly created, it will automatically be used by queries that reference that label and any indexed property in a filter.
This can significantly improve the runtime of queries with very specific filters. An index on :employer(name), for example, will dramatically benefit the query:
An example of utilizing a geospatial index to find Employer nodes within 5 kilometers of Scranton are:
Geospatial indexes can currently only be leveraged with < 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:
Then the execution plan for using the index:
This can significantly improve the runtime of queries that traverse super nodes or when we want to start traverse from relationships.

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, use GRAPH.EXPLAIN before and after creating the index:

Index Management

Listing Existing Indexes

To view all indexes in your graph, use the db.indexes() procedure:
This returns information about all indexes including their type (RANGE), entity type (node/relationship), labels, and properties.

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
Costs:
  • 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
Recommendations:
  • Index properties that are frequently used in WHERE clauses
  • 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.PROFILE to validate index effectiveness

Example: Profiling Index Performance

This shows detailed timing information and confirms whether the index was used.

Frequently Asked Questions

Range indexes support string, numeric, and geospatial (point) data types. They handle equality checks, comparisons (<, >, <=, >=), and string prefix operations.
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.
Yes. You can create separate range indexes on different properties of the same label. Each index covers a single property.
No. The current range index implementation does not optimize <> (not-equal) filters. These queries will still perform a full label scan.
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.