In many databases, an index can speed up one part of a query while the remaining filters are checked later, one row at a time.
That is correct, but it can be expensive when the search condition matches many rows.
ParadeDB avoids that pattern where possible.
It can apply many filters directly during the ParadeDB index scan, including numeric comparisons, boolean checks, set membership, null checks, etc.
When a filter is better served by a different index, ParadeDB can also combine its own results with the candidates from that index before returning rows.
Choosing a Filtering Path
The fastest option is to put frequently-filtered columns in the ParadeDB index when their type can be represented by ParadeDB.
This is the right path for most built-in scalar column types, including numbers, booleans, dates, UUIDs, and literal text. See Indexed Columns for the supported type and operator combinations.
The exception to this rule is when the filter depends on a specialized data type or search method that is not natively supported by the ParadeDB index.
Common examples include ltree path queries or PostGIS spatial filters.
See External Indexes for examples and limitations.
Segment Pruning with Partitioning (Beta)
partition_by is currently a Beta feature under active development.
partition_by enables segment pruning. ParadeDB evaluates query filters against per-segment metadata bounds, skipping non-matching segments entirely before opening posting lists or columnar storage.
See the Partitioning Guide for details on column selection and pruning behavior. 
