What is the ALLOW FILTERING clause and why is it risky?

Cassandra normally rejects queries that would require scanning data across partitions inefficiently — for example, filtering on a non-indexed, non-key column. ALLOW FILTERING overrides that safety check and lets the query run anyway.

SELECT * FROM orders WHERE amount > 1000 ALLOW FILTERING;
-- runs, but may scan a large amount of data server-side to find matches

• Without ALLOW FILTERING, Cassandra simply refuses queries it predicts will be inefficient, forcing the developer to reconsider the data model or add an index.
• With it, the coordinator (and replicas) may scan far more data than the number of rows actually returned, since filtering happens after data is read rather than through an index lookup.
• On a small table or a query already scoped to one partition, the impact can be negligible; on a large, unbounded table it can mean scanning gigabytes of data for a handful of matching rows.

It's fine for ad-hoc analysis, debugging, or genuinely small reference tables, but it should almost never appear in an application's hot query path in production — a properly modeled query table or materialized view is the correct long-term fix.