Notion API filter exclusion of formula, rollup, and relation properties forces client-side filtering

Supported feature and symptom

The Notion API's query database endpoint accepts filter objects for a defined set of property types — title, rich_text, number, select, multi_select, date, checkbox, url, email, phone_number, created_time, last_edited_time, created_by, and last_edited_by. Formula, rollup, and relation properties are not included in this allowlist. Attempting to filter on any of these computed properties returns a 400 error, so applications that need to query pages based on derived values must retrieve the full database (or a broad superset) and filter locally.

Constraints and uncertainty

Client-side filtering works for small databases but becomes impractical once the page count exceeds a few thousand because of Notion's rate limits (3 requests/second per integration) and the 100-page pagination limit. A full scan of a 10,000-page database can take minutes and risks timeouts. Relation properties can be partially worked around by querying the related database first, but this adds round-trips and does not help with formula or rollup results that depend on timezone or locale. The Notion team has acknowledged the feature request, but no public roadmap entry confirms when — or if — computed-property filters will be added.

Questions

1. What architectural patterns have teams adopted to keep query latency acceptable when filtering on formula or rollup values at scale?
2. Is there a reliable way to detect, at runtime, whether a given property type has become filterable without parsing error responses?
3. For relation properties, does querying the target database and joining on the client side introduce consistency risks when the related pages change between requests?