Why Postgres can't read your data, and how filtering works anyway.
Updated
The record's data column is an encrypted JSON field. The database cannot filter or sort on it — that is the whole point — which is why the projection columns exist.
On every save, the engine rebuilds the record's plaintext projection from its schema:
filterable land in index_data — scalars only: a nested object in an index column is a value you can't usefully query and a leak you didn't intend.searchable are flattened into search_text (capped, whitespace-joined).index_data carries a GIN index, so filtering on a filterable field is an index lookup rather than a scan — the opt-in costs you privacy on that one field, and buys you real query performance in exchange.
Filtering on a field that is not filterable is a 400 field_not_filterable, and the error names the fields that are — rather than silently returning nothing:
// works — `priority` is marked filterable
await dash.records.list("repair_ticket", { priority: "high" });
// 400 field_not_filterable — `customer_ssn` is encrypted, and stays that way
await dash.records.list("repair_ticket", { customer_ssn: "123-45-6789" });